Validación SMTP explicada: cómo funcionan realmente los validadores de correo

Validación SMTP explicada: cómo funcionan realmente los validadores de correo

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:

  1. Deténgalos. Envíe una sonda a una parte local aleatoria y evidentemente falsa. Si también devuelve 250, el dominio es catch-all.
  2. 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.
  3. Envíe en lotes pequeños y mida las aperturas y los rebotes. Si un segmento catch-all funciona, consérvelo.
  4. 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

Empieza gratis →

100 validaciones SMTP al mes, sin tarjeta de crédito.

¿Listo para limpiar tu lista de correos?

200 verificaciones gratuitas. Sin tarjeta de crédito. Validación SMTP completa en menos de 1 segundo.

🚀 Crear cuenta gratuita
MP

Milan Pasić

Milan Pasić es el fundador de N-Software y desarrollador principal de Email Validator. Lleva más de una década construyendo infraestructura de correo electrónico, herramientas de entregabilidad y sistemas de validación SMTP utilizados por miles de profesionales del marketing y desarrolladores en todo el mundo.