Cómo verificar si un correo existe sin enviar nada

Puedes determinar si una dirección de correo electrónico es real sin enviarle nada. El método no es ningún truco: es la conversación normal de entrega de correo, detenida un paso antes de la entrega.

Estas son las cuatro comprobaciones, en el orden en que deben ejecutarse, y lo que cada una puede demostrar de verdad.

1. Sintaxis

¿Cumple la dirección las reglas de una dirección de correo? Esto detecta errores tipográficos, la falta del símbolo @ y caracteres no válidos.

Es barata e instantánea, y no demuestra casi nada. asdkjhaslkdjh@gmail.com tiene una sintaxis perfectamente válida y, desde luego, no es un buzón real. Cualquier herramienta que se quede aquí es un corrector ortográfico.

2. Dominio y registros MX

Todo dominio que recibe correo publica registros MX en el DNS, que indican los servidores que aceptan correo para él. Si un dominio no tiene ninguno, no puede recibir correo y todas sus direcciones están muertas.

Puedes comprobarlo a mano:

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.

Sin registro MX y sin registro A alternativo, el dominio no puede recibir correo. El RFC 5321 establece que un remitente recurre al registro A del dominio cuando no existe MX, así que la falta de MX por sí sola es una señal fuerte, no una prueba. Un MX nulo (MX 0 .) es definitivo: el dominio ha declarado que no acepta correo. En cualquier caso, es la comprobación más barata que existe, y detecta dominios mal escritos y abandonados.

3. Comprobaciones de desechables y de rol

Dos cosas que conviene saber antes de enviar nada:

Los dominios desechables (Mailinator, Guerrilla Mail y miles más) son buzones de usar y tirar. Técnicamente el buzón es real, pero la persona que hay detrás nunca verá el mensaje.

Las direcciones de rol (info@, sales@, admin@) las leen varias personas o nadie, atraen quejas por spam y a veces se reciclan como trampas de spam.

Ninguna de las dos es un fallo definitivo. Ambas son decisiones que deberías tomar a conciencia en lugar de descubrirlas después.

4. La comprobación SMTP del buzón

Esta es la que realmente responde a la pregunta.

Te conectas al servidor de correo del dominio e inicias la conversación que iniciarías si fueras a entregar un mensaje, y te detienes antes de enviar nada:

$ telnet gmail-smtp-in.l.google.com 25

> HELO yourdomain.com
< 250 mx.google.com at your service

> MAIL FROM: <you@yourdomain.com>
< 250 2.1.0 OK

> RCPT TO: <someone@gmail.com>
< 250 2.1.5 OK                    ← el buzón existe

Si el buzón no existe:

> RCPT TO: <definitely-not-real-xyz9987661@gmail.com>
< 550-5.1.1 The email account that you tried to reach does not exist

Después, QUIT. No se envía ningún mensaje y no aparece nada en la bandeja de entrada de nadie. El comando DATA, el que realmente transmite un mensaje, no se emite nunca.

Esa diferencia entre 250 y 550 es toda la verificación de correo electrónico.

Por qué probablemente no puedes hacerlo tú mismo

Prueba ese comando telnet desde tu portátil y lo más probable es que se quede colgado. Casi todos los proveedores de internet domésticos y de la nube bloquean el puerto 25 de salida para evitar el spam. Lo medimos en dos grandes proveedores de alojamiento:

Proveedor	Puerto 25 de salida
Railway	Bloqueado
DigitalOcean	Bloqueado

Esta es la única razón por la que la verificación de correo existe como servicio de pago. La comprobación en sí es sencilla; lo difícil es estar en una red que permita hacerla, desde una IP con buena reputación y con un DNS inverso que coincida.

También conviene saberlo por cómo lo gestionan algunas herramientas. Si la comprobación SMTP de un verificador falla y el código recurre a informar valid (válido), entonces todas las direcciones de un dominio activo pasan y no se ha verificado nada en realidad. Conocemos ese fallo de primera mano: nuestro propio motor lo cometía hasta que lo descubrimos.

Lo que no se puede responder

Hay dos casos en los que el método no sirve en absoluto:

Los dominios catch-all aceptan cualquier dirección del dominio, sea real o no. Que la acepten no demuestra nada, así que no se puede confirmar nada. Escribimos sobre ello aquí.

Los proveedores que no responden con claridad. Yahoo e iCloud a menudo se niegan a confirmar o negar un buzón en la fase RCPT, así que la prueba no es concluyente. Outlook.com y Microsoft 365, en cambio, rechazan a los destinatarios desconocidos durante la conversación.

Un verificador honesto informa de ambos casos como risky (de riesgo). Un verificador que los da por válidos está adivinando y esperando que nunca lo compruebes.

En resumen

1. Sintaxis: detecta errores tipográficos, demuestra poco
2. Registros MX: muestran si un dominio puede recibir correo
3. Marcas de desechables y de rol: decisiones, no fallos
4. Comprobación SMTP del buzón: la respuesta real, cuando la red lo permite

Todo lo que no se pueda establecer debería devolverse como de riesgo. Las herramientas por las que vale la pena pagar son las que están dispuestas a decirte cuándo no lo saben.