Enviaste la cotización con la factura adjunta hace cinco minutos. En la bandeja de entrada aparece un correo con un remitente como MAILER-DAEMON o Mail Delivery System y el asunto “Undelivered Mail Returned to Sender”. Lo abres: párrafos en inglés, siglas y un bloque de texto apretado. Cierras la ventana y te quedas con la duda de si el cliente recibió algo.
Ese aviso es un rebote, y casi siempre contiene la respuesta a esa duda. Solo hay que saber qué líneas mirar.
Qué es un rebote y quién lo genera
Un rebote es un mensaje nuevo y automático que genera un servidor de correo cuando no logra entregar lo que enviaste. No es un acuse de recibo: es un aviso de falla, y cuando informa un error permanente significa que el mensaje no llegó a la bandeja del destinatario.
Normalmente lo genera uno de estos dos servidores:
- Tu propio servidor de salida (por ejemplo,
mail.tuempresa.cl). Intentó entregar el mensaje y no pudo, porque el dominio de destino no existe, porque el otro servidor no respondió o porque lo rechazó. Entonces te devuelve el aviso, muchas veces copiando la respuesta que le dio el otro lado. - El servidor de destino, el que recibe el correo de
[email protected]. En algunos casos acepta el mensaje primero y lo rechaza después, y es él quien te envía el aviso.
Saber quién respondió cambia la lectura. Un “host not found” escrito por tu servidor apunta a un dominio mal escrito o inexistente. Un 5.7.1 que viene del servidor del cliente habla de una política de ese receptor.
Las tres partes del aviso que debes mirar
El formato varía según el programa, pero la mayoría de los avisos traen un resumen legible arriba y un bloque técnico más abajo, a veces como adjunto o en una sección aparte. En ese bloque busca tres datos.
El destinatario que falló
Ubica la dirección exacta que rebotó. En la parte técnica aparece como Final-Recipient (y a veces Original-Recipient). Confirma que sea la dirección que querías usar: un error de tipeo en el dominio, como ejemplo.cl en vez de ejemplo.com, es una causa común y la más rápida de corregir.
El servidor que respondió
Hay dos líneas que se confunden. Reporting-MTA indica qué servidor escribió el aviso, que suele ser el tuyo. Remote-MTA indica con qué servidor del otro lado se estaba conversando cuando llegó el rechazo. Si Remote-MTA muestra un servidor del dominio de tu cliente, el rechazo vino de su lado.
Código y texto de diagnóstico
Aquí está lo útil. Busca las líneas Status: y Diagnostic-Code:. La primera trae un código de tres partes, como 5.1.1. La segunda trae el texto que respondió el servidor, que suele incluir un código de tres dígitos (550, 552, 554 u otro) y una explicación breve, por ejemplo smtp; 550 5.1.1 User unknown.
Si tu programa no muestra ese bloque, busca en el menú del mensaje una opción para ver el original o el código fuente; el nombre cambia según el programa o el webmail.
Error temporal y error permanente
El primer dígito del código indica la gravedad.
4.x.x (o respuestas 4xx): temporal. El servidor no acepta el mensaje en este momento, pero podría aceptarlo más tarde. Tu servidor lo reintenta solo durante un plazo que depende de su configuración y que suele ser de varios días; la norma del correo (RFC 5321) recomienda no rendirse antes de cuatro o cinco. Algunos servidores te envían un aviso de retraso mientras siguen intentando, y el mensaje puede llegar igual más tarde.
5.x.x (o respuestas 5xx): permanente. El servidor rechazó el mensaje y no habrá más reintentos. Reenviar lo mismo sin cambiar nada solo produce otro rebote: hay que corregir la causa.
Ojo con una confusión habitual: permanente no significa que la culpa sea del destinatario. Un rechazo por política o por autenticación muchas veces apunta a tu propio dominio.
Códigos frecuentes y qué hacer
| Código | Qué significa | Qué hacer |
|---|---|---|
| 5.1.1 | La casilla no existe en ese dominio | Revisa la ortografía y confirma la dirección con tu contacto por otra vía antes de reenviar. |
| 5.1.2 | El dominio o sistema de destino no es válido | Revisa el dominio completo: .cl o .com, guiones, letras de más. |
| 5.2.1 | La casilla existe, pero está deshabilitada | Es probable que la persona ya no use esa cuenta. Busca otro contacto en la empresa. |
| 5.2.2 | Casilla llena | Avisa al destinatario por otra vía y reintenta cuando libere espacio. |
| 5.3.4 (a veces con 552) | Mensaje demasiado grande | Comprime los adjuntos o compártelos con un enlace. El límite lo fija cada servidor. |
| 5.7.1 | Entrega no autorizada: filtro antispam, bloqueo, autenticación o lista de bloqueo | No reenvíes de inmediato. Lee el texto del diagnóstico y revisa la sección siguiente. |
| 4.2.2 | Casilla llena, informado como temporal | Tu servidor seguirá intentando. Si persiste, avisa por otra vía. |
| 4.7.x | Rechazo temporal por política, por ejemplo greylisting | Algunos servidores rechazan el primer intento a propósito. Normalmente el reintento automático lo resuelve. |
Cada servidor redacta el texto a su manera, así que usa el código como guía y lee siempre la frase que lo acompaña.
¿El problema es del destinatario o de tu dominio?
Una regla práctica ahorra mucho tiempo.
Si rebota una sola dirección y tus correos al resto de ese dominio llegan sin problema, el asunto está en esa casilla: mal escrita, llena o deshabilitada.
Si rebotan destinos distintos con códigos 5.7.x, o los textos mencionan SPF, DKIM, DMARC, “not authorized” o spam, mira tu lado. Revisa con quien administra tu correo que los registros de autenticación de tu dominio estén publicados y que incluyan todos los servicios que envían en tu nombre, y que la dirección IP de salida no aparezca en listas de bloqueo. Si ese es tu caso, te pueden servir las guías sobre correos que llegan a spam, un solo SPF para facturador y boletín y reportes DMARC.
Una señal que no conviene pasar por alto: si en tu carpeta Enviados aparecen mensajes que no escribiste, o recibes muchos rebotes justo cuando tu cuenta envió correos reales que no reconoces, puede haber una cuenta comprometida. Cambia la contraseña, cierra las sesiones abiertas y activa la verificación en dos pasos si tu servicio la ofrece.
Rebotes falsos: avisos de mensajes que no enviaste
A veces llega un aviso de entrega fallida por un correo que nunca salió de tu empresa. Lo habitual es que alguien haya usado tu dirección como remitente falso; el servidor que rechazó ese envío te devuelve el aviso a ti. A esto se le llama backscatter.
No abras los adjuntos ni hagas clic en los enlaces: algunos de estos avisos son, en realidad, phishing con apariencia de rebote. Revisa tu carpeta Enviados. Si no hay envíos que no reconozcas, se trató de una suplantación del remitente y puedes borrar el aviso. Si los hay, trátalo como una cuenta comprometida. Tener SPF, DKIM y una política DMARC aplicada en tu dominio hace que más servidores descarten esos envíos falsos, lo que reduce la suplantación y estos avisos.
Qué copiar antes de pedir ayuda
Cuando escribas a soporte, incluye:
- El aviso de rebote completo, reenviado como adjunto o con su código fuente, no una captura recortada.
- La fecha y hora del envío original y del aviso.
- La dirección de destino exacta y el asunto del mensaje original.
- Si falla una sola dirección o varias, y si son del mismo dominio.
- Si había adjuntos, su tamaño aproximado.
Si eres cliente de Bitsur, puedes reenviar el aviso a [email protected] o abrir un ticket en cliente.bitsur.cl. Con el aviso completo revisamos de dónde vino el rechazo y te decimos si hay que corregir algo en tu dominio o si depende del destinatario.