Cómo funciona la verificación de correo electrónico: las 8 etapas

La respuesta corta#

La verificación de correo electrónico hace pasar una dirección por un proceso de comprobaciones cada vez más costosas, que se detiene en cuanto una de ellas es decisiva. Las comprobaciones baratas e instantáneas ocurren en local —si la dirección tiene siquiera la forma de un correo, si su dominio acepta correo en absoluto— y solo las direcciones que superan esas fases llegan al paso lento y dependiente de la red de preguntar realmente al servidor de correo si el buzón existe. Qualisend ejecuta ocho etapas distintas, y este artículo repasa cada una: qué puede demostrar, qué no puede y qué veredicto produce.

El orden importa porque cada etapa es un filtro. No tiene sentido abrir una conexión SMTP para comprobar un buzón en un dominio que no tiene servidor de correo, ni tiene sentido consultar el DNS de ese dominio si a la dirección le falta una @. Primero las eliminaciones baratas; la pregunta cara, al final.

Etapa 1 — Sintaxis#

La primera comprobación es si la cadena es siquiera una dirección de correo estructuralmente válida: una @, una parte local con sentido, un dominio que parezca un dominio. Esto detecta los errores de dedo —comas sobrantes, espacios, un TLD ausente, dos signos @— y es instantáneo y gratuito porque nunca sale del proceso.

La validación de sintaxis es necesaria pero débil por sí sola. definitely-not-real@some-made-up-domain.com tiene una sintaxis perfectamente válida y es completamente no entregable. Quien "verifica" con una expresión regular y se detiene aquí está comprobando la ortografía, no la entregabilidad. Un fallo en esta etapa devuelve undeliverable con el motivo invalid_email.

Etapa 2 — Dominio y registros MX#

A continuación, el verificador pregunta al DNS si el dominio puede recibir correo en absoluto: ¿resuelve y publica registros MX (o un registro A utilizable como alternativa) que apunten a un servidor de correo? Un dominio sin ruta de correo no puede aceptar correo para nadie, así que esta etapa elimina dominios enteros y muertos con una sola consulta: nombres de empresa mal escritos, dominios caducados y TLD inventados.

Un dominio que falla aquí devuelve undeliverable con el motivo invalid_domain. Un dominio que pasa tiene una ruta para el correo; todavía no ha demostrado que tu buzón concreto exista. Para eso aún quedan cuatro etapas.

Etapa 3 — Dominios desechables#

Algunos dominios existen solo para repartir buzones de usar y tirar: las direcciones de diez minutos que la gente usa para conseguir un código de descuento y no vuelve a revisar jamás. Qualisend coteja el dominio con una lista mantenida de proveedores desechables. Una coincidencia no significa que la dirección no vaya a aceptar correo hoy; significa que la dirección no valdrá nada mañana, así que se marca y se baja su puntuación en lugar de confiar en ella.

Una dirección desechable se reporta como risky con el motivo low_quality y un subindicador de desechable. La cuestión relacionada de si conviene enviarle algo o no es una decisión aparte, tratada en direcciones de rol, desechables y gratuitas.

Etapa 4 — Cuentas de rol#

Una dirección de rol es un buzón compartido —info@, support@, billing@— que lee un equipo o un sistema de tickets en lugar de una persona. Suelen ser reales y entregables, pero se comportan mal en marketing: ningún humano concreto es su dueño, distorsionan las métricas de interacción y atraen quejas de spam. Por eso el verificador las detecta (sin distinguir mayúsculas de minúsculas e ignorando cualquier sufijo +tag) y las marca en lugar de tratarlas como un buzón personal.

Una dirección de rol se mantiene como deliverable pero lleva un subindicador de rol, para que puedas decidir si encaja en un envío determinado. De nuevo, la decisión de enviar o suprimir tiene su propia guía.

Etapa 5 — Detección de erratas#

Antes de gastar un ida y vuelta por la red, el verificador comprueba si el dominio es un casi acierto de un proveedor común —gmial.com por gmail.com, hotmial.com por hotmail.com— usando la distancia de edición de Damerau-Levenshtein (el algoritmo que cuenta inserciones, eliminaciones, sustituciones y transposiciones). Cuando encuentra una errata probable, ofrece una sugerencia de "quizás quisiste decir", que es mucho más útil que un mero rechazo: en el momento del registro te permite ofrecer la corrección en tiempo real y salvar al suscriptor en lugar de perderlo.

La detección de erratas es una sugerencia, no un veredicto por sí sola, pero es una de las etapas de mayor impacto, porque atrapar la errata en el momento de la captura evita un rebote duro y un contacto perdido en un solo paso.

Etapa 6 — La sonda SMTP del buzón#

Todo lo anterior es local e instantáneo. Esta es la etapa que realmente cuesta algo: el verificador abre una conexión con el servidor de correo del dominio e inicia la conversación de entrega —HELO, MAIL FROM, RCPT TO:<address>— y luego lee la respuesta del servidor sin llegar a enviar nunca un mensaje. La respuesta a RCPT TO es lo más parecido a una respuesta real sobre si el buzón existe:

• 250/251 → el servidor acepta al destinatario → deliverable, accepted_email
• clase 550 → rechazo permanente, no existe tal usuario → undeliverable, rejected_email
• 4xx → un aplazamiento temporal, normalmente greylisting → reintentar, y luego unknown si persiste
• cualquier otra cosa, o un tiempo de espera agotado → unknown

Esta etapa también lee el texto de la respuesta y los códigos para dos condiciones especiales: un mensaje 452/552 o "over quota" significa que el buzón existe pero está lleno (risky), y un mensaje "disabled/suspended" significa que la cuenta está muerta (undeliverable). La gramática completa de estas respuestas tiene su propia referencia: códigos de respuesta SMTP explicados.

Etapa 7 — Detección de catch-all#

Un 250 de SMTP solo significa algo si el servidor hubiera dicho que no a una dirección inexistente. Así que, junto a tu dirección, el verificador sondea un buzón deliberadamente absurdo en el mismo dominio. Si el servidor acepta ese también, el dominio es catch-all —lo acepta todo— y el 250 de tu dirección no demuestra nada. Esa dirección se reporta como risky con el motivo low_deliverability y un indicador de catch-all, y nunca se redondea al alza a entregable.

Esta es la etapa que más se tergiversa en el sector, y por eso tiene su propio pilar. El resumen honesto: un buzón detrás de un dominio catch-all es inconfirmable, y ninguna puntuación cambia eso.

Etapa 8 — Puntuación y veredicto#

La etapa final integra cada señal —el veredicto SMTP, los subindicadores, la reputación del dominio, si el buzón está en un proveedor gratuito— en un único estado (deliverable | risky | undeliverable | unknown), un código de motivo y una puntuación de confianza de 0 a 100. El estado te dice qué hacer; el motivo y los subindicadores te dicen por qué; la puntuación ordena las direcciones dentro de un mismo estado. Y algo crucial: cada veredicto viene con su evidencia —el proveedor de MX, el detalle de la sonda—, de modo que el número es auditable en lugar de una caja negra.

Lo que las ocho etapas siguen sin poder decirte#

Un proceso tan exhaustivo puede dar la sensación de que debería producir un sí o un no limpio para cada dirección. No lo hace, y vale la pena enunciar con claridad sus límites honestos:

• Un dominio catch-all limita la certeza a "arriesgado". Cuando la etapa 7 encuentra un servidor que lo acepta todo, el 250 de la etapa 6 no aporta información: el buzón es inconfirmable por muchas etapas que se hayan ejecutado. Ningún verificador resuelve esto sin enviar, y cualquiera que afirme hacerlo está adivinando.
• Un servidor con greylisting o limitación de tasa puede forzar un unknown. Si la etapa 6 solo consigue un aplazamiento 4xx dentro del presupuesto de tiempo, el veredicto honesto es unknown —reintentar más tarde—, no un válido o inválido inventado.
• La verificación es una instantánea. Una dirección confirmada como entregable hoy puede degradarse mañana cuando alguien deje un trabajo o abandone un buzón. Por eso importa volver a limpiar antes de los envíos grandes, y por eso una tasa de rebote que sube es una señal para volver a verificar.
• La interacción es lo único que la verificación no puede medir. Una dirección entregable que nunca abre nada es un lastre para la entregabilidad que el proceso no puede ver. La verificación te dice que una dirección puede recibir correo, no que su propietario quiera tu correo.

Ninguno de estos es un defecto del proceso: son los límites de lo que cualquier verificación puede saber. La herramienta de la que desconfiar es la que finge que esos límites no existen.

Por qué el verificador gratuito se detiene en la etapa 5#

Nuestro verificador de correo gratuito ejecuta las etapas 1 a 5 —las locales— y se detiene deliberadamente antes de la sonda SMTP. Eso no es una versión mutilada del producto; es un límite honesto. Las etapas 1 a 5 pueden descartar una dirección (sintaxis incorrecta, sin ruta de correo, desechable, errata evidente), pero no pueden confirmar un buzón ni detectar catch-all, porque eso requiere abrir una conversación SMTP real desde una IP con buena reputación. Cualquier herramienta gratuita de navegador que afirme confirmar buzones activos o no está haciendo la etapa 6 o no está siendo honesta al respecto. El equilibrio entre la versión completa y la gratuita tiene su propio desglose.

Preguntas frecuentes#

¿Verificar un correo electrónico le envía un mensaje?#

No. La sonda SMTP de la etapa 6 ejecuta la conversación de entrega hasta el punto en el que el servidor acepta o rechaza al destinatario, y luego se desconecta sin emitir el comando DATA que transmitiría un mensaje. El propietario del buzón no ve nada. Enviar un correo de "prueba" real para comprobar la validez es exactamente la mala práctica que una verificación como es debido evita.

¿Por qué la verificación no puede ser simplemente instantánea?#

Las etapas 1 a 5 son instantáneas porque son locales. La etapa 6 requiere una conversación de red con un servidor de correo de terceros que no controlas, uno que puede aplicarte greylisting, limitarte la tasa o responder despacio a propósito. Ese ida y vuelta es el precio de una respuesta real, razón por la cual los trabajos masivos se ejecutan de forma asíncrona en lugar de bloquearse en cada dirección.

¿Cuál es la diferencia entre el estado y la puntuación?#

El estado (deliverable | risky | undeliverable | unknown) es la decisión; la puntuación (0 a 100) ordena las direcciones dentro de un estado para que puedas priorizar. Una dirección entregable en un proveedor gratuito puntúa de forma distinta a una en un dominio corporativo, pero ambas son entregables. Usa el estado para decidir y la puntuación para ordenar.

¿Qué etapas expone la API?#

Todas ellas. Un resultado de verificación devuelve el estado y el motivo finales, además de los subindicadores (catch-all, desechable, rol, gratuito, buzón lleno) y la sugerencia de "quizás quisiste decir", de modo que tu propio código puede actuar sobre la evidencia y no solo sobre el veredicto. Consulta la documentación para desarrolladores y —si estás eligiendo entre proveedores— la comparativa de API de verificación de correo.