Un correo rebotado le dice algo que a menudo podría haber sabido antes de enviar: que la dirección no existe. En la prospección en frío, donde las direcciones proceden de sitios web, directorios y tarjetas de visita y no de formularios de registro, una parte de cualquier lista estará desactualizada.
Esta guía es para cualquiera que esté a punto de escribir a una lista que no armó mediante suscripción voluntaria (opt-in) — equipos de ventas, emprendedores, agencias. Nosotros (Outreach) explicamos las tres comprobaciones que indican si una dirección puede recibir correo, dónde dejan de funcionar esas comprobaciones y cómo leer los códigos de rebote que recibe cuando un mensaje falla de todos modos.
La respuesta corta por adelantado: normalmente se puede confirmar que una dirección existe sin enviarle un correo electrónico, pero no siempre — y saber cuándo no se puede saber es tan útil como la propia respuesta.
¿Por qué verificar las direcciones de correo electrónico antes de enviar?
Porque los proveedores de correo piden a los remitentes que eliminen las direcciones no válidas, y cada rebote es un mensaje que no llegó a nadie. Las prácticas recomendadas del Sender Hub de Yahoo dicen: «Elimine con prontitud de su lista a los destinatarios no válidos.» Las directrices de Google para remitentes de correo electrónico dicen que se debe «dar de baja automáticamente a los destinatarios que tengan varios mensajes rebotados» y que «si los mensajes empiezan a rebotar o a diferirse, se reduzca el volumen de envío hasta que disminuya la tasa de errores SMTP.»
Dicho de forma sencilla: los proveedores vigilan cómo trata usted las direcciones incorrectas. Comprobar antes de enviar significa menos rebotes que gestionar después y una idea más clara de a cuántas personas reales llegó su campaña.
¿Cuáles son los pasos para verificar una dirección de correo electrónico?
Tres comprobaciones, en orden: si la dirección está bien formada, si su dominio tiene un servidor de correo y si ese servidor dice que el buzón existe. Cada paso detecta problemas que el anterior no puede.
| Paso | Qué comprueba | Qué detecta |
|---|---|---|
| 1. Sintaxis | La dirección sigue las reglas de formato del correo electrónico | Errores tipográficos, @ ausente, caracteres no válidos |
| 2. Consulta MX | El dominio publica un servidor de correo en el DNS | Dominios inactivos, dominios que no aceptan correo |
| 3. Comprobación SMTP del buzón | El servidor de correo acepta a ese destinatario concreto | Buzones que no existen o que se cerraron |
Superar el paso 3 es la señal más fuerte que se puede obtener sin enviar. Pero, como veremos, algunos servidores dan la misma respuesta para todas las direcciones, reales o no.
¿Cómo se comprueba la sintaxis de un correo electrónico?
Confirme que hay exactamente una @, una parte anterior de aspecto válido y un dominio real después — dentro de los límites de longitud del estándar SMTP. La RFC 5321 fija «la longitud total máxima de un nombre de usuario u otra parte local» (la parte anterior a la @) en 64 octetos, y la longitud máxima del dominio en 255 octetos.
Las comprobaciones de sintaxis detectan lo evidente: sales@@example.com, info@example, un espacio final copiado de una página web o una coma escrita en lugar de un punto. Son baratas e instantáneas, así que ejecútelas siempre primero. Lo que no pueden decirle es si hay alguien detrás de la dirección. jane.doe@example.com está perfectamente formada, trabaje o no allí Jane.
¿Cómo funciona una consulta MX?
Pregunta al DNS qué servidor recibe el correo del dominio; si no hay ninguno, ninguna dirección de ese dominio puede recibir correo electrónico. El registro MX (mail exchanger, o servidor de intercambio de correo) apunta al servidor que acepta el correo de un dominio. Consultarlo indica si el dominio está configurado para recibir correo electrónico siquiera.
Tres resultados posibles, según los estándares:
- Se encuentran registros MX. El dominio tiene un servidor de correo — pase al paso 3.
- El dominio no existe. La RFC 5321 dice: «Si se devuelve un error de dominio inexistente, esta situación DEBE notificarse como un error.» La dirección no sirve.
- No hay registro MX, pero el dominio existe. La RFC 5321 dice que la dirección «se trata como si estuviera asociada a un MX implícito» — el correo va al propio registro de dirección del dominio. Así que la ausencia de MX no es automáticamente un callejón sin salida.
También hay una señal explícita de «no aceptamos correo». La RFC 7505 define un «MX nulo» — un único registro MX con preferencia 0 y un «.» como nombre del servidor — que «hará que todos los intentos de entrega de correo a un dominio fallen de inmediato.» Si lo ve, deténgase: el dominio ha declarado que no recibe correo electrónico.
¿Cómo funciona la comprobación SMTP de un buzón sin enviar un correo electrónico?
El verificador se conecta al servidor de correo del dominio, inicia una entrega, indica el destinatario, lee la respuesta del servidor y se desconecta antes de enviar ningún contenido del mensaje. En términos de SMTP: conectar, EHLO, MAIL FROM, RCPT TO:<address>, leer el código de respuesta y después QUIT — el paso DATA, donde iría el mensaje real, nunca ocurre.
Lo que importa es la respuesta a RCPT TO. La RFC 5321 define los códigos:
| Respuesta | Significado en la RFC 5321 | Lo que suele indicar |
|---|---|---|
| 250 | Acción de correo solicitada correcta, completada | El servidor acepta a este destinatario |
| 550 | «Acción solicitada no realizada: buzón no disponible (por ejemplo, buzón no encontrado, sin acceso o comando rechazado por motivos de política)» | A menudo «no existe tal buzón» — pero lea el texto, también puede ser un rechazo por política |
| 553 | «nombre de buzón no permitido (por ejemplo, sintaxis del buzón incorrecta)» | Formato de dirección rechazado |
| 450 | «buzón no disponible (por ejemplo, buzón ocupado o bloqueado temporalmente por motivos de política)» | Temporal — inténtelo más tarde |
| 452 | «almacenamiento insuficiente del sistema» | Temporal |
¿Por qué no preguntar directamente al servidor con el comando VRFY? Porque los servidores pueden desactivarlo. La sección 7.3 de la RFC 5321 permite a los sitios desactivar VRFY por razones de seguridad, y dice que un servidor que lo hace «DEBE devolver una respuesta 252» — una respuesta que no significa ni sí ni no. Por eso los verificadores usan en su lugar la vía de RCPT TO.
En nuestras propias pruebas de septiembre de 2026, el método RCPT identificó correctamente las 6 direcciones de un pequeño conjunto conocido: 3 direcciones que sabíamos que habían rebotado, 2 direcciones que funcionaban y 1 de un dominio catch-all que marcamos correctamente como no confirmable.
¿Qué es un dominio catch-all y por qué no se puede verificar?
Un dominio catch-all acepta correo para cualquier dirección, real o inventada, por lo que su servidor responde «250 OK» para todos los destinatarios y una comprobación previa al envío no aprende nada. Algunas empresas configuran así su correo para que las direcciones mal escritas lleguen igualmente a alguien. Otras usan pasarelas que aceptan todo primero y lo clasifican después.
Un catch-all se detecta preguntando al servidor por una dirección que casi con seguridad no existe, como una larga cadena aleatoria en el mismo dominio. Si el servidor también la acepta, cada «sí» suyo carece de sentido.
¿Con qué frecuencia ocurre? En una prueba de septiembre de 2026, nosotros (Outreach) enviamos comprobaciones RCPT con direcciones inventadas a 25 dominios de correo tomados de 200 contactos de empresas que habíamos recopilado (en su mayoría empresas coreanas). Aproximadamente el 74% de los dominios respondió con honestidad y rechazó la dirección falsa; aproximadamente el 25% la aceptó — eran catch-all. Considérelo una muestra de un solo mercado, no una tasa universal. Lo importante es que no es raro.
Para las direcciones catch-all, el resultado honesto es «no se puede verificar.» Enviar es la única forma de averiguarlo, y es una decisión de criterio: una dirección publicada en el sitio web de la propia empresa es una mejor apuesta que una adivinada a partir de un patrón de nombre.
¿Por qué algunos servidores de correo rechazan las comprobaciones de verificación?
Algunos servidores de correo limitan quién puede preguntar por los destinatarios, así que en lugar de responder retrasan la respuesta, rechazan temporalmente o cortan la conexión. Los rechazos suelen tener este aspecto:
- Una respuesta temporal 4xx para todos los destinatarios, que le pide volver a intentarlo más tarde.
- Una respuesta 5xx que se refiere a la política o a la reputación y no al buzón — por ejemplo, un código ampliado 5.7.1, que la RFC 3463 describe como «Entrega no autorizada, mensaje rechazado.»
- Ninguna respuesta, o una conexión que se corta.
Ninguno de estos casos indica si el buzón existe. Un buen verificador los informa como «desconocido» y no como «no válido» — marcar como inexistente una dirección real porque su servidor fue cauteloso descartaría un buen contacto.
Algunos proveedores de alojamiento también bloquean las conexiones salientes por el puerto 25, el puerto de SMTP, lo que significa que un verificador que se ejecute allí no puede llegar a ningún servidor de correo. De nuevo, la respuesta correcta en ese caso es «no se puede verificar» y no «no existe».
¿Cómo se leen los códigos de rebote después de enviar?
Mire el primer dígito del código de estado ampliado: 5 significa permanente y 4 significa temporal. Después, el dígito central indica qué tipo de problema es. La RFC 3463 define códigos con la forma class.subject.detail:
- 5.x.x — Fallo permanente: «es poco probable que se resuelva reenviando el mensaje en su forma actual.»
- 4.x.x — Fallo transitorio persistente: «el envío en el futuro puede tener éxito.»
Los códigos que verá con más frecuencia cuando el problema es la dirección:
| Código | Nombre en la RFC 3463 | Qué hacer |
|---|---|---|
| 5.1.1 | Dirección de buzón de destino incorrecta — «El buzón especificado en la dirección no existe» | Elimine la dirección |
| 5.1.2 | Dirección de sistema de destino incorrecta | Compruebe el dominio; elimínela si ya no existe |
| 5.1.3 | Sintaxis incorrecta de la dirección de buzón de destino | Corrija el error o elimínela |
| 5.1.6 | El buzón de destino se ha trasladado, sin dirección de reenvío | Elimínela; busque un contacto nuevo |
| 5.2.1 / 4.2.1 | Buzón deshabilitado, no acepta mensajes | Elimínela si es permanente (5), espere si es temporal (4) |
| 4.2.2 | Buzón lleno («debe usarse como un fallo transitorio persistente») | Inténtelo de nuevo más tarde |
| 4.4.1 | Sin respuesta del host | Temporal — reintente más tarde |
| 4.4.7 | Tiempo de entrega agotado | El mensaje era demasiado antiguo para entregarse; compruebe la dirección y reintente más tarde |
| 5.7.1 | Entrega no autorizada, mensaje rechazado | No es un problema de la dirección, sino de política o de autenticación |
Esa última fila importa. Un código 5.7.x normalmente significa que el servidor receptor le rechazó a usted, no que falte el buzón. Revise su configuración de SPF, DKIM y DMARC antes de eliminar el contacto.
¿Cómo puede comprobar una sola dirección gratis?
Introdúzcala en nuestro verificador gratuito de direcciones de correo electrónico; ejecuta las comprobaciones de sintaxis, MX y buzón y le indica una de tres cosas. No hace falta registrarse. El verificador está disponible en inglés y coreano; introduzca la dirección que desea comprobar. El resultado es uno de estos:
- Esta dirección puede recibir correo — el servidor de correo aceptó al destinatario.
- Esta dirección no existe — la dirección no está bien formada, el dominio no tiene servidor de correo o el servidor dijo que no existe ese buzón.
- No se puede verificar — el dominio es catch-all, el servidor rechazó la comprobación o no fue posible ninguna comprobación. La herramienta le indica qué motivo se aplicó.
Para evitar que la herramienta se use para sondeos masivos, permite un número limitado de comprobaciones al día. Para una lista completa, verifique dentro de su flujo de envío en lugar de dirección por dirección.
¿Qué debe hacer con las direcciones que no se pueden verificar?
Manténgalas aparte, envíeles en lotes más pequeños y elimine las que reboten con un código 5.x.x. Un orden práctico:
- Descarte todo lo que falle en la sintaxis o no tenga servidor de correo.
- Elimine las direcciones que el servidor dijo que no existen.
- Envíe primero a las direcciones confirmadas.
- Envíe con más cautela a las direcciones marcadas como «no se puede verificar», y elimine las que vuelvan con un rebote permanente — como aconsejan tanto Yahoo como Google.
Recuerde también que una dirección válida no significa un destinatario dispuesto. Las quejas de spam cuentan en su contra exista o no la dirección; explicamos las cifras en por qué los correos en frío acaban en spam.
En resumen
- Verifique en tres pasos: sintaxis → consulta MX → comprobación SMTP del buzón (RCPT, sin enviar contenido).
- La parte anterior a la @ puede tener como máximo 64 caracteres (RFC 5321); un MX nulo significa que el dominio no recibe correo (RFC 7505).
- Los dominios catch-all aceptan todas las direcciones — en nuestra prueba de 25 dominios, lo hizo aproximadamente el 25% — por lo que algunas direcciones solo se pueden marcar como «no se puede verificar.»
- En los rebotes, 5.x.x es permanente y 4.x.x temporal; 5.1.1 significa que el buzón no existe; 5.7.x apunta a un problema de política, no a una dirección incorrecta.
- Pruebe una sola dirección con nuestro verificador gratuito de correo electrónico.
