La mayoría de los verificadores de correo afirman ser precisos. Pocos explican cómo verifican realmente una dirección.
Esta es esa explicación.
¿Qué es SMTP?
SMTP = Simple Mail Transfer Protocol (Protocolo simple de transferencia de correo)
Es el lenguaje que usan los servidores de correo para enviar y recibir correos electrónicos.
Cuando envías un correo electrónico:
1. Tu cliente se conecta a un servidor SMTP
2. Envía MAIL FROM: you@yourcompany.com
3. Envía RCPT TO: recipient@their.com
4. El servidor responde 250 OK (yes, we accept it) or 550 Reject (no, we don't)
5. El cliente envía el cuerpo del mensaje
Validación SMTP: la comprobación real
Validación SMTP simula los pasos 1–4 sin enviar el correo electrónico real.
Por eso es la única forma de saber si un buzón realmente existe.
El intercambio SMTP
→ Cliente: EHLO correo.validador.com
← Servidor: 250 OK ESMTP
→ Cliente: MAIL FROM:<validador@mail.validador.com>
← Servidor: 250 OK
→ Cliente: RCPT TO:<test@gmail.com>
← Servidor: 250 OK
(buzón existe y acepta correo)
→ Cliente: QUIT
← Servidor: 221 Adiós
Si el RCPT TO returns 250, la dirección es Válidas.
Si devuelve 550, la dirección es No válidos.
Si el servidor no responde, es Arriesgado o Desconocido.
Por qué fallan otros métodos
❌ Solo verificación de sintaxis
test@example.com ✅ (parece bueno)
test.12345@example.com ❌ (podría No existen)
La sintaxis es correcta, pero no sabemos si el buzón existe.
❌ Solo verificación de registros MX
Dominio: gmail.com → MX: aspmx.l.google.com (sí, existe)
Pero: hace test@gmail.com realmente existen? Desconocido.
✅ Validación SMTP
Conectar a gmail SMTP → RCPT TO test@gmail.com
← 550 No tal usuario
Resultado: NO VÁLIDO (buzón doesn't existen)
El desafío: dominios catch-all
Algunos servidores (especialmente los más antiguos) dicen "sí" a a cada dirección:
→ RCPT TO: usuarioreal@company.com
← 250 OK
→ RCPT TO: usuariofalso123456789@company.com
← 250 OK (también aceptó!)
Estas son dominios catch-all. La verificación SMTP por sí sola no puede saber si es real.
Avanzado: puntuación + detección de catch-all
Los mejores validadores combinan SMTP con otras señales:
- Reputación del dominio — ¿se sabe que el servidor de correo rebota los mensajes?
- Actividad reciente — ¿estuvo activo este dominio en los últimos 90 días?
- Comprobaciones de honeypot — ¿es una trampa de spam conocida?
- Marca de riesgo + catch-all — "Válido por SMTP, pero podría ser catch-all"
Puntuación de 0 a 10 = nivel de confianza, no solo aprobado o suspendido.
Velocidad frente a precisión
| Método | Velocidad | Precisión | Coste |
|---|---|---|---|
| Sintaxis | <1 ms | 60% | Gratis |
| Comprobación MX | 50 ms | 75% | Gratis |
| SMTP | 500 ms–2 s | 95% | ¢ |
| SMTP + puntuación | 1–5 s | 99% | ¢¢ |
Por qué importa la validación SMTP
✅ Protege la reputación del remitente — verifica antes de enviar
✅ Reduce las tasas de rebote — SMTP detecta los inválidos antes del envío
✅ Ahorra créditos — no pagues al ESP por los correos rebotados
✅ Mejora la entregabilidad — los ISP premian los envíos limpios
Cómo verificarlo tú mismo (solo desarrollo)
import smtplib
dominio = "gmail.com"
try:
smtp = smtplib.SMTP(f"mx.{dominio}")
smtp.correo("test@validator.com")
code, msg = smtp.rcpt("recipient@gmail.com")
if code == 250:
print("Valid")
else:
print("Invalid")
smtp.quit()
except:
print("Risky/Unknown")
Pero en producción, usa un servicio. La validación SMTP a gran escala es compleja (cortafuegos, límites de tasa, retrasos).
SMTP en más detalle
SMTP es un protocolo de texto. Una sesión es una conversación breve con una secuencia de comandos y respuestas numéricas. Para la validación, solo importa la primera mitad: la parte anterior al envío de cualquier cuerpo del mensaje.
Puertos y TLS
- 25 — el puerto clásico de servidor a servidor. Los proveedores de alojamiento suelen bloquearlo para frenar el spam, por lo que los servicios de validación utilizan infraestructura dedicada.
- 465 — TLS implícito (SMTPS).
- 587 — puerto de envío con STARTTLS, utilizado por los clientes de correo.
Un validador necesita alcanzar el puerto 25 del MX del destinatario. Si tu propio servidor no puede conectarse al puerto 25, no podrás realizar comprobaciones SMTP fiables por tu cuenta; este es el motivo más común por el que los equipos externalizan la verificación.
EHLO, MAIL FROM, RCPT TO
→ EHLO validador.example.com
← 250-correo.example.com
← 250-PIPELINING
← 250 SIZE 35882577
→ MAIL FROM:<comprobación@validator.example.com>
← 250 OK
→ RCPT TO:<person@example.com>
← 250 OK
EHLO opens the session and asks which extensions the server supports. MAIL FROM declares the envelope sender. RCPT TO is the actual test: the server accepts or rejects the recipient. QUIT ends the session.
El punto clave: RCPT TO recibe respuesta antes de que se envíe cualquier dato del mensaje. Eso es lo que hace posible la validación sin entregar correo.
Interpretación de los códigos de respuesta SMTP
| Código | Significado | Interpretación de la validación |
|---|---|---|
| 250 | Acción solicitada completada | Válido (salvo catch-all) |
| 251 | Usuario no local, será reenviado | Válidas |
| 450 | Buzón no disponible, inténtalo más tarde | Arriesgado |
| 451 | Error local, inténtalo más tarde | Arriesgado |
| 452 | Almacenamiento insuficiente | Riesgoso (buzón lleno) |
| 550 | Buzón no disponible | No válidos |
| 551 | Usuario no local | No válidos |
| 552 | Almacenamiento superado | Arriesgado |
| 553 | Nombre de buzón no permitido | No válidos |
| 421 | Servicio no disponible | Desconocido, reintente |
Un validador que trata cada respuesta distinta de 250 como "no válida" es incorrecto: los códigos 4xx son temporales y suelen resolverse al reintentar.
Por qué las comprobaciones de sintaxis y de registros MX no son suficientes
Ambas son económicas y útiles como primer filtro, pero ninguna puede responder a la única pregunta que importa: ¿acepta este buzón correo?
- Sintaxis indica que la cadena parece una dirección de correo. No puede detectar que la empresa cerró.
- MX indica que el dominio tiene un servidor de correo. No puede detectar que
person@was never created. - SMTP se comunica con ese servidor y pregunta por ese destinatario concreto. Solo este paso ofrece una respuesta real.
En la práctica, una lista que supera las comprobaciones de sintaxis y MX puede seguir rebotando entre un 20 y un 30 %. Por eso las herramientas de "comprobador de correo gratuito" que solo aplican expresiones regulares son populares, pero inútiles para el trabajo de entregabilidad.
Dominios catch-all en profundidad
Un servidor catch-all está configurado para aceptar correo para cualquier parte local. Es una configuración legítima —las empresas la usan para que una errata en la dirección de un prospecto no desaparezca en silencio—, pero rompe la validación SMTP.
Cómo gestionar los catch-all:
- Deténgalos. Envíe una sonda a una parte local aleatoria y evidentemente falsa. Si también devuelve 250, el dominio es catch-all.
- Marque, no elimine. Las direcciones catch-all suelen pertenecer a personas reales. Eliminarlas puede costar entre un 5 y un 15 % de una lista B2B.
- Envíe en lotes pequeños y mida las aperturas y los rebotes. Si un segmento catch-all funciona, consérvelo.
- Utilice señales adicionales —reputación del dominio, historial de interacción y patrones de coincidencia— para priorizar las direcciones catch-all.
Greylisting, límites de tasa y anti-recolección
Los servidores de correo reales no son entornos de prueba. Espera:
- Greylisting — el servidor rechaza temporalmente a los remitentes nuevos con un código 4xx y espera un reintento. Los servicios de validación reintentan automáticamente.
- Limitación de tasa — demasiadas conexiones desde una misma IP se ralentizan. Los buenos proveedores reparten las comprobaciones entre varias IP y en el tiempo.
- Anti-recolección — algunos servidores responden deliberadamente de forma ambigua a quien sondea muchas direcciones.
- Honeypots — direcciones que existen únicamente para detectar remitentes masivos. Un buen validador las marca.
Por eso los scripts de validación caseros funcionan con diez direcciones y se desmoronan con diez mil.
Tiempo real frente a lotes, y el patrón asíncrono
- Tiempo real es el adecuado para formularios de registro y pagos: una dirección, una respuesta inmediata, con un tiempo de espera estricto para que el usuario nunca espere más de uno o dos segundos.
- Por lotes es el adecuado para listas: miles de direcciones, reintentos y un archivo de resultados que puedes segmentar.
- Asíncrono es el patrón de producción para ambos: pon la dirección en cola, devuelve la respuesta de inmediato, verifica en segundo plano y actualiza el registro cuando llegue el resultado.
Nunca bloquees un hilo de petición esperando un handshake SMTP remoto. Un servidor lento o hostil puede mantener la conexión durante 30 segundos o más.
Un mejor ejemplo en Python
import smtplib
import dns.resolver
def comprobación(dominio: str, física: str, timeout: int = 10) -> str:
try:
mx = str(dns.resolver.resolve(dominio, "MX")[0].exchange).rstrip(".")
with smtplib.SMTP(mx, 25, timeout=timeout) as smtp:
smtp.ehlo_or_helo_if_needed()
smtp.correo("check@validator.example.com")
code, _ = smtp.rcpt(física)
if code a (250, 251):
return "valid"
if code a (450, 451, 452, 552):
return "risky"
if code a (550, 551, 553):
return "invalid"
return "unknown"
except Excepción:
return "unknown"
Incluso esta versión simplificada tiene problemas a gran escala: ignora el greylisting, no detecta los catch-all, usa una sola IP y será bloqueada por los proveedores que limitan la frecuencia de peticiones. Es una herramienta de aprendizaje, no un validador para producción.
Limitaciones y ética
Ningún validador puede garantizar la entregabilidad. Los buzones se cierran entre la comprobación y el envío; los servidores cambian sus políticas; una dirección "válida" también puede quedar abandonada. Usa la verificación para eliminar fallos previsibles, no para prometer una campaña con cero rebotes.
Desde el punto de vista ético, valida únicamente las direcciones a las que tengas una base legal para contactar. La sonda SMTP es una operación técnica, pero no genera consentimiento, y usar la validación para dar apariencia de legalidad a una lista comprada no hace legal el envío.
Lo que la validación no puede ver
- Interacción — una dirección válida puede que nunca abra tu correo.
- Intención — una persona real puede no querer tu oferta.
- Consentimiento — una dirección entregable no es una base legal.
- Estado futuro — un buzón puede cerrarse el día después de verificarlo.
La verificación elimina la incertidumbre técnica. Todo lo demás sigue siendo marketing.
Prueba primero tu propio dominio
Antes de validar una lista, valida tu dominio de envío:
- Envía una prueba a un buzón que controles en Gmail, Outlook y un dominio corporativo.
- Comprueba la alineación de SPF, DKIM y DMARC.
- Vigila de cerca los primeros 200 envíos de cualquier dominio nuevo; el calentamiento importa más que cualquier verificación puntual.
Una lista limpia enviada desde un dominio con autenticación defectuosa acabará igualmente en spam.
Preguntas frecuentes
¿La validación SMTP envía un correo electrónico?
No. Se detiene en RCPT TO, before any message body is transmitted.
¿Por qué algunas direcciones válidas aparecen como arriesgadas?
Por el greylisting, errores temporales del servidor o políticas contra la recolección de direcciones. Vuelve a intentarlo después de 24–48 horas.
¿Puedo validar desde mi propio servidor?
Solo si puede acceder al puerto 25 y no está limitado en frecuencia ni en listas negras. La mayoría de los hosting compartidos lo bloquean.
¿La detección de catch-all es fiable?
Te indica de forma fiable que el dominio es catch-all. No puede decirte si un buzón concreto existe.
¿Qué precisión debo esperar?
Un buen validador basado en SMTP acierta alrededor del 95–99 % de las veces; la incertidumbre restante se debe sobre todo a los catch-all y a los fallos temporales.
SPF, DKIM y DMARC en un párrafo cada uno
- SPF enumera los servidores autorizados a enviar correo en nombre de tu dominio. Es un registro TXT de DNS y deja de funcionar si superas el límite de 10 consultas.
- DKIM añade una firma criptográfica a cada mensaje para que el receptor pueda comprobar que no ha sido alterado. Rota las claves periódicamente.
- DMARC indica a los receptores qué hacer cuando fallan SPF o DKIM (none, quarantine, reject) y te envía informes. Empieza con
p=none, read the reports, then tighten.
La validación SMTP comprueba el destinatario; SPF, DKIM y DMARC determinan si tu propio correo es confiable al salir. Una lista verificada enviada desde un dominio con la autenticación mal configurada seguirá fallando. Configura los informes de DMARC antes de escalar una campaña: los informes son la forma de encontrar los remitentes que habías olvidado.
Empieza a validar
100 validaciones SMTP al mes, sin tarjeta de crédito.