Un rebote de correo casi nunca es lo que parece a primera vista. El mensaje que reenvía tu servidor suele resumir el fallo en una frase amable (“el usuario no existe”), pero el informe técnico que lo acompaña, el DSN o Delivery Status Notification, contiene la versión literal que devolvió el MTA del destinatario. Ahí está la diferencia entre aplicar un parche y resolver la causa. Leer ese informe con criterio evita perder horas persiguiendo un problema de buzón cuando el origen era un registro MX mal apuntado.
La parte legible del DSN es una traducción, y como toda traducción pierde matices. El campo Diagnostic-Code, en cambio, conserva el texto exacto del servidor remoto: un 550 5.1.1 suele señalar que la parte local no coincide con ninguna dirección del dominio, mientras que un 550 5.1.2 apunta a un problema de enrutamiento interno. Distinguir un rebote duro (códigos 5.x.x, definitivo) de uno blando (4.x.x, temporal) es el primer filtro, pero no el último. El segundo es identificar qué MTA generó el informe, porque de ello depende si el fallo está en tu configuración o en la del receptor.
Este análisis recorre las cabeceras Action, Status y Diagnostic-Code de un DSN real, explica cómo interpretarlas y traduce cada patrón en una acción concreta: corregir un alias de correo mal definido, revisar los registros MX del dominio o ajustar el enrutamiento. También hay un factor que distorsiona el diagnóstico más de lo que parece: un correo catch-all activo. Un buzón comodín acepta cualquier mensaje enviado a un dominio, de modo que silencia la respuesta 550 no such user que necesitas para detectar direcciones inválidas. Saber cuándo conviene tenerlo y cuándo enmascara errores reales forma parte de la misma lectura.
Qué es un rebote de correo y por qué el DSN no siempre dice la verdad
Un rebote de correo es la devolución de un mensaje que no pudo entregarse al destinatario final. El servidor de correo que lo rechaza genera un informe técnico llamado DSN (Delivery Status Notification) y lo envía a la dirección del remitente, o al Return-Path si es distinto. Ese informe es la fuente de verdad del fallo, aunque no siempre sea fácil de leer. La parte que la mayoría de clientes muestra en pantalla suele ser un resumen en lenguaje llano, y ese resumen frecuentemente simplifica, generaliza o directamente desvía el diagnóstico hacia el sitio equivocado.
La primera distinción que conviene tener clara es la de los dos grandes tipos de rebote. Los rebotes duros se identifican por códigos de estado que empiezan por 5, como 5.1.1, y significan que la entrega ha fallado de forma permanente: reintentar no tiene sentido. Los rebotes blandos llevan códigos que empiezan por 4, como 4.2.2, y describen una situación temporal: buzón lleno, servidor receptor saturado, límite de conexiones alcanzado. Un rebote blando puede resolverse solo en el siguiente intento, pero si se repite durante horas o días acaba convirtiéndose en un rebote duro por agotamiento del tiempo de espera.
Cuando el servidor de correo receptor no encuentra coincidencia para la dirección solicitada, responde con un 550 no such user. Ese código viaja dentro del DSN que recibes, junto con la respuesta literal del otro extremo. El problema es que muchos paneles y clientes de correo traducen ese 550 a un escueto “el destinatario no existe” sin mostrar el texto original. Y ahí está la trampa: un 550 no such user puede deberse a que la parte local está mal escrita, a que el alias de correo no existe, o a que el dominio enruta el correo hacia un host que no reconoce esa cuenta. Tres causas distintas con una misma etiqueta visible.
Por qué el DSN que ves no coincide con el que se generó
El DSN se compone de varias partes. Una es legible para humanos y otra contiene los campos técnicos: Action, Status, Diagnostic-Code, Reporting-MTA. Los clientes de correo más simples muestran solo la primera y ocultan la segunda. Si te fías de esa vista, pierdes justo la información que permite saber quién rechazó el mensaje y por qué. Un mismo “mensaje no entregado” en pantalla puede esconder un 5.7.1 de política antispam, un 5.1.1 de usuario inexistente o un 5.4.4 de fallo de enrutamiento, y cada uno exige una acción diferente.
Hay otro factor que distorsiona la lectura: el DSN lo puede generar un servidor intermedio, no el destino final. Si tu proveedor reenvía el correo a otra plataforma y esa plataforma lo rechaza, el rebote que te llega puede describir el segundo salto, no el primero. En ese escenario, el campo Reporting-MTA delata qué máquina emitió el informe, y el Diagnostic-Code incluye normalmente el nombre del host que rechazó. Leer esos dos campos antes que la parte legible ahorra bastantes conjeturas.
La recomendación práctica es simple: abre siempre el mensaje de rebote en modo texto completo o consulta el original desde el cliente, y localiza el bloque message/delivery-status. Ahí están los códigos que importan. La narrativa en español que aparece arriba puede ayudar a un usuario final, pero para diagnosticar de verdad necesitas los números y el texto literal del servidor remoto.
Anatomía de un DSN: cabeceras Action, Status y Diagnostic-Code
Un DSN (Delivery Status Notification) es un mensaje multipart que genera el MTA. La primera parte suele ser texto legible en lenguaje humano; la segunda, message/delivery-status, es la que importa de verdad. Ahí están las cabeceras por máquina que describen el fallo con precisión. Si tu cliente de correo solo te muestra el texto amable (“no pudimos entregar tu mensaje”), abre el original o descarga el .eml y revisa las partes.
La estructura típica es multipart/report; report-type=delivery-status. Dentro encontrarás tres bloques: el texto legible, el bloque de estado de entrega y, en muchos casos, el mensaje original adjunto como message/rfc822. Ese adjunto no es decorativo: conserva las cabeceras del envío original, incluido el Message-ID y el destinatario real, útil cuando el rebote llega a una cuenta distinta de la que envió.
El bloque de estado se organiza en párrafos separados por líneas en blanco. El primero describe el mensaje en conjunto (campos Reporting-MTA, Arrival-Date). Los siguientes, uno por destinatario, contienen las tres cabeceras clave: Action, Status y Diagnostic-Code. A veces aparecen Remote-MTA, Final-Recipient y Original-Recipient, que conviene leer antes de sacar conclusiones.
Action indica qué hizo el sistema con el mensaje. Los valores habituales son failed, delayed, delivered y relayed. Un failed significa que la entrega se abandonó de forma definitiva; un delayed es un aviso de que sigue intentándolo y no debe tratarse como error final. Confundir ambos lleva a borrar de la lista a un destinatario que quizá solo tenía el buzón lleno o el servidor caído. Un delayed puede convertirse más tarde en failed; espera al menos 24 o 48 horas antes de actuar.
Status es el código numérico que replica la lógica SMTP con formato extendido. La primera cifra repite la clase: 4 para fallo temporal, 5 para permanente. Las dos siguientes afinan el motivo. El caso más común, 5.1.1, responde a “usuario inexistente”: la parte local de la dirección no existe en el dominio de destino. Otros relevantes: 5.1.2 (dominio inexistente), 5.1.3 (dirección mal formada), 5.2.2 (buzón lleno, a veces temporal), 5.4.4 (sin registro MX válido) y 5.7.1 (rechazo por política, spam o autenticación).
Diagnostic-Code contiene el mensaje literal que devolvió el servidor receptor, normalmente precedido por smtp;. Aquí es donde aparece la verdad sin filtros: smtp; 550 5.1.1 <usuario@dominio.com>: Recipient address rejected: User unknown in local recipient table no deja dudas. También verás variantes como 550 no such user o 554 5.7.1 Message rejected. La cabecera Remote-MTA te dice qué host emitió ese diagnóstico, dato que separa un rechazo del destino final de uno de un relay intermedio.
Cuando el DSN no trae Diagnostic-Code, no asumas que el fallo es ambiguo. Revisa Final-Recipient: si el dominio no coincide con el que enviaste, algo en el enrutamiento reescribió la dirección. Y si el Reporting-MTA es tu propio servidor, el rebote se generó antes de salir, lo que apunta a una configuración local y no a un problema del destinatario.
Cómo interpretar las cabeceras para identificar el MTA y el motivo real del rebote
El DSN llega como un correo multipart con dos caras: una parte legible para humanos y una parte message/delivery-status que es la que vale. Ahí están las líneas que resuelven el caso. Lo primero que conviene mirar es Action. Si dice failed, el intento se ha agotado y el mensaje no se entregará. Si dice delayed, el servidor remoto aún acepta la conexión y reintenta; un 4.x.x con delayed no es un rebote definitivo, es una alerta de cola. Si dice delivered, el rebote no lo generó el destinatario final, sino un reenvío o una regla posterior.
El segundo campo es Status. El formato es clase.punto. El primer dígito marca la gravedad: 5 es fallo permanente, 4 es temporal. El 5.1.1 significa “destinatario desconocido”: el servidor receptor procesó el dominio, encontró sus registros MX y rechazó la parte local. Ese matiz separa dos mundos. Un 5.1.1 con un dominio válido apunta casi siempre a un alias mal escrito, un buzón eliminado o una regla de enrutamiento interna que no cubre esa dirección. Un 5.4.4 o un 5.1.2 suele hablar de DNS: dominio sin MX, MX apuntando a un host que ya no existe o un registro mal priorizado.
El tercer campo es el Diagnostic-Code, el mensaje literal del MTA receptor. qué es un correo catch-all incluye más detalles al respecto. Aquí está la verdad cruda y a menudo la pista del fabricante. Ejemplos típicos:
- smtp; 550 5.1.1 <usuario@dominio.com>: Recipient address rejected: User unknown in local recipient table suena a Postfix: la tabla de destinatarios locales no tiene esa entrada. Revisa el alias o el buzón en el panel de hosting.
- smtp; 550 5.1.1 <usuario@dominio.com>: recipient rejected, no such user con la firma “no such user” es el patrón de Exchange y de muchos filtros perimetrales. La dirección no existe en el directorio.
- smtp; 550 5.1.1 <usuario@dominio.com>: unknown user con host … said delante indica que el rechazo viene del host del MX, no de tu servidor saliente. La parte local es la culpable.
- smtp; 550 5.7.1 … blocked o Relay access denied no es un problema de buzón: es política de relay o lista negra.
Para saber qué MTA generó el rebote, mira las cabeceras Received y el Reporting-MTA dentro del bloque de estado. Si el Reporting-MTA es tu propio servidor de correo, el rebote lo produjo tu infraestructura al no poder entregar al destino, y el Final-Recipient te dirá a quién intentaba llegar. Si el Reporting-MTA es un host remoto, el rechazo nació allí y el Diagnostic-Code es la sentencia del receptor.
Un detalle que se pasa por alto: el Original-Recipient y el Final-Recipient pueden diferir. Cuando el mensaje pasa por un reenvío o un alias, el fallo puede estar en la dirección final, no en la que escribiste. Compara ambos campos antes de tocar nada. Si el Final-Recipient apunta a un buzón que no reconoces, el problema está en tu regla de reenvío o en el alias, no en el dominio del destinatario.
Cruza siempre estos tres datos con la parte local del dominio. Si el Status es 5.1.1 y el Diagnostic-Code menciona “unknown user” o “no such user”, el diagnóstico apunta a un alias de correo mal definido o a un buzón inexistente. Si el Status es 5.4.4, 5.4.1 o el Diagnostic-Code habla de “no MX record” o “host not found”, el fallo está en los registros MX del dominio. Esa lectura cruzada es la que evita cambiar el alias cuando en realidad había un MX huérfano o una prioridad mal puesta.
Del diagnóstico a la decisión: corregir el alias de correo o el registro MX
El DSN ya te ha dado el código y el servidor que lo emitió. Lo que viene después es decidir dónde está la avería: en la tabla de alias del dominio o en el DNS. La clave está en quién generó el rebote y en qué parte de la dirección falló.
Si el Diagnostic-Code cita un host concreto del dominio receptor (por ejemplo, mx1.destino.com) y el Status es 5.1.1, el mensaje llegó al servidor correcto y allí no encontró la parte local. Eso apunta a un alias de correo mal escrito, a un buzón eliminado o a una regla de enrutamiento interna que ya no existe. La acción es revisar el panel de hosting o el panel del proveedor de correo del destinatario si tienes acceso, o avisar al contacto con el texto literal del Diagnostic-Code. En tu propio dominio, comprueba que el alias apunta a una dirección válida y que la parte local no tiene mayúsculas ni puntos que el servidor no normalice.
Cuando el DSN menciona un host que no pertenece al dominio del destinatario, o el mensaje de error habla de “no MX record”, “host not found” o “connection refused”, el problema está en los registros MX. Ahí la búsqueda normal de dirección ni siquiera empieza: el MTA emisor no encuentra dónde entregar. Los registros MX indican qué hosts aceptan correo para el dominio y llevan una prioridad; si el registro de menor prioridad está caído o mal apuntado, el emisor prueba el siguiente, y si todos fallan, el rebote es duro con un 5.4.4 o similar.
Pasos de verificación que puedes ejecutar desde tu equipo:
- Consulta los MX con dig MX dominio.com +short o nslookup -type=MX dominio.com. Debes ver al menos un registro con prioridad baja y un host que resuelva a una IP.
- Resuelve cada host con dig A mx1.dominio.com. Un MX que apunta a un nombre sin registro A es una causa clásica de rebote duro.
- Comprueba la prioridad: dos MX con el mismo valor provocan un reparto aleatorio que puede llevar tráfico a un servidor que no acepta ese dominio.
- Verifica el registro SPF del dominio emisor si el rebote llega como rechazo por autenticación. SPF, DKIM y DMARC rigen el correo saliente, no el entrante, y un fallo de alineación se traduce en un 5.7.x que no tiene nada que ver con el alias.
Un detalle que se pasa por alto: el DSN de un rebote puede venir de un servidor intermedio, no del destino final. Si el Action es failed pero el Reporting-MTA es tu propio servidor de correo saliente, lee el campo Final-Recipient y el Original-Recipient. Ahí ves la dirección tal como salió de tu sistema, y muchas veces revela una transformación interna (un reenvío de correo, un alias encadenado) que rompió la parte local. Corrige esa cadena antes de tocar el DNS.
La regla práctica: código 5.1.x con host del destino, revisa alias y buzones. Código 5.4.x o mensajes de resolución, revisa MX, A y prioridades. Código 5.7.x, revisa autenticación y políticas. Cualquier otra combinación merece una lectura del Diagnostic-Code completo, porque la parte legible del DSN suele simplificar el motivo real.
Qué es un correo catch-all y cómo influye en los rebotes
Un correo catch-all es un ajuste en el servidor de correo que acepta cualquier mensaje enviado a un dominio, aunque la parte local no corresponda a ninguna cuenta existente. En lugar de devolver un 550 no such user, el MTA entrega el mensaje a un buzón designado. Cuando ese buzón no existe, la respuesta es clara: el servidor rechaza el destinatario y el rebote queda registrado en el DSN. Con catch-all activo, ese mismo error desaparece de la traza y el diagnóstico se complica.
El funcionamiento es sencillo si se sigue el orden de resolución del servidor. Primero busca coincidencia exacta entre la parte local y una cuenta o un alias de correo. La regla catch-all se aplica después de que falla la búsqueda normal de dirección. Si está activa, el mensaje cae en el buzón comodín, que se recoge con un solo login POP3 o IMAP. Conviene subrayar que el DNS no tiene ningún tipo de registro para activar catch-all: es una directiva del servidor de correo o del panel de hosting, no una entrada en la zona.
Por qué el catch-all enmascara rebotes y cómo configurarlo sin cegarte
El efecto más incómodo aparece en la analítica. Un dominio con catch-all puede recibir cientos de mensajes diarios dirigidos a direcciones inventadas, erratas de tecleo o intentos de sondeo. Desde fuera, el dominio parece aceptar todo, y desde dentro nadie ve el 550 no such user que debería haber alertado de un alias mal escrito o de una campaña enviada a una lista obsoleta. El rebote duro se convierte en correo entrante silencioso, y el fallo real queda enterrado en el buzón comodín.
También hay un riesgo de reputación. Si el catch-all recibe mensajes para direcciones que nunca existieron y alguien responde desde ese buzón, el dominio empieza a emitir correo saliente con remitentes que no figuran en SPF, DKIM y DMARC. Esos tres registros rigen el correo saliente y no saben nada del comodín: un envío desde cualquiercosa@tudominio.com puede fallar la alineación y acabar en spam o en un rechazo del receptor.
Pautas para configurar correo catch-all sin ocultar errores:
- Actívalo con una finalidad concreta y temporal: capturar erratas de una campaña, recibir correo de dominios antiguos tras una migración o recoger direcciones heredadas de un cambio de proveedor.
- Revisa el buzón comodín con una periodicidad fija, por ejemplo semanal, y clasifica lo recibido. Si predominan direcciones aleatorias, el catch-all está trabajando como imán de spam.
- Mantén los alias de correo y los buzones reales bien definidos antes de activar el comodín. La regla solo debe cubrir el residuo, no sustituir el enrutamiento normal.
- No respondas desde el buzón catch-all con la identidad del destinatario original. Usa una dirección real y verificada para el correo saliente.
- Documenta qué direcciones deberían existir. Si un DSN previo apuntaba a un alias roto, corrígelo en el panel de hosting y comprueba con una prueba manual que el catch-all ya no recibe ese tráfico.
El catch-all se diferencia de un alias, de un reenvío y del correo desechable. El alias apunta a una cuenta concreta, el reenvío redirige a otro destino y el desechable se abandona tras su uso. El buzón comodín, en cambio, acumula todo lo que no encaja. Úsalo como red de seguridad, nunca como sustituto de un enrutamiento limpio: si el DSN te mostró un 5.1.1, la solución pasa por arreglar la dirección, no por taparla con un comodín.
Una comprobación que lleva menos de cinco minutos y ahorra horas de soporte: toma el último DSN que tengas en la bandeja de entrada, ábrelo en vista de código fuente y localiza las tres cabeceras. Si el Status empieza por 4, no toques nada todavía; el servidor remoto está pidiendo paciencia y el mensaje sigue en cola. Si empieza por 5 y el Diagnostic-Code menciona “user unknown” o “no such user”, el problema está en la parte local de la dirección, no en el dominio. Ese es el momento de entrar en el panel de hosting, revisar si existe un alias de correo para esa dirección concreta y comprobar si el enrutamiento interno apunta al buzón correcto. Si el texto del diagnóstico habla de “no route to host”, “connection refused” o “timed out” sobre el puerto 25, la pista lleva a los registros MX y a la prioridad configurada, no al buzón.
Un detalle que se pasa por alto con frecuencia: si el dominio tiene un correo catch-all activo, un rebote 550 por dirección no coincidente puede desaparecer y convertirse en un mensaje entregado en el buzón comodín. Eso tapa el error real. Antes de dar por bueno un envío, consulta la cuenta catch-all y mira si el mensaje acabó ahí. La regla catch-all se aplica después de que falla la búsqueda normal de dirección, así que el DSN original ya no se genera. Para distinguir ambos escenarios, desactiva temporalmente el catch-all, repite el envío de prueba y observa si vuelve el 5.1.1. Recuerda que SPF, DKIM y DMARC rigen el correo saliente y no explican un rebote de entrada por dirección inexistente; mezclar ambas cosas lleva a perseguir el problema equivocado. Y si el DSN muestra Action: delayed con varios intentos, anota la hora del primer y último intento: la diferencia indica cuánto margen queda antes de que el rebote blando se convierta en duro. Con esos datos sobre la mesa, la decisión deja de ser una corazonada.
