NDR, DSN, Bounce: distinguir correctamente los informes de no entrega

Un correo no llega y en el ticket aparece «bounce», «NDR», «Mailer-Daemon» o «mensaje de error del servidor». En el día a día de la administración, estos términos se usan como sinónimos aunque designan cosas diferentes: un reject en la sesión SMTP no es un correo de devolución, una notificación de retraso no es un error de entrega y una confirmación de lectura no tiene nada que ver con la no entrega. Quien distingue correctamente los términos encuentra la causa más rápido, porque cada tipo de mensaje indica algo distinto sobre dónde se encuentra el problema en la ruta de transporte y quién puede resolverlo.

DSN: el término genérico de las RFC

El término genérico formal es Delivery Status Notification (DSN), definido en las RFC 3461 a 3464. Una DSN es un correo generado automáticamente que informa al remitente sobre el estado de entrega de su mensaje. Lo decisivo: una DSN no informa solo de fallos. El campo Action de la parte legible por máquina tiene cinco valores:

Por tanto, el informe de no entrega es solo un caso especial: una DSN con Action: failed. Microsoft denomina precisamente a este caso especial Non-Delivery Report (NDR). El término NDR procede del mundo de Exchange, pero actualmente se utiliza entre fabricantes. Para ser precisos: todo NDR es una DSN, pero no toda DSN es un NDR.

La notificación de retraso (Action: delayed) merece especial atención, porque en soporte se interpreta habitualmente como un error de entrega. Un asunto típico es «Delivery delayed» o «Entrega retrasada». El correo permanece entonces en la cola del servidor remitente, que sigue intentándolo, normalmente durante uno o dos días. Solo cuando expira la vida útil de la cola se genera el NDR definitivo. Un usuario que reenvía el correo al recibir una notificación de retraso genera duplicados en cuanto el sistema de destino vuelve a estar disponible.

Reject o bounce: la distinción más importante

Antes de abordar los demás términos, es necesario explicar la bifurcación técnica central, ya que determina qué servidor genera un mensaje.

Reject (rechazo en la sesión): El servidor receptor rechaza el correo ya durante la sesión SMTP, con un código de respuesta 5xx a RCPT TO o después de DATA. Nunca acepta el correo y tampoco genera un correo de respuesta. La obligación de informar al remitente recae en el servidor de envío: el MTA remitente ve la respuesta 5xx y genera entonces el NDR para su usuario local. En este caso, el NDR que lee el usuario procede de su propio servidor, pero cita el mensaje de error del servidor remoto.

Bounce (aceptación con devolución posterior): El servidor receptor acepta el correo con 250 OK y solo después detecta que no puede entregarlo, por ejemplo porque el buzón no existe, la cuota está llena o un servidor posterior lo rechaza. En ese momento asume la responsabilidad del mensaje y debe enviar él mismo una DSN al remitente. Este correo de devolución posterior es el bounce en sentido estricto.

Para solucionar problemas, la diferencia es directamente útil: si el NDR indica el propio servidor como sistema generador, el correo fue rechazado durante la sesión o ni siquiera llegó a salir. Si un servidor externo aparece como remitente del mensaje, la otra parte aceptó inicialmente el correo y el problema está detrás de su punto de aceptación, invisible para el remitente.

Del ámbito del marketing proceden otros dos términos relacionados con bounces que no aparecen en ninguna RFC: hard bounce para errores definitivos (5xx, Action: failed) y soft bounce para errores temporales (4xx, Action: delayed). Para las plataformas de mailing, la distinción es fundamental, ya que los hard bounces deberían llevar a una depuración inmediata de la lista. Técnicamente, son los mismos mecanismos descritos anteriormente.

Los términos de un vistazo

Estructura de una DSN

Las DSN conformes al estándar utilizan el tipo MIME multipart/report; report-type=delivery-status con tres partes: una explicación legible por humanos, una parte legible por máquina de tipo message/delivery-status y, opcionalmente, el mensaje original o sus encabezados. La parte legible por máquina es la más valiosa para el diagnóstico, ya que sus campos están normalizados:

Reporting-MTA: dns; mail01.example.net
Received-From-MTA: dns; client.example.org

Final-Recipient: rfc822; max.muster@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <max.muster@example.com>:
    Recipient address rejected: User unknown

Una DSN se envía siempre con un remitente de sobre vacío (MAIL FROM:<>). No es una negligencia, sino un requisito de RFC 5321: el remitente vacío evita que una DSN no entregable genere otra DSN y que dos servidores se envíen mensajes de error sin fin. De ello se deriva una regla de configuración: un sistema de correo no debe rechazar de forma generalizada los mensajes con remitente de sobre vacío; de lo contrario, los informes legítimos de no entrega nunca llegarán a los propios usuarios.

Exchange y Exchange Online respetan el estándar en cuanto al formato, pero presentan el contenido de una forma propia: el usuario ve una página preparada con una explicación en texto claro y, debajo, «Generating server» (equivale a Reporting-MTA) y los datos sin procesar. Para el diagnóstico, siempre merece la pena revisar esta parte técnica inferior.

Leer los Enhanced Status Codes

En el campo Status y, habitualmente, también en Diagnostic-Code, aparece un código de tres partes según RFC 3463: clase.asunto.detalle. La clase indica el carácter vinculante, y el asunto y el detalle indican la causa:

El código de respuesta SMTP clásico de tres dígitos (por ejemplo, 550) y el Enhanced Status Code suelen aparecer juntos en una línea: 550 5.7.1 .... El código de tres dígitos controla el comportamiento del protocolo del servidor remitente; el código ampliado aporta la información de diagnóstico. Si hay contradicciones entre el código y el texto libre, el texto libre del servidor remoto suele ser la fuente más precisa, ya que muchos sistemas establecen códigos genéricos y escriben la causa real en el comentario, incluidos los ID de referencia para el soporte de la otra parte.

Téngase en cuenta que los rechazos 5.7.x realizados por filtros de reputación y contenido suelen aportar deliberadamente poca información. Quien se fija únicamente en el código buscará en el lugar equivocado; la lista de bloqueo o el fabricante del filtro indicados en el texto libre conducen más rápido a la solución.

Backscatter: el tipo dañino de bounce

El backscatter se produce cuando un servidor acepta primero spam con un remitente falsificado y después envía un NDR a la dirección falsificada. El NDR llega así a una persona no implicada cuya dirección ha sido utilizada indebidamente por el spammer. En grandes oleadas de spam, los afectados reciben miles de NDR de correos que nunca enviaron, y los servidores que generan masivamente estos NDR acaban ellos mismos en listas de bloqueo (como la lista Backscatterer de UCEPROTECT).

La solución se deriva directamente de la distinción entre reject y bounce: todo lo que pueda rechazarse debe rechazarse durante la sesión SMTP, no devolverse después de aceptarlo. En concreto, esto significa validar los destinatarios en el punto de aceptación más externo (la gateway perimetral conoce las direcciones válidas, mediante comparación con el directorio o Recipient Callout, en lugar de aceptarlo todo y dejar que falle internamente), rechazar spam y malware durante la sesión en vez de generar NDR de cuarentena, y no enviar NDR para mensajes clasificados como spam. Un reject no genera backscatter, porque con un remitente falsificado la respuesta 5xx llega al servidor del spammer, que no genera a partir de ella un NDR para la víctima.

Lo que no es un informe de no entrega

Tres tipos de mensajes llegan regularmente a los tickets agrupados con los anteriores, pero no pertenecen a esta categoría:

MDN (Message Disposition Notification, RFC 8098): La confirmación de lectura. No la genera el sistema de transporte, sino el cliente de correo del destinatario, e informa de la visualización o eliminación del mensaje, no de su entrega. El tipo MIME se llama correspondientemente multipart/report; report-type=disposition-notification. La ausencia de una confirmación de lectura no dice nada sobre la entrega; la mayoría de los clientes preguntan al usuario o suprimen por completo los MDN.

Respuestas de ausencia y autorespondedores (RFC 3834): Una respuesta de ausencia demuestra lo contrario de un error de entrega, pues presupone que el correo ha llegado al buzón. En las descripciones de tickets («recibo una respuesta automática, ¿llega mi correo?»), conviene preguntar qué mensaje concreto está presente.

Notificaciones de cuarentena: Mensajes como el resumen de cuarentena de Microsoft 365 o de una gateway informan al destinatario sobre correos retenidos. Se envían al destinatario, no al remitente, y no siguen ningún estándar DSN. En este escenario, el remitente a menudo no recibe nada, lo que explica los casos en los que un correo «desaparece sin mensaje de error».

Lista de comprobación para el diagnóstico

Si hay un mensaje, aclare los siguientes puntos en este orden:

1. ¿De qué tipo se trata: NDR (Action: failed), retraso (Action: delayed), MDN, autorespondedor o aviso de cuarentena? Si es una notificación de retraso: espere, no reenvíe el mensaje.
2. ¿Quién generó el mensaje (Reporting-MTA o «Generating server»)? El propio servidor implica un reject o un error interno; un servidor externo implica aceptación con fallo posterior en el lado remoto.
3. ¿Qué indican el estado y el Diagnostic-Code? La clase 4 frente a la clase 5 separa lo temporal de lo definitivo; el asunto (x.1 dirección, x.2 buzón, x.4 red, x.7 política) delimita la causa, y el texto libre del servidor remoto proporciona los detalles.
4. Si no hay ningún mensaje aunque el correo no llega: compruebe el seguimiento de mensajes en el sistema propio y piense en cuarentena o filtrado silencioso en el lado remoto.

Los artículos sobre Message Tracking y diagnóstico SMTP en el generador de comandos y el analizador de encabezados de correo muestran cómo reproducir posteriormente rutas de entrega concretas para analizar la ruta de transporte de un correo recibido.