Sí, en algunos casos. Un dominio sin registro MX puede recibir correo mediante la regla de enrutamiento implícito de SMTP. Para ello, el dominio debe resolver a una dirección IP en la que un servidor acepte correo. Un MX nulo declara expresamente que el dominio no acepta correo. RFC 5321, sección 5.1 define la ruta alternativa y RFC 7505, sección 3 define el MX nulo.
Este artículo trata de la recepción de correo desde internet. La respuesta DNS no evalúa la autenticación del envío ni la reputación del remitente. La definición de registro MX explica los conceptos generales.
Sin MX, hay que consultar los registros de dirección del dominio
Si la consulta MX se completa correctamente pero no devuelve registros MX, SMTP trata el propio dominio como un servidor de correo implícito con preferencia 0. El destino se obtiene de sus registros A o AAAA. La regla solo se aplica cuando la lista MX está vacía. RFC 5321 especifica cómo se elige el host de destino.
Si las consultas de direcciones también se completan correctamente y no devuelven registros A ni AAAA, no hay un destino implícito disponible. Que haya una web en una dirección resuelta no demuestra que un servidor SMTP acepte conexiones allí. DNS indica una posible ruta; la aceptación del correo sigue dependiendo del servicio receptor. RFC 7505 explica por qué los registros de dirección por sí solos pueden dar lugar a intentos de entrega fallidos.
El MX nulo declara que el dominio no acepta correo
Un MX nulo consiste en un único registro MX con preferencia 0 y . como destino:
nomail.example. 3600 IN MX 0 .
El punto representa la etiqueta raíz de DNS; no es el nombre de un servidor de correo. Un dominio que publique un MX nulo no debe publicar otros registros MX junto a él. Ambas condiciones figuran en RFC 7505.
Si el MX nulo aparece junto a un MX normal, la configuración se contradice. Emvero distingue este caso con DOMAIN_MAIL_ROUTE_MISCONFIGURED. La verificación devuelve unknown en vez de adivinar qué declaración pretendía publicar el responsable del dominio.
Un MX explícito inutilizable no activa la ruta implícita
Cuando existen registros MX, el servidor remitente debe resolver los hosts que indican. Si ninguno es utilizable, no puede sustituirlos por las direcciones del propio dominio mediante la regla implícita. RFC 5321, sección 5.1 establece este límite.
Por ejemplo, una web que funciona en el dominio no arregla un destino MX sin registros de dirección. También hay que investigar una consulta fallida del destino MX: pueden faltar registros o existir un problema temporal de DNS. No todos los destinos sin resolver indican un fallo permanente del buzón.
Distinguir la ausencia de datos de un fallo de DNS
NXDOMAIN significa que el nombre consultado no existe. NODATA significa que para ese nombre no hay registros del tipo solicitado. Una consulta MX que devuelve NODATA puede, por tanto, dar paso a una consulta de direcciones; no significa que el dominio no exista. RFC 2308, sección 2 explica estas respuestas negativas.
SERVFAIL o un tiempo de espera agotado dejan la consulta sin resolver. Conviene repetirla o investigar el resolutor antes de concluir nada sobre la ruta del correo. SMTP exige aplazar el envío y volver a intentarlo tras un error temporal de consulta. RFC 5321 describe ese comportamiento. La explicación de los fallos de DNS ayuda a interpretar las diferencias en la verificación.
Comprobar la respuesta antes de cambiar la dirección
Con dig instalado, se puede consultar la respuesta MX así:
dig MX example.com
Hay que sustituir example.com por el dominio que se investiga. Conviene conservar la cabecera y la sección de respuesta: una salida abreviada por sí sola omite detalles que permiten distinguir una respuesta vacía de un error. El manual de dig de ISC documenta la sintaxis y las opciones de salida.
- Comprobar primero el estado de la respuesta. Investigar
NXDOMAIN,SERVFAILo un tiempo de espera agotado antes de interpretar el resultado como una lista MX vacía. - Si aparece
MX 0 ., comprobar si es el único registro MX. Un solo MX nulo declara que el dominio no acepta correo; los registros mezclados requieren revisar la configuración. - Si hay registros MX normales, consultar A y AAAA para sus hosts de destino. No usar las direcciones del propio dominio como sustituto implícito.
- Si la lista MX está vacía tras una resolución correcta, consultar A y AAAA para el propio dominio. Esas direcciones son los posibles destinos implícitos.
Los siguientes ejemplos son sintéticos. Los nombres bajo .example y la dirección IP reservada para documentación son ilustraciones, no resultados de consultas reales.
| Resultado DNS sintético | Conclusión sobre la ruta | Siguiente paso |
|---|---|---|
implicit.example. no tiene MX, pero tiene A 192.0.2.10 |
Existe un destino implícito; el registro no demuestra que haya un servicio SMTP escuchando | Comprobar el servicio receptor si importa que acepte correo realmente |
nomail.example. IN MX 0 . es el único MX |
El dominio declara expresamente que no acepta correo | Corregir el dominio si se introdujo por error |
broken.example. IN MX 10 mx.broken.example.; el destino no tiene A ni AAAA tras consultas correctas |
No se encontró un destino explícito utilizable | Pedir al responsable del dominio que revise el destino MX |
mixed.example. tiene MX nulo y registros MX normales |
Configuración contradictoria | Pedir una revisión de la configuración DNS |
La consulta del dominio devuelve NXDOMAIN |
El nombre no existe según la respuesta DNS | Comprobar si hay un error en el dominio |
La consulta devuelve SERVFAIL o agota el tiempo de espera |
La ruta sigue sin resolverse | Repetir la consulta o investigar DNS; conservar la incertidumbre |
Interpretar la evidencia de dominio de Emvero
El comprobador público de dominios de Emvero evalúa las rutas del correo entrante sin abrir una sesión SMTP. Devuelve la conclusión sobre la ruta, pero no los nombres de los hosts MX ni sus valores de preferencia. Para inspeccionar esos registros, hace falta una herramienta DNS.
Cuando los registros MX sí indican una ruta, puede identificar el proveedor visible sin confundir una pasarela con el servicio de buzones.
Para consultar una dirección completa desde una integración, la API de verificación de correo acepta variant: "domain". Hay que leer checks.mail_routing junto con status y reason_codes. IMPLICIT_MX es informativo. NULL_MX y DNS_NXDOMAIN respaldan undeliverable; DNS_SERVFAIL, DNS_TIMEOUT y las rutas contradictorias conservan unknown. DNS_NODATA forma parte del vocabulario de DNS, pero una respuesta MX vacía de bajo nivel no garantiza ese código en la API ni un veredicto sobre la dirección.
Una ruta de dominio no demuestra que exista un buzón
Una ruta para example.com no dice nada sobre la existencia de person@example.com. Una verificación completa puede recoger evidencia sobre el destinatario si el servidor receptor lo permite; el intercambio SMTP explica el proceso. La aceptación también puede deberse a un dominio catch-all o a que la decisión sobre el destinatario se tome más tarde.
La comparación entre verificación completa y comprobación de dominio ayuda a elegir la evidencia necesaria para cada decisión. Para investigar ahora el correo entrante, se puede comprobar la ruta de correo del dominio. La consulta pública es gratuita y no requiere una cuenta.