Cómo saber si tu verificador de correo te está mintiendo

La verificación de correo electrónico tiene un problema poco habitual: no es fácil saber si ha funcionado.

Si un verificador te dice que una dirección es válida y le envías un correo, te enteras semanas después por tu tasa de rebote. Para entonces el daño (reputación del remitente, entregabilidad, un dominio quemado) ya está hecho. Todas las herramientas de la categoría anuncian "99 % de precisión", y casi nadie lo comprueba.

Esta es una prueba que lleva alrededor de un minuto, y esto es lo que encontramos al pasarla con nuestro propio producto.

La prueba

Inventa una dirección que no pueda existir de ninguna manera, en un proveedor que sabes que rechaza los buzones desconocidos:

definitely-not-real-xyz9987661@gmail.com

Gmail rechaza a los destinatarios desconocidos en la capa SMTP con una respuesta 550. No es una suposición sobre el comportamiento de Gmail: es observable, y es todo el mecanismo sobre el que se construye la verificación.

Así que solo hay una respuesta correcta: invalid (inválido).

Pasa esa dirección por tu verificador. Si vuelve como válida, la herramienta no comprobó el buzón. Miró el dominio, vio gmail.com y dio por hecho el resto.

Suspendimos nuestra propia prueba

Nosotros construimos este producto. Cuando pasamos esa dirección por nuestro propio motor, devolvió:

definitely-not-real-xyz9987661@gmail.com  →  valid  ("Verified")

No "risky" (riesgoso). No "unknown" (desconocido). Verified (verificado).

Lo causaron dos cosas de nuestro propio código, y vale la pena entender las dos porque son errores fáciles de cometer.

El atajo de los proveedores. El motor tenía una lista de los grandes proveedores (Gmail, Yahoo, Outlook, iCloud, etc.) y devolvía válido para cualquier dirección bien formada en uno de ellos, sin llegar a abrir una conexión SMTP. El razonamiento era que esos dominios sin duda aceptan correo. Eso es cierto del dominio y no dice nada del buzón. En una lista típica de consumidores, ese único atajo da por buena una gran parte de cada archivo que subes.

El valor por defecto ante un fallo. Cuando la comprobación SMTP sí se ejecutaba y fallaba por cualquier motivo (tiempo de espera agotado, puerto bloqueado, conexión rechazada), el código recurría a un valor por defecto de válido, con la lógica de que una sintaxis válida más un servidor de correo válido probablemente significan una dirección real.

El segundo importa más de lo que parece, por el lugar donde suele ejecutarse la verificación.

La mayoría de los proveedores en la nube bloquean el puerto que necesita la verificación

Comprobar un buzón implica conectarse al servidor de correo del destinatario en el puerto 25. Casi todos los grandes proveedores en la nube bloquean por defecto el puerto 25 saliente para frenar el spam. Lo medimos en dos:

Proveedor	Puerto 25 saliente
Railway	Bloqueado
DigitalOcean	Bloqueado

Junta esos dos hechos. Si un verificador funciona en una infraestructura que bloquea el puerto 25, y su código devuelve válido por defecto cuando falla la comprobación SMTP, entonces todas las direcciones de un dominio activo salen como válidas, y la herramienta no ha verificado absolutamente nada mientras informa de una confianza total.

No es un fallo hipotético. Es lo que hacía nuestro propio código hasta que lo corregimos.

Cómo es un resultado honesto

La solución no es sondear con más ingenio. Es estar dispuesto a decir "no lo sé".

Un verificador debería devolver tres estados, y el del medio es el importante:

• valid (válido): un servidor de correo confirmó que este buzón existe
• invalid (inválido): un servidor de correo lo rechazó, el dominio no tiene servidor de correo, la sintaxis está mal o es una dirección desechable
• risky (riesgoso): no se pudo completar la comprobación

Riesgoso es la respuesta honesta para los casos realmente ambiguos, y hay varios:

Los dominios catch-all (dominios que aceptan todo) aceptan cualquier dirección del dominio, exista o no, así que cualquiercosa@sudominio.com recibe una aceptación. Ahí la verificación no puede distinguir un buzón real de un error tipográfico. Cualquier herramienta que devuelva válido en un dominio catch-all está informando de la configuración del dominio, no del buzón.

Los proveedores que ocultan el estado del buzón. Algunos grandes proveedores de consumo, entre ellos Yahoo e iCloud, se niegan a dar una respuesta clara sobre destinatarios desconocidos en la fase RCPT, así que una sonda contra ellos suele ser inconclusa. Microsoft no está en este grupo: tanto Outlook.com como Microsoft 365 rechazan a los destinatarios desconocidos durante la conversación SMTP.

Las conexiones bloqueadas o rechazadas, como vimos arriba.

Nuestro motor ahora devuelve inválido para esa dirección inventada de Gmail, con el motivo Mailbox not found. Todo lo que no puede confirmar va a riesgoso, y nunca a válido.

Cómo probar el que usas

Prepara un archivo pequeño con direcciones cuya respuesta ya conoces:

1. Una dirección inventada en gmail.com: debe salir invalid
2. Tu propia dirección real: debe salir valid
3. Algo sin @: debe salir invalid
4. Una dirección en un dominio desechable como mailinator.com: debería salir invalid
5. Una dirección en un dominio sin ningún servidor de correo: debe salir invalid
6. Una dirección de rol como info@ en una empresa real: debería marcarse como risky o como dirección de rol

Seis filas. Cualquier verificador por el que valga la pena pagar acierta las seis, y la primera es la que detecta si está adivinando.

Si tu proveedor devuelve válido en la fila 1, no estás comprando verificación. Estás comprando un comprobador de sintaxis con un tono muy seguro, y descubrirás la diferencia por tu tasa de rebote.

Por qué publicamos esto

Habría sido fácil corregir el error en silencio. Lo contamos porque la prueba es más útil que la afirmación: no deberías fiarte de nuestra palabra sobre nuestra precisión más que de la de cualquier otro.

Pasa las seis filas con nosotros. Pásalas con el que uses ahora. Los resultados te dirán más que cualquier porcentaje de precisión en una página de precios.