La verificación de correo reúne evidencia técnica sobre una dirección antes de usarla. Comprueba su estructura, el dominio y la ruta de correo; cuando es posible, pregunta al servidor receptor por el destinatario. Cada respuesta aporta información, pero ninguna garantiza que un mensaje futuro llegue. Algunos servidores tampoco permiten obtener una conclusión firme.
La diferencia importa al aceptar un registro, incorporar un contacto o revisar una lista. Que la dirección parezca correcta no basta para tomar esas decisiones.
Tres preguntas que suelen llamarse «validación»
Conviene separar el formato, la recepción de correo y el control del buzón:
| Pregunta | Método | Qué permite saber |
|---|---|---|
| ¿Está bien formada la dirección? | Validación de sintaxis | Su parte local y su dominio cumplen las reglas de estructura. No demuestra que existan. |
| ¿Puede recibir correo? | Verificación previa al envío | Qué indican el DNS, la ruta y, cuando se obtiene, la respuesta del servidor receptor. |
| ¿Controla alguien ese buzón? | Confirmación por correo | Alguien ha usado en ese momento un enlace o código enviado a la dirección. |
Para decidir si una comprobación puede sustituir al enlace de confirmación, consulta la comparación entre verificación y confirmación de correo.
A veces «validación de correo» nombra todo el proceso. Si una herramienta solo revisa el formato, su alcance es más limitado. La comparación entre SMTP y sintaxis ayuda a elegir el nivel de comprobación.
Las cinco etapas de la verificación
Emvero avanza mientras la evidencia lo permite. Un fallo claro puede cerrar la comprobación antes de contactar con un servidor de correo. Incluso una verificación completa puede terminar en unknown.
1. Sintaxis: ¿tiene forma de dirección?
Se analiza la parte local anterior a @, el dominio posterior y la dirección completa. Un error de formato se detecta sin consultar la red. Superar esta etapa no prueba que exista el dominio ni el buzón. La entrada sobre sintaxis de correo explica las reglas.
Para incorporar ese primer paso a un formulario, consulte el ejemplo de validación de correo con JavaScript.
2. Dominio: ¿lo reconoce el DNS?
Una respuesta inequívoca de dominio inexistente es evidencia negativa. Si el dominio existe, la comprobación continúa: puede tener una web y no aceptar correo. El DNS por sí solo no informa sobre un destinatario concreto.
3. Ruta: ¿adónde iría el mensaje?
Los registros MX suelen indicar qué servidores reciben el correo del dominio. Un MX nulo anuncia expresamente que el dominio no acepta mensajes. La ausencia de MX, en cambio, no basta para rechazarlo: SMTP permite una ruta implícita por el host del dominio. La guía de registros MX distingue los casos. Una ruta válida habla del dominio, no demuestra que exista un buzón concreto. La ruta implícita se define en RFC 5321, sección 5.1, y el MX nulo en RFC 7505.
La comprobación de dominio termina en este punto y no abre una sesión SMTP. Para obtener evidencia sobre el destinatario hace falta una verificación completa.
4. Destinatario: ¿qué contesta el servidor?
Cuando el destino lo permite, la verificación completa abre una conversación SMTP y nombra al destinatario. El servidor puede aceptarlo, rechazarlo, aplazar la respuesta u ocultar su política. Incluso una respuesta clasificada como «buzón inexistente» queda en unknown según la política actual de Emvero; no descarta automáticamente la dirección. Un dominio cuya inexistencia se haya establecido o un MX nulo sí pueden justificar undeliverable antes de SMTP. La aceptación aporta evidencia positiva, pero también puede deberse a una regla catch-all.
El sondeo se detiene en el sobre del mensaje:
EHLO verifier.example
MAIL FROM:<probe@verifier.example>
RCPT TO:<person@example.com>
RSET
QUIT
DATA iniciaría el contenido. Emvero no llega a ese paso durante la verificación y no envía ningún mensaje de confirmación. RFC 5321, sección 3.3 describe el intercambio y señala que algunos servidores retrasan la decisión sobre el destinatario. La entrada sobre el intercambio SMTP amplía el mecanismo.
5. Clasificación: ¿qué permiten concluir los datos?
Emvero combina las observaciones con señales como un dominio catch-all, un proveedor de correo temporal, una posible errata en el dominio o una dirección genérica como support@. Una dirección temporal o genérica puede recibir mensajes sin problemas. Decidir si encaja en un flujo concreto corresponde a quien lo gestiona. Si el servidor acepta nombres arbitrarios, la aceptación de uno no prueba que exista ese buzón.
Cuando no hay respuesta concluyente
Un servidor puede limitar el ritmo del sondeo, aplazar la respuesta u ocultar sus destinatarios. También puede agotarse el tiempo de conexión. Ninguno de esos hechos constituye un rechazo permanente. Una respuesta positiva a RCPT TO en un dominio catch-all tampoco identifica un buzón individual. Por eso una comprobación ya terminada puede ser risky o unknown.
Interpretar el resultado sin perder la evidencia
Hay cuatro valores finales de status:
status |
Lectura |
|---|---|
deliverable |
La ruta y la evidencia disponible sobre el destinatario apoyan la aceptación, sin garantizar entregas futuras. |
risky |
El correo podría llegar, pero hay una señal concreta que conviene revisar. |
undeliverable |
Un motivo técnico permanente apoya el rechazo. |
unknown |
La evidencia obtenida no permite resolver la dirección. |
pending indica que el trabajo sigue en cola o en curso. Es un estado de transporte, no un quinto dictamen. Hay que consultar el resultado después del intervalo indicado.
Los demás campos muestran cómo se llegó a la conclusión. checks recoge lo observado en cada etapa, reason_codes identifica las señales y freshness fecha las observaciones DNS y SMTP. confidence es una puntuación de la evidencia, no una probabilidad de entrega. action recomienda allow, allow_with_email_confirmation o reject. No se deduce automáticamente de status: un resultado risky puede llevar allow o allow_with_email_confirmation según su causa. El artículo sobre cómo leer un resultado explica los campos; la página de la API de verificación muestra la respuesta técnica.
Aplicar el resultado en cada caso
Para una dirección concreta, conviene leer los motivos junto al estado. unknown significa que falta evidencia, no que la dirección sea inválida. Es posible comprobar una dirección y ver ambas cosas.
Durante el registro o la compra, un rechazo técnico claro permite pedir una corrección. Una posible errata puede resolverse en el momento. Si importa demostrar el control del buzón y el resultado es risky o unknown, puede seguir una confirmación por correo. La guía para formularios de registro explica cómo tomar esa decisión.
En una lista existente, conviene separar los fallos demostrados, los riesgos y los casos abiertos. freshness ayuda a no tratar observaciones antiguas como hechos permanentes. Una dirección temporal o genérica sigue siendo una decisión de política aunque funcione técnicamente.
La verificación no demuestra identidad, consentimiento, interés, llegada a la bandeja de entrada ni entrega futura. La confirmación solo indica que alguien controlaba el buzón cuando actuó sobre el mensaje. Cada decisión necesita la evidencia que realmente la sustenta.