Tenemos un servidor de correo (Mailenable) que utilizamos para vender cuentas de correo electrónico a nuestros clientes. Tenemos un cliente que no pudo enviar correo electrónico a un dominio específico y recibe este error del servidor de correo electrónico del dominio:
Motivo: el mensaje no se pudo entregar porque el nombre de dominio nombredenuestraempresacliente.com no tiene ningún registro DNS.
La empresa que nos utiliza para el correo electrónico no tiene ningún registro DNS para su dominio.ourclientcompanyname.com
Los registros MX están bien pero el dominio no tiene otros registros DNS. ¿Es ese un posible error? ¿Qué registros DNS debería agregar el cliente?
Respuesta1
Los registros MX son finos, pero el dominio no tiene ningún registro DNS. ¿Es ese un posible error? ¿Qué registro DNS debería agregar el cliente?
Sí, algunos servidores de correo, al recibir un correo electrónico, verifican que el dominio del usuario remitente, no solo el servidor remitente, tenga registros DNS. Creo que es un poco tonto y no es una buena forma de comprobar el spam, pero es lo que es. Lo más probable es que su cliente simplemente necesite ingresar un Aregistro para su dominio principal ourclientcompanyname.com. Consígales una cuenta de hosting de $5 y un sitio web informativo de una sola página por si acaso, sólo para ser amables.
EDITAR:
Enterrado dentro del antiguo RFC 5321, dice en la sección 2.3.5:
Solo se permiten nombres de dominio completos (FQDN) que se puedan resolver cuando se utilizan nombres de dominio en SMTP.
¡Ruido! Sigo pensando que es una tontería pensar en ello como un disuasivo de spam y es una combinación de correlación/causalidad, pero bueno, al menos es un estándar documentado y seguirlo tiene algunos efectos secundarios positivos en la carpeta de spam. ¿Quién tiene dos pulgares y acaba de recibir educación sobre RFC?
Respuesta2
RFC 5321 sección 2.3.5requiere que los nombres de dominio utilizados en el correo electrónico se puedan resolver en direcciones.
De las partes relevantes:
Solo se permiten nombres de dominio completos (FQDN) que se puedan resolver cuando se utilizan nombres de dominio en SMTP. En otras palabras, se permiten nombres que se pueden resolver en RR MX o RR de dirección (es decir, A o AAAA) (como se analiza en la Sección 5), al igual que RR CNAME cuyos objetivos se pueden resolver, a su vez, en MX o RR de dirección. . NO DEBEN utilizarse apodos locales ni nombres no calificados. Hay dos excepciones a la regla que requiere FQDN:
- El nombre de dominio proporcionado en el comando EHLO DEBE ser un nombre de host principal (un nombre de dominio que se resuelve en una dirección RR) o, si el host no tiene nombre, una dirección literal, como se describe en la Sección 4.1.3 y se analiza con más detalle en la discusión de EHLO de la Sección 4.1.4.
Este no es un requisito nuevo;RFC 2821 sección 2.3.5(2001) tenían un lenguaje similar.
El nombre de dominio, como se describe en este documento y en [22], es el nombre completo y totalmente calificado (a menudo denominado "FQDN"). Un nombre de dominio que no está en formato FQDN no es más que un alias local. Los alias locales NO DEBEN aparecer en ninguna transacción SMTP.
Si su servidor de correo dice EHLO company.exampleque company.example no se puede resolver en una dirección, entonces es perfectamente válido rechazar esa conexión. Lo mismo se aplica a los nombres de dominio utilizados en las direcciones del remitente y del destinatario (con la excepción de postmaster, que no requiere ningún nombre de dominio).
(Antes de RFC 2821, los estándares rectores eran RFC 821 y RFC 974, que datan de la década de 1980 y tenían que adaptarse a muchas redes distintas de Internet que ya no existen, por lo que los estándares eran mucho menos restrictivos).
Respuesta3
Para que el correo funcione correctamente, se requieren tres registros DNS.
Registro A: asignación de nombre de host a dirección IP
Registro MX: el registro MX está vinculado al registro A del servidor de correo.
Búsqueda inversa: la dirección IP debe estar vinculada al registro A para la búsqueda inversa (Prevención de SPAM)
Además, es necesario configurar la dirección PAT en el firewall para el servidor de correo de modo que la IP pública (IP de origen) del servidor de correo coincida con la búsqueda inversa.
Por lo general, necesitará comunicarse con su ISP y pedirle que cree la búsqueda inversa si posee las direcciones IP que está utilizando en el lado público.
Nota: No existe ningún RFC con respecto al DNS inverso confirmado hacia adelante. Es simplemente una mejor práctica.