Aprende qué confirma una comprobación de registro MX, cómo manejar null MX, dominios mal configurados y fallos DNS temporales, y por qué reintentos y caché reducen falsos rechazos.
Una comprobación de registro MX te indica si un dominio publica en DNS un enrutamiento de correo, lo que significa que probablemente se pueda enrutar correo a ese dominio. No confirma que exista un buzón específico ni que el servidor aceptará tu mensaje.
No. Un dominio puede tener registros MX válidos y aun así rechazar correo porque la dirección no exista, el servidor bloquee remitentes desconocidos o se requieran comprobaciones adicionales. Trata MX como una señal a nivel de dominio, no como prueba de entregabilidad para un buzón específico.
Un null MX es una política explícita de “no enviar correo” establecida por el propietario del dominio. Suele aparecer como un registro MX que apunta a un solo punto (.), lo que significa que no hay lugar donde entregar correo a propósito.
“No MX” puede ser ambiguo porque algunos sistemas de correo intentan un fallback a A/AAAA cuando falta MX, así que el dominio aún podría recibir correo en algunas configuraciones. Null MX es inequívoco: el dominio dice explícitamente que no acepta correo y normalmente se rechaza en el registro.
Porque un nombre de host MX puede existir en DNS pero ser inutilizable si no resuelve a una dirección IP. Verificar que cada objetivo MX tenga registros A/AAAA detecta un modo de fallo común donde el enrutamiento parece configurado pero no es accesible.
Los timeouts suelen significar que tu resolvedor no recibió respuesta a tiempo por pérdida de paquetes, servidores autorizados lentos, límites de tasa o problemas de red temporales. Normalmente es un problema que merece reintento, no una señal definitiva de que el dominio no puede recibir correo.
SERVFAIL indica que el resolvedor no pudo completar la consulta, a menudo por un problema temporal como caídas aguas arriba o problemas con DNSSEC. En la mayoría de los casos deberías reintentar brevemente y, si persiste, tratar el resultado como “desconocido” en lugar de inválido permanentemente.
Un valor práctico por defecto son 2–3 intentos dentro de un pequeño presupuesto de tiempo (alrededor de 1–2 segundos en total para el paso DNS), reintentando solo errores retryables como timeouts o SERVFAIL. Si sigue fallando, evita un rechazo contundente y mueve la dirección a una ruta de “verificar más tarde”.
Caché los resultados exitosos usando el TTL de DNS cuando esté disponible, pero limita cuánto tiempo los confías para no mantener veredictos obsoletos. Cachea fallos temporales por poco tiempo para no sobrecargar DNS durante incidentes y vuelve a comprobar cuando el usuario edite el correo o cuando la última comprobación sea antigua.
Almacena un resultado junto con un código de motivo (por ejemplo: dominio no existe, null MX, fallo DNS temporal, objetivo MX sin IP) y una marca temporal de cuándo se verificó. Si prefieres no orquestar todas las comprobaciones y casos extremos tú mismo, Verimail puede devolver un resultado estructurado que combina comprobación de sintaxis, verificación de dominio/MX y detección de desechables en una sola llamada API.
Una comprobación de MX responde a una pregunta práctica: ¿puede este dominio recibir correo en alguna parte? No trata de determinar si una persona es real ni confirma que exista un buzón específico. Solo inspecciona la configuración de enrutamiento de correo del dominio en DNS.
Cuando la comprobación tiene éxito, normalmente significa que el dominio publica servidores de correo (o una alternativa reconocida) y, en teoría, se pueden enrutar mensajes a ese dominio. Eso es útil durante el registro o la captura de leads porque filtra basura obvia como dominios inventados antes de que los guardes o envíes correo.
Pero los resultados de MX no garantizan un buzón. Un dominio puede tener registros MX válidos y aun así rechazar correo por muchas razones: la dirección podría no existir, el servidor podría bloquear remitentes desconocidos o puede requerir comprobaciones adicionales antes de aceptar mensajes. MX tampoco puede decir si una bandeja está llena, si un dominio está aparcado o si el usuario puede acceder al buzón.
Un flujo de validación típico trata MX como una primera barrera, no como el veredicto final. Empiezas por la sintaxis básica, luego confirmas que el dominio tiene una ruta de correo plausible (MX y señales DNS relacionadas) y solo después aplicas reglas de mayor señal como detección de proveedores desechables, riesgo de trampas de spam y listas blancas o negras.
El resultado de “fallo” importa tanto como el hecho de que haya fallado. La mayoría de sistemas acaban viendo un pequeño conjunto de resultados:
Considera MX como una señal fuerte a nivel de dominio, pero nunca como prueba de que un buzón concreto sea entregable.
DNS es la guía telefónica de Internet. Cuando escribes un dominio, DNS devuelve registros que dicen a los ordenadores a dónde conectarse y cómo.
Durante una comprobación de registro MX (y cualquier verificación básica de dominio de correo), te encontrarás con varios tipos de registro frecuentemente:
Las respuestas DNS pueden cambiar con el tiempo, incluso para el mismo dominio. El caché es la razón más común: tu dispositivo, router, ISP y resolvedores públicos pueden almacenar respuestas hasta que expire el TTL. Si el propietario del dominio acaba de arreglar su configuración de correo, algunos usuarios verán los nuevos registros MX rápidamente mientras otros seguirán viendo los antiguos durante minutos u horas.
Un resolvedor es el servicio DNS que realiza búsquedas en tu nombre. La elección del resolvedor importa porque distintos resolvedores tienen diferentes estados de caché, rutas de red y comportamientos de timeout. Un resolvedor puede devolver una respuesta limpia al instante mientras que otro devuelve un error temporal porque no puede alcanzar un servidor autoritativo en ese momento.
Por eso un dominio puede verse “bien” en la red Wi‑Fi de la oficina y “mal” desde una red móvil. Por ejemplo, el host MX puede resolverse bien en un punto, pero en otro sitio un resolvedor agota el tiempo intentando obtener el registro A/AAAA, así que el dominio parece roto aunque solo sea un problema DNS momentáneo.
Estos básicos te ayudan a tratar los resultados DNS como señales y no como verdades absolutas. También explican casos límite como null MX, malas configuraciones y fallos temporales.
Empieza tratando el dominio como dato del usuario, no como algo ya limpio. Recorta espacios, elimina puntos finales y conviértelo a minúsculas. Si el usuario introduce caracteres internacionales (como ü o 例), convierte el dominio a su forma IDN (a menudo llamada punycode) antes de consultar DNS, así verificarás lo que DNS realmente almacena.
A continuación, realiza la búsqueda MX para ese dominio normalizado. Si obtienes múltiples registros, ordénalos por prioridad (los números más bajos se prueban primero). Ese orden importa si haces comprobaciones más profundas porque un dominio “bueno” puede tener un MX roto y otro que funciona.
Tras obtener resultados MX, valida los destinos, no solo el hecho de que “algo existe”. Cada registro MX apunta a un nombre de host, y ese nombre debe resolverse a al menos un registro A o AAAA. Si no lo hace, los servidores de correo no pueden alcanzarlo aunque el registro MX exista.
Cuando no hay registros MX, comprueba si el dominio base tiene registros A/AAAA. Muchos sistemas lo tratan como un fallback porque algunos servidores entregan a la A/AAAA del dominio cuando falta MX. Los límites son importantes: sigue sin probar que el dominio acepte correo y no te protege de dominios que intencionalmente no reciben email.
Un flujo seguro podría ser:
No almacenes solo “aprobado/rechazado”. Guarda un estado, un código de motivo (por ejemplo: MX_FOUND, NO_MX_BUT_A, MX_TARGET_NO_IP, DNS_TIMEOUT) y un checked_at para saber cuándo revalidar.
Un registro MX nulo es el propietario del dominio indicando claramente: “Este dominio no acepta correo”. No es una configuración rota ni una caída temporal. Es una política intencional.
En DNS suele aparecer como un registro MX cuyo destino especial es un solo punto (.). Ese punto significa “a ninguna parte”. Así, una búsqueda MX puede tener éxito y aun así decirte que no entregues correo a ese dominio.
Null MX difiere de dos resultados que a primera vista pueden parecer similares:
Con null MX no hay ambigüedad. Si tu comprobación devuelve null MX, el comportamiento más seguro es tratar el dominio como no emailable y bloquearlo en el registro (o pedir otra dirección). Permitirlo provocará rebotes predecibles y dañará la entregabilidad.
Cómo lo explicas al usuario importa. Evita términos DNS y mantén la comunicación accionable:
Además, mantén null MX separado de “no se pudo comprobar ahora”. Null MX debe ser un rechazo seguro. Los errores temporales deben activar una ruta de reintento, no un bloqueo definitivo.
Muchos dominios de correo no son un simple “sí” o “no”. Existen, pero su DNS está lo suficientemente desordenado como para que una comprobación MX devuelva resultados confusos. El objetivo es evitar rechazar a personas reales mientras bloqueas dominios que no pueden recibir correo.
Las malas configuraciones comunes incluyen MX que apuntan a un host de correo que no existe, a menudo porque el propietario cambió de proveedor y dejó registros obsoletos. Otro problema frecuente es un objetivo MX inválido: MX debe apuntar a un nombre de host, no a una dirección IP. También puedes encontrarte con cadenas CNAME que terminan en ningún lado, loops o comportamientos inconsistentes entre resolvedores.
Algunos dominios no tienen ninguna ruta de entrega usable: ni MX ni un fallback A/AAAA que funcione. Otros devuelven respuestas inconsistentes (registros MX aparecen en una consulta y desaparecen en la siguiente), normalmente por propagación o DNS alojado mal configurado.
Clasifica según la confianza.
Trata el resultado como fallo duro cuando el dominio claramente no puede aceptar correo, como un objetivo MX inválido (por ejemplo una IP) o hosts MX que son consistentemente NXDOMAIN tras reintentos.
Trátalo como fallo suave cuando el resultado pueda ser temporal (timeouts, respuestas inconsistentes, SERVFAIL). En ese caso, pide al usuario que reintente o permite el registro pero marca la dirección para confirmación posterior.
Usa una categoría desconocido para dominios raros pero no definitivamente rotos, y combina el resultado MX con otras señales en lugar de tomar una decisión única.
Un lookup MX fallido no siempre significa que un dominio no pueda recibir correo. A veces tu resolvedor (o el proveedor DNS del dominio) está teniendo un mal momento. Si tratas cada fallo como “inválido”, rechazarás usuarios reales durante incidentes breves.
Estos son resultados DNS comunes y cómo suelen mapearse en la práctica:
Un enfoque práctico es clasificar errores en reintentables vs finales. Timeouts, SERVFAIL, REFUSED y truncamiento suelen ser “intentar de nuevo”, idealmente con un pequeño backoff y un tope (2–3 intentos). Solo tras fallos repetidos deberías caer en una decisión más suave como “desconocido” en lugar de “inválido”.
Para depurar, registra suficiente información para ver patrones sin almacenar datos personales innecesarios. El dominio consultado (no la dirección de correo completa), el código de error y el resolvedor usado, recuento de intentos y marcas temporales, si hubo reintento por TCP y si la respuesta fue desde caché suelen ser suficientes.
DNS suele ser rápido, pero no es perfectamente fiable. Si tratas un timeout como un “no” definitivo, rechazarás usuarios reales durante pequeñas interrupciones. Una buena comprobación MX equilibra velocidad con una pequeña red de seguridad.
Mantén los reintentos limitados y predecibles para que los usuarios no queden bloqueados en un formulario:
Backoff y jitter simplemente significan esperar un poco más cada vez y evitar reintentos perfectamente sincronizados entre usuarios. Eso evita picos donde muchos registros golpeen DNS al mismo tiempo.
La caché evita que hagas la misma pregunta una y otra vez. Cachea resultados positivos usando el TTL DNS cuando esté disponible, pero pon un tope (por ejemplo, no más de 24 horas) para no confiar en datos antiguos indefinidamente.
Para resultados negativos o de error, cachea por poco tiempo (a menudo 1–5 minutos). Esto evita sobrecargar DNS durante incidentes cortos y mantiene tus sistemas más estables.
Fuerza una nueva comprobación cuando importe: el usuario edita su correo, ves nueva actividad tras un largo periodo de inactividad o tu última comprobación es más antigua que el tope de caché.
Una comprobación MX es útil, pero es fácil tratarla como un veredicto final.
Un error es asumir que “MX existe” significa que una dirección es entregable. MX solo te dice que un dominio afirma aceptar correo en alguna parte. No dice si un buzón existe, si el servidor rechaza usuarios desconocidos o si el dominio es seguro para enviar.
Otro error es fallar de forma contundente en el primer timeout, SERVFAIL o respuesta inestable. DNS no es perfectamente fiable. Si bloqueas un registro porque una consulta falló, rechazarás usuarios reales durante pequeñas caídas.
Null MX también se malinterpreta con frecuencia. Un null MX es una señal explícita de que el dominio no acepta correo. Si lo ignoras y aceptas el dominio, te expones a rebotes garantizados más tarde.
Muchas implementaciones se quedan a mitad de camino al leer nombres de host MX. Nunca resuelven los objetivos MX a A/AAAA, lo que hace que se pierda un modo de fallo común: el dominio publica MX que no resuelven o que solo resuelven a una familia de direcciones inalcanzable.
La caché también puede jugar en tu contra cuando no tiene un plan de expiración. Guardar resultados “para siempre” significa que seguirás rechazando dominios que estuvieron temporalmente rotos, o seguirás aceptando dominios que luego quitaron servicio de correo.
Los patrones que más problemas causan en producción son:
Si validas en el registro, piensa en términos de confianza, no de certeza. Reintenta errores DNS transitorios, cachea resultados por tiempo limitado y combina comprobaciones MX con otras señales.
Usa este repaso después de que tu comprobación MX devuelva resultado:
Un ejemplo concreto: un usuario se registra con [email protected] durante una breve caída DNS en tu resolvedor. La primera búsqueda agota el tiempo y tu app rechaza el registro. Si reintentas una o dos veces en uno o dos segundos, a menudo obtendrás una respuesta limpia sin ralentizar mucho el formulario. Si sigue fallando, permite el registro pero marca el correo como “necesita verificación posterior” y reintenta en segundo plano.
Mantén resultados por un periodo corto. Cachear éxitos y fallos recientes reduce búsquedas repetidas y te ayuda a distinguir entre “este dominio no puede recibir correo” y “DNS estuvo inestable un minuto”.
Un usuario intenta registrarse con una cuenta real de trabajo, como [email protected]. Tu app ejecuta una comprobación MX durante el registro para ver si el dominio puede recibir correo. Al mismo tiempo, el proveedor DNS del dominio tiene un problema breve.
En la primera consulta, tu sistema no obtiene un sí o un no claro. En su lugar la consulta DNS agota el tiempo o devuelve SERVFAIL. Eso no significa que el dominio sea falso. Significa que el resolvedor no pudo obtener una respuesta en ese momento.
Si tratas eso como “dominio inválido” y bloqueas el registro, crearás un falso rechazo. El usuario lo intenta de nuevo un minuto después y funciona, lo que hace que tu validación parezca aleatoria.
Un flujo más seguro separa “definitivamente malo” de “temporalmente desconocido”:
Los reintentos ayudan porque muchos problemas DNS son breves. El caché a corto plazo ayuda porque varios registros de la misma empresa pueden ocurrir juntos. Si tu primer intento falla por una caída temporal, cachear ese fallo por demasiado tiempo puede bloquear usuarios reales.
Cuando soporte reciba la pregunta “¿por qué fue rechazado mi correo?”, evita culpar al usuario. Una respuesta clara es: “No pudimos confirmar que tu dominio de correo pudiera recibir mensajes en ese momento debido a un fallo DNS temporal. Por favor inténtalo de nuevo o usa otra dirección”.
Una comprobación MX es una señal fuerte, pero no debería ser tu única puerta. El siguiente paso es convertir los resultados DNS en una política clara que tu producto aplique siempre de la misma forma.
Decide qué hacer con cada resultado. Null MX suele ser un bloqueo duro porque el dominio expresa explícitamente que no acepta correo. Un fallo DNS temporal raramente debería ser un rechazo permanente. Las malas configuraciones quedan en el medio: puedes permitir el registro pero exigir que el usuario confirme su dirección antes de realizar acciones importantes.
Un marco de política simple que muchos equipos usan es:
Luego combina resultados MX con otras comprobaciones para no sobreconfiar en DNS. Una buena cobertura suele incluir comprobaciones de sintaxis RFC, verificación básica del dominio, búsqueda MX y detección de correos desechables.
La consistencia importa tanto como la precisión. Usa códigos de motivo estables y mapea esos códigos al comportamiento del producto. Si soporte ve “dns_temporary_failure” pero los registros de analítica muestran “invalid_domain”, no podrás medir lo que realmente está ocurriendo.
Si prefieres no mantener todos los casos extremos por tu cuenta, un validador en varias etapas puede devolver una respuesta estructurada en lugar de unir llamadas separadas de DNS y listas negras. Por ejemplo, Verimail (verimail.co) combina comprobaciones de sintaxis RFC, verificación de dominio y MX, y coincidencia en tiempo real contra proveedores desechables conocidos en una sola llamada API.
Finalmente, añade un ciclo de revisión. Rastrea con qué frecuencia las advertencias se confirman luego como válidas, cuántos usuarios bloqueados contactan soporte y si los picos coinciden con incidentes de resolvedor. Ajusta reintentos y caché para que las pequeñas interrupciones no se conviertan en usuarios perdidos.
