Validación de sintaxis vs. comprobación MX vs. verificación SMTP: qué detecta cada una

Una validación de sintaxis confirma que una dirección de correo electrónico está bien formada. Una comprobación MX confirma que el dominio publica servidores de correo. Una comprobación SMTP le pregunta a ese servidor si el buzón concreto existe. Cada una detecta fallos que la anterior no puede ver, y solo la última dice algo sobre la persona. Las consultas reales de abajo muestran exactamente dónde se detiene cada capa.

La mayoría de las explicaciones sobre esto se quedan en "la sintaxis es débil, el MX es mejor y el SMTP es lo mejor". Es cierto, pero oculta la parte interesante: cada capa tiene casos límite en los que la lectura obvia es incorrecta. Hicimos las consultas DNS de este artículo el 1 de octubre de 2026 con dig, desde una conexión normal. La salida sin procesar está en nuestras notas de investigación.

Las tres capas de un vistazo

Cada capa responde a una pregunta distinta, y ninguna puede responder la de la siguiente.

Capa	Pregunta que responde	Coste	Detecta	No puede detectar
Sintaxis	¿Tiene esto forma de dirección de correo?	Microsegundos, sin red	Falta de @, espacios, puntos dobles, partes demasiado largas	Dominios con errores tipográficos, dominios muertos, buzones muertos
MX / DNS	¿Puede este dominio recibir correo?	Una consulta DNS	Dominios inexistentes, MX nulo, la mayoría de los dominios con errores tipográficos	Buzones muertos en dominios activos
SMTP RCPT TO	¿Aceptará este servidor correo para este buzón?	Una conexión TCP en el puerto 25, unos segundos	Buzones eliminados y buzones que nunca existieron	Dominios catch-all, servidores que aceptan y luego rebotan

Capa 1: sintaxis

La validación de sintaxis rechaza las entradas que no pueden ser una dirección, y nada más. Es la única capa que funciona sin red, lo que la hace ideal para dar respuesta instantánea en un formulario e inútil como veredicto.

Lo que detecta legítimamente:

Entrada	Por qué falla
jane.doe.example.com	No tiene @
jane doe@example.com	Espacio sin comillas
jane..doe@example.com	Puntos consecutivos en una parte local sin comillas
jane@	No tiene dominio
Una parte local de 70 caracteres	La sección 4.5.3.1.1 del RFC 5321 limita la parte local a 64 octetos

Lo que deja pasar, y con razón, porque todas tienen una sintaxis válida:

• asdkjhaslkdjh@gmail.com: bien formada, y desde luego no es una persona.
• jane@gmial.com: bien formada, dominio equivocado.
• jane+newsletter@gmail.com: bien formada y real. Las direcciones con signo más son legítimas, y una regex estricta que las rechace está rechazando a usuarios reales.

El error habitual es ir en la dirección contraria y escribir una regex tan estricta que rechaza direcciones válidas. Explicamos por qué en por qué falla la validación de correo con regex. En un proceso de verificación, la sintaxis solo tiene que ser lo bastante estricta para frenar la basura antes de gastar una consulta DNS en ella.

Capa 2: MX y DNS

La capa MX le pregunta al DNS qué servidores aceptan correo para el dominio, y la respuesta puede tener más de dos formas. La mayoría de las guías la tratan como un sí o un no. Esto es lo que obtuvimos realmente para ocho dominios:

Dominio	Estado DNS	Respuesta MX	Qué significa
gmail.com	NOERROR	Cinco hosts MX de Google	Puede recibir correo
outlook.com	NOERROR	outlook-com.olc.protection.outlook.com	Puede recibir correo
nonexistent-domain-zz918273.com	NXDOMAIN	ninguna	El dominio no existe. Inválido, con certeza
example.com	NOERROR	0 .	MX nulo: declara explícitamente que no acepta correo
yahoo.co	NOERROR	0 .	MX nulo. Un error tipográfico de yahoo.com que rechaza el correo
gmial.com	NOERROR	ninguna, pero existe un registro A	Sin MX. Consulta la regla del MX implícito más abajo
gmai.com	NOERROR	1 mail.h-email.net.	Un dominio con error tipográfico con un MX que funciona
hotmial.com	SERVFAIL en la primera consulta, después 5 mail.h-email.net.	Un fallo temporal de DNS y luego un MX que funciona	Reintenta; nunca decidas con un SERVFAIL

En esa tabla hay cuatro lecciones.

Un MX nulo es un "no" definitivo

example.com y yahoo.co publican un único registro MX que apunta a . con preferencia 0. Eso es un MX nulo, definido en el RFC 7505: "Para indicar que un dominio no acepta correo, anuncia un único RR MX ... con ... número de preferencia 0 y una etiqueta de longitud cero". Una comprobación ingenua que solo pregunta "¿hay un registro MX?" ve un registro y da el dominio por bueno. Una correcta reconoce el punto y marca como fallidas todas las direcciones de ese dominio. Puedes comprobar cualquier dominio con la herramienta de consulta MX.

Sin MX no es exactamente lo mismo que sin correo

gmial.com no tiene registros MX, pero sí un registro A. Según la sección 5.1 del RFC 5321, "Si se devuelve una lista vacía de MX, la dirección se trata como si estuviera asociada a un RR MX implícito ... que apunta a ese host". Dicho de otro modo, se supone que un servidor remitente debe intentarlo con el registro A.

En la práctica, un dominio sin MX y con solo una página web aparcada casi nunca tiene un servidor de correo, así que el intento de entrega falla. Pero el comportamiento estrictamente correcto es tratar "sin MX, con registro A" como "intenta con ese host en el puerto 25", y darlo por fallido solo si nada responde. Tratarlo como inválido al instante suele ser correcto y, de vez en cuando, no lo es.

Los dominios con errores tipográficos pueden superar la comprobación MX

gmai.com y hotmial.com publican un MX que apunta al mismo host de terceros, mail.h-email.net. El correo enviado ahí no le llega a la persona que escribió mal su dirección de Gmail. La capa MX no puede decírtelo. Informa, con exactitud, de que el dominio recibe correo. Por eso la detección de errores tipográficos es una comprobación aparte del DNS: compara el dominio con una lista de errores conocidos en los nombres de los grandes proveedores. Consulta cómo detectar errores tipográficos en el correo durante el registro.

SERVFAIL no es NXDOMAIN

Nuestra primera consulta para hotmial.com devolvió SERVFAIL. Una segunda devolvió un registro MX. El RFC 5321 es explícito: un dominio inexistente "DEBE notificarse como error", mientras que "Si se devuelve un error temporal, el mensaje DEBE ponerse en cola y reintentarse más tarde". Un verificador que marca un SERVFAIL como inválido borrará direcciones reales cada vez que un servidor DNS tenga un mal momento.

Capa 3: la comprobación SMTP del buzón

La comprobación SMTP es la única capa que pregunta por el buzón y no por el dominio. El verificador se conecta al host MX de mayor prioridad en el puerto 25, se presenta, indica un remitente y luego indica el destinatario con RCPT TO. El código de respuesta del servidor es la respuesta, y la conexión se cierra antes de enviar ningún mensaje. La conversación completa aparece paso a paso en cómo verificar si un correo existe sin enviar nada.

Lo que detecta y las capas anteriores no pueden:

Dirección	Sintaxis	MX	SMTP
former.employee@company.com (buzón eliminado)	Supera	Supera	Rechazada, 550 5.1.1
random-string-xyz@gmail.com	Supera	Supera	Rechazada, 550 5.1.1
real.person@gmail.com	Supera	Supera	Aceptada, 250

Esta es la capa que importa para los rebotes duros en una lista de personas reales. Cuando la gente deja su trabajo o abandona sus cuentas, el dominio sigue funcionando y solo muere el buzón, así que solo esta capa lo ve.

Dónde se detiene el SMTP

La capa SMTP tiene sus propios límites, y por eso existe un cuarto resultado, risky (riesgoso):

• Los dominios catch-all responden 250 a todas las direcciones, incluidas las que no pueden existir. Un buen verificador prueba primero una dirección aleatoria para detectarlo. Consulta qué es un dominio catch-all.
• Los proveedores que aceptan y luego rebotan dicen 250 en el RCPT TO y rebotan después. Yahoo es el ejemplo más conocido, que tratamos en por qué las direcciones de Yahoo son difíciles de verificar.
• El greylisting y los tiempos de espera agotados devuelven un código temporal 4xx o nada en absoluto. Reintenta más tarde.
• El puerto 25 bloqueado en el lado del verificador. La comprobación nunca llega a hacerse. Lo medimos en hosts en la nube en los proveedores de nube bloquean el puerto 25.

En todos esos casos, la respuesta honesta es riesgoso o desconocido. Devolver válido es adivinar.

Qué capas necesitas, según la situación

Usa tantas capas como te permita tu margen de latencia, y nunca te quedes solo en la sintaxis para algo a lo que piensas enviar correo.

Situación	Capas que aplicar	Por qué
Campo de formulario en vivo, mientras el usuario escribe	Solo sintaxis	Respuesta instantánea, sin llamadas de red
Envío del formulario	Sintaxis + MX + comprobación de errores tipográficos, y SMTP si responde dentro de tu tiempo límite	Consulta la verificación en tiempo real en formularios de registro
Lista de correo en frío (cold email) antes de una campaña	Las tres, más la detección de catch-all	Un buzón muerto cuesta reputación, no solo un envío desperdiciado
Lista antigua de newsletter que vuelves a usar	Las tres	El deterioro está en la capa del buzón, que la sintaxis y el MX no pueden ver
Limpieza de datos en un CRM, sin envíos previstos	Sintaxis + MX	Barato, y encuentra los dominios muertos

Cómo las aplica SimpleVerifier

Aplicamos las tres capas en orden y nos detenemos en cuanto una da una respuesta definitiva: una sintaxis rota o un dominio sin servidor de correo devuelve invalid (inválido) sin abrir una conexión SMTP. Los dominios activos pasan a la comprobación RCPT TO. Todo lo que el servidor de correo no confirma, incluidos los dominios catch-all, se devuelve como risky (riesgoso), nunca como valid (válido).

En resumen

La sintaxis es un filtro, el MX es una prueba del dominio y el SMTP es la prueba del buzón. Si una herramienta o un script que escribiste se detiene en el MX, te está diciendo que el dominio funciona y nada sobre la persona. Antes de fiarte de cualquiera de ellas, lee bien la respuesta DNS: NXDOMAIN y MX nulo son fallos definitivos, SERVFAIL es un reintento, y un dominio con error tipográfico y un MX activo es un problema que ninguna consulta DNS va a señalar.

Para ver las tres capas aplicadas a una sola dirección, prueba la herramienta gratuita de verificación de correo.