Cómo verificar si un email existe sin enviar un correo

Sí, se puede saber si una dirección de correo probablemente existe sin enviarle nada. Se comprueba el formato, que el dominio tenga servidores de correo y, por último, se pregunta al servidor si aceptaría un mensaje para ese buzón, cortando la conversación antes de enviar. La respuesta no siempre es un sí o un no: los dominios que aceptan cualquier dirección y los servidores que no contestan dejan casos inciertos, y conviene saber qué hacer con cada uno.

Las cuatro comprobaciones, de un vistazo

Cada paso es más preciso y más lento que el anterior. Por eso se hacen en orden: no tiene sentido preguntar a un servidor por un buzón de un dominio que no existe.

Qué significa cada veredicto y qué hacer

Formato y dominio: lo que puedes comprobar tú

1. Formato

Una dirección tiene una parte local, una arroba y un dominio, y sus reglas están en los estándares de internet (RFC 5322 y RFC 5321). Por ejemplo, la parte local admite hasta 64 caracteres. En la práctica, esta comprobación atrapa sobre todo errores de escritura:

• dominios mal tecleados, como gmial.com o hotmial.com;
• terminaciones erróneas, como .con en lugar de .com;
• espacios, comas o dos arrobas en la misma dirección.

Las tildes y la eñe merecen una mención aparte. Una dirección con «ñ» en la parte local solo funciona si los servidores de ambos lados admiten el correo internacionalizado (RFC 6531), y no todos lo hacen. Por eso lo habitual es que las direcciones de empresa se escriban sin tildes ni eñes.

2. Dominio y registros MX

El dominio tiene que existir y tener dónde recibir correo. Eso lo indican sus registros MX en el DNS, que apuntan a los servidores de correo del dominio. Si un dominio no tiene registros MX, el estándar permite entregar el correo en la dirección del propio dominio (RFC 5321, apartado 5.1); si publica un «MX nulo», está declarando que no acepta correo (RFC 7505).

Esta comprobación descarta, por ejemplo, las direcciones de negocios que cerraron o que se cambiaron de dominio y dejaron caducar el antiguo.

Estas dos comprobaciones las puedes hacer tú: la primera a simple vista y la segunda con cualquier herramienta de consulta DNS. Las dos siguientes exigen hablar con el servidor de correo del dominio, y para una lista conviene usar un servicio. En Glintscout, la verificación es el paso que sigue a la búsqueda de negocios y emails (por ejemplo, en Google Maps): contacta con el servidor de correo sin enviar ningún email, una segunda verificación opcional vuelve a comprobar las direcciones desconocidas y el CSV que descargas solo incluye las válidas.

La consulta al servidor, sin enviar el mensaje

3. La conversación SMTP, paso a paso

Enviar un email es una conversación entre servidores con pasos fijos. El verificador sigue esa conversación hasta el punto en que el servidor dice si aceptaría al destinatario, y se despide antes de mandar ningún contenido:

1. Se conecta al servidor de correo del dominio, el que indica su registro MX.
2. Se presenta (EHLO) e indica desde qué dirección escribiría (MAIL FROM).
3. Indica el destinatario (RCPT TO). La respuesta a este paso es la que importa.
4. Cierra la conexión (QUIT) sin llegar al paso en el que se envía el mensaje (DATA).

El servidor contesta con códigos de tres cifras (RFC 5321, apartado 4.2.1). Los que empiezan por 2 significan que acepta, los que empiezan por 4 son un fallo temporal («inténtalo más tarde») y los que empiezan por 5 son un rechazo permanente. Un «550 5.1.1» es el clásico «ese buzón no existe»; el 5.1.1 es un código ampliado definido en el RFC 3463.

Existe un comando pensado para preguntar si un buzón existe (VRFY), pero el propio estándar admite que los servidores lo desactiven por seguridad, y es habitual que lo hagan. Por eso se usa el paso del destinatario.

Hacer esto a gran escala desde tu propio servidor es mala idea. Los servidores de correo detectan las consultas repetidas y pueden bloquear tu IP o tu dominio, y entonces el problema ya no es verificar, sino enviar.

4. La prueba de catch-all

Antes de dar por buena una dirección, se pregunta al mismo servidor por otra inventada del mismo dominio, algo como [email protected]. Si también la acepta, el dominio acepta cualquier dirección y la respuesta sobre la tuya no demuestra nada: es un dominio catch-all.

Por qué a veces no hay respuesta clara

Greylisting

Algunos servidores rechazan temporalmente al remitente que no conocen, con un código que empieza por 4, y esperan a que vuelva a intentarlo, como hace cualquier servidor de envío legítimo. Es el greylisting, descrito en el RFC 6647. Una comprobación única solo ve un «inténtalo más tarde», así que el veredicto honesto es «desconocido».

Servidores que no contestan o que limitan

Tiempos de espera agotados, límites de conexiones por remitente, filtros antiabuso: el resultado también es «desconocido». No significa que la dirección sea mala, sino que ese día no se pudo saber. Repetir la comprobación unas horas después resuelve parte de estos casos.

Servidores que aceptan todo y rechazan después

Algunos proveedores aceptan cualquier destinatario durante la conversación y deciden más tarde, de modo que la consulta no aporta información. La prueba de catch-all existe precisamente para detectarlos: si la dirección inventada también se acepta, la tuya no se da por válida.

Qué hacer con las direcciones catch-all

Un catch-all no es una dirección mala: puede que el buzón exista y lo lea alguien. El problema es que no lo sabes, y si no existe, el mensaje puede rebotar más tarde o perderse sin aviso. Estas son las opciones razonables:

• Cambia lo adivinado por lo publicado. Si la dirección la has deducido (nombre@), usa mejor una que publique la propia web del negocio: en un dominio catch-all, lo publicado es más fiable que lo adivinado.
• Envía en un segmento aparte y con poco volumen, y mira los rebotes antes de seguir.
• Déjalas fuera si tu dominio de envío es nuevo o ya has tenido problemas de entregabilidad.

Cuándo volver a verificar

• Antes de cada campaña, si la última verificación tiene más de unas semanas. Es una regla práctica: los buzones se cierran y las empresas cambian de proveedor de correo.
• Después de importar una lista comprada o heredada, siempre.
• Tras un envío con muchos rebotes, para limpiar lo que quede.
• Las desconocidas, unas horas o un día después, para dar tiempo al greylisting.

Si estás montando la lista desde cero, la verificación va justo antes de exportar. Lo contamos paso a paso en cómo crear una lista de leads B2B por ciudad y nicho.

Rebotes y reputación: lo que se juega tu dominio

Un rebote duro es un rechazo permanente: el buzón o el dominio no existen. Un rebote blando es temporal: buzón lleno, servidor caído. Los duros son los que más dañan tu reputación como remitente, porque los proveedores de correo los leen como señal de una lista descuidada. Una regla práctica habitual es mantenerlos por debajo del 2 %.

La verificación también te ayuda con los requisitos de los grandes proveedores. Google exige a todos los remitentes autenticar su correo con SPF o DKIM y mantener la tasa de spam que muestra Postmaster Tools por debajo del 0,3 %. Quien envía más de 5000 mensajes al día a cuentas personales de Gmail necesita además SPF y DKIM a la vez, DMARC y la baja con un clic en los mensajes de marketing (directrices de Google para remitentes).

Yahoo tiene requisitos muy parecidos (requisitos de Yahoo para remitentes). Una lista limpia no garantiza cumplirlos, pero una sucia te lo pone mucho más difícil.

Lo que la verificación no hace

• No te da permiso para escribir. En España, la LSSI prohíbe enviar publicidad por email que no se haya solicitado o autorizado antes, también a empresas. Lo explicamos en ¿Es legal el email frío B2B en España?.
• No garantiza la bandeja de entrada. Que el buzón exista no dice si tu mensaje llegará a la bandeja principal: eso depende de tu reputación, tu autenticación y tu contenido.
• No dura para siempre. Es una foto del momento de la comprobación.
• No te exime del RGPD. Si subes a un servicio de verificación direcciones de personas (nombre.apellido@), ese servicio trata datos personales por encargo tuyo, y el RGPD exige un contrato de encargo del tratamiento (artículo 28).

Preguntas frecuentes

¿Verificar un email avisa al destinatario?

No. No se entrega ningún mensaje, así que el destinatario no ve nada en su bandeja. El servidor sí anota la conexión en sus registros técnicos, como anota cualquier otra.

¿La verificación es 100 % fiable?

No. «Válido» significa que el servidor aceptó el buzón en el momento de la consulta: es una señal fuerte, no una garantía. Un buzón puede cerrarse al día siguiente, y algunos servidores aceptan durante la conversación y rechazan después. Por eso se verifica justo antes de usar la lista.

¿Puedo comprobarlo enviando un correo de prueba?

No es buena idea. Si la dirección no existe, generas un rebote con tu propio dominio, que es justo lo que querías evitar; si existe, has enviado un mensaje que nadie pidió.

¿Qué diferencia hay entre validar y verificar un email?

En la práctica se usan como sinónimos. A veces «validar» se refiere solo al formato, lo que hace un formulario web al comprobar que hay una arroba, y «verificar» a la consulta con el servidor.

¿Cómo saber gratis si un correo existe?

Para una dirección suelta, puedes hacer tú mismo las dos primeras comprobaciones: revisar el formato y consultar los registros MX del dominio con cualquier herramienta de consulta DNS. La consulta al servidor es la parte delicada. Para listas, usa un servicio de verificación que no envíe nada y que te ofrezca un contrato de encargo del tratamiento.