Verificar una dirección no envía ningún mensaje: la sesión SMTP se detiene antes del comando DATA, el que transmite el contenido (RFC 5321, sección 4.1.1.4). Este mecanismo, poco conocido, explica la mayoría de los mitos sobre la verificación de emails, ya sea porque se le atribuyen demasiados poderes o intrusiones que no comete.
Su efecto mejor establecido recae en el hard bounce: descarta las direcciones inexistentes antes del envío. No influye ni en las quejas de spam ni en el engagement. Cada uno de los 9 mitos siguientes se resuelve con un umbral publicado o con el funcionamiento del protocolo SMTP.
Verificación y validación: el alcance en pocas líneas
La validación comprueba la forma de una dirección: una «@», un dominio, una sintaxis conforme a la RFC 5322. La verificación consulta después el dominio, a través de su registro MX, luego el propio servidor de correo, y señala las direcciones desechables. El detalle de los pasos está en el artículo sobre la diferencia entre validación y verificación.
9 mitos sobre la verificación de emails, puestos a prueba
¿Una dirección verificada es una dirección sin riesgo?
No. Un verificador clasifica las direcciones en categorías (válida, inválida, catch-all, de riesgo) porque un «válido» no cubre todos los casos. Las direcciones desechables son uno de ellos: el buzón existe y responde el día de la prueba, y después se abandona. Los servicios las detectan con listas de dominios desechables, comparadas en el artículo sobre los correos electrónicos desechables. La trampa de spam es el caso más insidioso: la gestiona un proveedor de correo o un organismo antispam y acepta el correo, así que la prueba SMTP la ve como un buzón normal. La documentación de Amazon SES precisa que estas trampas pueden ser antiguas direcciones válidas, abandonadas tras un largo periodo de rebotes.
¿Se puede verificar un buzón sin enviarle un email?
Sí. Una transacción SMTP consta de 3 comandos: MAIL FROM anuncia al remitente, RCPT TO designa al destinatario y DATA transmite el contenido del mensaje (RFC 5321, sección 3.3). El servidor responde a RCPT TO antes de que exista DATA; un verificador se detiene ahí y cierra la conexión. El código 250 significa «aceptado», el 550 «buzón desconocido» y un código 4xx un rechazo temporal que conviene reintentar.
El registro MX indica a quién hay que preguntar. La sección 5.1 de la RFC 5321 prevé que un dominio sin MX se trate como si tuviera un MX implícito que apunta a su propio host. La ausencia de MX sigue siendo, por tanto, una señal que hay que cruzar con el resto. Este mecanismo tiene un fallo conocido, que se desarrolla más abajo: algunos dominios responden 250 a todo.
¿Es invasiva la verificación?
El contenido queda fuera de su alcance: no se transmite ni se lee ningún mensaje, ya que la sesión se detiene antes de DATA. Queda la cuestión del RGPD: una dirección nominativa sigue siendo un dato personal. La CNIL fija las reglas en el momento de la prospección. Exige un consentimiento previo en B2C y un derecho de oposición en B2B. Recomienda recogerlos mediante una casilla desmarcada por defecto (la casilla premarcada está prohibida). Cada comunicación debe identificar a la organización emisora y ofrecer una forma sencilla de rechazarla (página de la CNIL sobre la prospección por correo electrónico, página en francés, actualizada el 10 de junio de 2026).
¿Demuestra el catch-all que la dirección existe?
No. Un dominio catch-all acepta el correo dirigido a cualquier nombre antes de la arroba: jean.dupont@ y azertyuiop@ obtienen el mismo 250 en el comando RCPT TO.
Ningún método lo resuelve con certeza: el destino del mensaje, guardado en un buzón real o descartado, depende de la configuración del dominio. Los servicios serios clasifican estas direcciones como risky («accept-all» en algunos), lo que expresa una incertidumbre real. Un lote de prueba enviado a este segmento, midiendo el hard bounce antes de ampliar, vale más que una selección a ciegas.
¿Basta una herramienta gratuita o una simple comprobación de sintaxis?
No. «gmial.com» respeta todas las reglas de sintaxis. El control siguiente, el registro MX, elimina los dominios inexistentes, pero no detiene un dominio real en el que el buzón no existe. Solo la conversación SMTP interroga a la propia dirección. Una herramienta gratuita se juzga, por tanto, por la profundidad de su control: sintaxis y dominio por un lado, SMTP con detección de catch-all por otro. La validación por sí sola no dice nada del estado del buzón de entrada.
¿Siguen activas las direcciones verificadas?
No. «Válido» significa aceptado por el servidor en el momento de la prueba. Un buzón puede pasar meses sin lector. También puede llenarse y devolver soft bounces. Amazon SES recomienda además dejar de enviar a los destinatarios que ni abren ni hacen clic: un contacto inactivo no rebota, pero pesa sobre el engagement.
¿Basta una verificación al año?
Ninguna cifra universal fija el ritmo. Depende de la velocidad de renovación de la base y del coste de un rebote (umbrales más abajo). Para los contactos a los que no se escribe desde hace tiempo, SES aconseja incluir solo una pequeña parte en cada envío. La página sobre la frecuencia de verificación de una lista de emails detalla el ritmo. Un doble opt-in y una verificación en el momento del registro cortan de raíz los errores de tecleo desde la entrada; la limpieza de la lista existente completa estas dos salvaguardas.
¿Garantiza la verificación la entregabilidad?
No, actúa sobre una sola línea del balance. En cuanto a las quejas de spam, Gmail fija la regla desde el 1 de febrero de 2024 para todos los remitentes:
«Mantenga las tasas de spam indicadas en Postmaster Tools por debajo del 0,10 % y evite alcanzar una tasa de spam del 0,30 % o superior.»
Esta indicación figura en las directrices de Google para remitentes, que piden SPF o DKIM a todos los remitentes y añaden DMARC a partir de 5.000 mensajes diarios hacia Gmail. Un destinatario perfectamente válido que pulsa «marcar como spam» pesa sobre la reputación del remitente sin que ninguna verificación pueda evitarlo; la definición de spam y los errores de entregabilidad cubren esa otra mitad del asunto.
En cuanto a los rebotes, la misma página de Amazon SES ofrece una escala clara: por debajo del 2 % de rebotes definitivos para obtener buenos resultados, revisión de la cuenta a partir del 5 % y posible suspensión a partir del 10 %. Los rebotes temporales, como un buzón lleno, no entran en este cálculo.
¿Valen lo mismo todos los servicios de verificación?
No. Los servicios difieren en el tratamiento de las direcciones catch-all, en la frescura de sus listas de dominios desechables y en la finura de sus estados. Un servicio que solo devuelve «válido» o «inválido» oculta la categoría más incierta, la de los catch-all. La prueba más reveladora cabe en unos minutos: enviar unos cientos de direcciones cuyo destino ya se conoce y comparar los estados devueltos. La muestra mezcla buzones internos activos, direcciones inventadas en dominios reales y un dominio catch-all identificado.
Lo que una lista verificada deja fuera
La prueba no mide ni el contenido del mensaje ni el consentimiento de los destinatarios. Tampoco dice nada de las ganas de leer. Una muestra extraída del segmento más antiguo y pasada por Captain Verify antes de la próxima campaña da la proporción de inválidas de esa base, para compararla con el umbral del 2 % de rebotes de Amazon SES.
