Leer a interpretar un bounce
Módulo 6: Rebotes y resolución de problemas · Tiempo de lectura: 11 minutos
Objetivo de la lección: Después de esta lección podrá analizar un aviso de error sobre un correo no entregado (un bounce): qué servidor dio el error, para qué dirección, qué significa el código y si es temporal o definitivo.
Conceptos clave: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, código de respuesta (RFC 5321), código de estado extendido X.Y.Z (RFC 3463), aviso de aplazamiento, backscatter
¿Qué es un bounce?
Si un servidor de correo no puede entregar un mensaje, envía un aviso de vuelta al remitente. Esto se llama un bounce (o: non-delivery report, NDR). Llega desde un remitente como Mailer-Daemon@..., MAILER-DAEMON o Mail Delivery System, con un asunto como:
Mail delivery failed: returning message to senderUndelivered Mail Returned to SenderDelivery Status Notification (Failure)Warning: message ... delayed 24 hours(esto no es un bounce sino un aviso de aplazamiento, véase más abajo)
Muchas personas tiran este tipo de mensaje de inmediato, o se asustan al ver el texto en inglés. Es una lástima, porque un bounce casi siempre indica con precisión qué ha fallado. Solo hay que saber dónde mirar.
Un bounce siempre tiene un remitente de sobre vacío (Return-Path: <>). Esto es intencionado: un bounce sobre otro bounce podría provocar un bucle infinito (RFC 5321).
¿Quién ha rechazado el correo?
Un correo pasa por al menos dos servidores: el de su proveedor y el del destinatario. Un bounce puede generarse en dos situaciones:
- El servidor receptor rechaza el correo durante la conversación SMTP (lección 1.2), por ejemplo tras
RCPT TO(dirección desconocida) o tras el contenido (spam o DMARC). Su propio servidor recibe ese rechazo y genera un bounce para usted. En ese caso, el error proviene del destinatario, pero el bounce lo genera su propio servidor. - Su propio servidor se rinde, por ejemplo porque el destinatario ha sido inalcanzable durante varios días, o porque usted mismo ha alcanzado un límite.
La distinción es importante: en el primer caso debe averiguar qué no le gustó al destinatario; en el segundo caso, el problema está más cerca de casa.
La parte legible
En la parte superior aparece un texto dirigido a personas. Varía según el software de correo, pero casi siempre contiene lo mismo:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
pieter.devries@example.net
host mx1.example.net [198.51.100.20]
SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknownInterprételo así:
| Fragmento | Qué significa |
|---|---|
permanent error | Definitivo: el servidor no volverá a intentarlo |
pieter.devries@example.net | La dirección para la que falló (si hay varios destinatarios: solo esta) |
host mx1.example.net [198.51.100.20] | El servidor del destinatario con el que se estableció la conversación |
SMTP error from remote mail server | El error provino del destinatario, no de su propio servidor |
after RCPT TO | En qué momento de la conversación: aquí, al indicar el destinatario |
550 5.1.1 ... User unknown | El código y el texto del destinatario: esta dirección no existe |
La parte para máquinas: el DSN
Debajo del texto suele haber una parte destinada a programas, la delivery status notification (RFC 3464). Siempre tiene la misma estructura, lo que facilita su lectura:
Reporting-MTA: dns; mail.hosting.example
Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown| Campo | Significado |
|---|---|
Reporting-MTA | El servidor que escribió este bounce (generalmente su propio servidor de envío) |
Final-Recipient | La dirección en cuestión |
Action | failed (fallido, definitivo), delayed (aplazado, se sigue intentando), a veces delivered o relayed |
Status | El código de estado extendido, véase más abajo |
Remote-MTA | El servidor del otro lado que dio la respuesta |
Diagnostic-Code | La respuesta literal de ese servidor: aquí está la razón real |
Will-Retry-Until | Con delayed: hasta cuándo seguirá intentándolo el servidor |
Al final del todo aparece el correo original o solo sus cabeceras. Ahí puede ver de qué correo se trataba, y qué dirección de remitente y qué Return-Path se utilizaron. Esto a veces es la clave de la solución (véase el caso de DMARC en el ejercicio).
Cómo leer los códigos
Hay dos tipos de códigos, y casi siempre aparecen ambos en un bounce.
El código de respuesta (RFC 5321): tres cifras, como 550 o 451. La primera cifra es la más importante:
| Empieza por | Significado | Qué hace el servidor de envío |
|---|---|---|
2 | Correcto | Nada más, el correo ha sido aceptado |
4 | Error temporal | Guarda el correo y vuelve a intentarlo más tarde |
5 | Error definitivo | Se rinde y envía un bounce |
El código de estado extendido (RFC 3463): tres números separados por puntos, como 5.1.1 o 4.7.500. El primer número vuelve a ser 2, 4 o 5. El segundo número indica dónde está el problema:
| Segundo número | Tema | Ejemplos |
|---|---|---|
X.1 | Dirección | 5.1.1 la dirección no existe, 5.1.2 el dominio no existe |
X.2 | Buzón | 5.2.2 / 4.2.2 buzón lleno, 5.2.1 buzón deshabilitado |
X.3 | Sistema de correo | 5.3.4 mensaje demasiado grande |
X.4 | Red y ruta | 4.4.1 sin respuesta, 4.4.7 demasiado tiempo en cola, 5.4.4 sin ruta |
X.5 | Protocolo | 5.5.1 comando no válido |
X.6 | Contenido | 5.6.0 problema con el contenido o la codificación |
X.7 | Seguridad y política | 5.7.1 rechazado, 5.7.26 no autenticado (Gmail), 5.7.509 DMARC (Microsoft) |
El tercer número es la razón precisa. Los grandes proveedores usan sus propios números para esto, como Gmail con 5.7.25 a 5.7.30 y Microsoft con 4.7.500 y 5.7.509. Están documentados en sus propias fuentes (lección 6.2).
Regla práctica: el código que empieza con un 5 y tiene un 7 en el medio (5.7.x) es casi siempre una cuestión de política: autenticación, reputación o spam. Reenviar el correo no ayuda en ese caso; hay que cambiar algo.
Aplazado todavía no es fallido
Ante un error temporal (4xx), su servidor guarda el correo y vuelve a intentarlo. La RFC 5321 recomienda insistir durante al menos cuatro o cinco días, con al menos media hora entre intentos. Muchos servidores envían, al cabo de unas horas o de un día, un aviso de aplazamiento:
Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100Esto significa: no reenviar, el propio servidor todavía lo está intentando. Si lo reenvía de todos modos, es posible que el destinatario lo reciba dos veces. Si finalmente no se consigue antes de Will-Retry-Until, llegará un bounce real, a menudo con 4.4.7 (mensaje caducado en la cola).
Bounces falsos: backscatter
¿Recibe de repente docenas de bounces de correos que nunca envió? Mire entonces el correo original al final del mensaje. Si ahí aparece un remitente de su dominio, pero un servidor y un texto que no reconoce, entonces un spammer ha usado su dirección como remitente. Los destinatarios envían sus bounces de vuelta a usted. Esto se llama backscatter.
En ese caso, su buzón normalmente no ha sido hackeado (véase la lección 3.4 para la diferencia). Lo que ayuda: una política DMARC que se vuelve más estricta paso a paso (lección 4.4), de modo que los destinatarios rechacen el correo falsificado antes de que se genere un bounce. Conviene revisar igualmente su correo enviado y consultar con su proveedor si realmente no se ha enviado nada desde su buzón.
En la práctica: así se ve
En WebOké, además del bounce, puede ver en Seguimiento de E-Mail en DirectAdmin qué hizo el servidor con un mensaje: Entregado, Aplazado o Falla, junto con la respuesta del servidor receptor. Otros paneles suelen tener un registro de correo o "rastreo de mensajes" similar; en Microsoft 365, por ejemplo, se llama seguimiento de mensajes. Es recomendable mirar ahí primero si no ha recibido un bounce, o si alguien le dice que su correo no llegó.
Resumen
- Un bounce proviene de Mailer-Daemon y tiene un Return-Path vacío. Léalo, casi siempre indica con precisión qué ha fallado.
- Compruebe primero quién dio el error (
SMTP error from remote mail server= el destinatario) y para qué dirección. - En la parte para máquinas:
Action,Status,Remote-MTAy sobre todoDiagnostic-Code. - Primera cifra: 4 = temporal, 5 = definitivo. Segundo número: 1 dirección, 2 buzón, 3 sistema, 4 ruta, 5 protocolo, 6 contenido, 7 política.
- Aviso de aplazamiento (
delayed): no reenviar. Bounces de correos que usted no envió: backscatter.
Cuestionario
Ejercicio
Ejercicio Z6.1: Analizar tres bounces. Recibirá tres bounces de ejemplo (bounce-1.txt, bounce-2.txt y bounce-3.txt). Complete para cada bounce: la dirección para la que falló, el servidor que dio el error (Remote-MTA), el código de estado, si es temporal o definitivo, y qué debe hacer el remitente (elija de una lista). El programa lo revisa con una clave fija y da explicaciones por cada campo.
Para saber más
Los pasos de estos artículos son válidos para los paneles de WebOké; en otros proveedores funciona de forma similar.
- Fallo en la entrega del correo: cómo interpretar el mensaje de error y qué significan los códigos
- Mensaje de error: 550 5.5.0 Requested action not taken: mailbox unavailable
- Comprobar si un correo ha llegado con el seguimiento de correo de DirectAdmin
- Manual de DirectAdmin 9.3: Seguimiento de E-Mail: ¿dónde ha ido a parar mi correo?
- RFC 3464 (estructura de un DSN), RFC 3463 (códigos de estado extendidos), RFC 5321 apartado 4.2 (códigos de respuesta) y 4.5.4.1 (reintentos)