DSN (Delivery Status Notification): format, status codes, and bounce processing

A Delivery Status Notification (DSN) is how mail servers report delivery outcomes back to the sender. When a message cannot be delivered, or when the sender explicitly requests a confirmation, the receiving or intermediate MTA generates a DSN and sends it to the Envelope From (Return-Path) address. The format is defined in RFC 3464, and generating these messages has been part of SMTP infrastructure since the early days of internet email.

What DSN actually is

DSN is what email marketers call a "bounce." That word is colloquial. In technical terms, a bounce is not just a failed delivery: it is a specific MIME message with a machine-readable status code, diagnostic text, and the headers of the original email. The format matters because automated systems at ESPs and SMTP relays parse that structure to decide what to do with the address.

A DSN is a multipart/report; report-type=delivery-status MIME message. It always contains three parts:

1. Human-readable explanation. Plain text describing what went wrong. This is what a person sees when they open a bounce message: something like "Your message could not be delivered to user@example.com."
2. Machine-readable status block. Structured fields: Status, Action, Reporting-MTA, Remote-MTA, Diagnostic-Code. Bounce processors parse this part, not the human text.
3. Original message headers (sometimes the full message). This is what lets the sender match the DSN to the specific send.

Status codes

The Status field uses the enhanced status code format from RFC 3463: three numbers separated by dots (class.subject.detail). The first number tells you the severity:

• 2.x.x — success. The message was accepted. In practice, positive DSNs are rare because most servers do not generate them unless the sender explicitly requested one.
• 4.x.x — temporary failure. The server could not deliver right now but may accept a retry. Common examples: 4.2.2 (mailbox full), 4.7.1 (greylisting in effect).
• 5.x.x — permanent failure. The address is definitively undeliverable. Common examples: 5.1.1 (user unknown), 5.2.1 (mailbox disabled), 5.7.1 (rejected by policy).

How ESPs process DSNs

Every ESP and SMTP relay parses incoming DSNs automatically. The system extracts the status code, the recipient address, and the failure type, then acts on it:

• A 5.1.x code (hard bounce) puts the address on the suppression list immediately. No further sends to that address are allowed.
• A 4.x.x code (soft bounce) queues the message for retry. After 3 to 5 consecutive failures, depending on the platform, the address also gets suppressed.
• The aggregate data feeds the bounce rate metric visible in the dashboard.

Not every rejection comes through a DSN. Some servers reject during the SMTP transaction itself, before a DSN is ever generated. In that case, the bounce is captured from the SMTP response code, not from the notification message. The outcome is the same, but the mechanism differs.

Real-world complications

DSN handling is messier in practice than the RFCs suggest. Some servers silently discard messages with no notification at all, specifically to avoid helping spammers probe which addresses are valid. Others reject at the SMTP layer, which is cleaner for the receiving side but gives the sender less diagnostic detail.

A separate problem is backscatter. If a spammer forges your address as the Envelope From, DSNs for their failed sends go to you. Those notifications are technically correct per RFC, but from your inbox they look like spam. Backscatter is itself a recognized form of abuse, and high volumes of it can affect your sending reputation.

DSN and email validation

A DSN tells you about a problem after the delivery attempt. Email validation catches the same problems before you send. SMTP verification works by issuing a RCPT TO command without sending the DATA body — the receiving server responds with the same accept or reject code it would use during real delivery. A 5.1.1 response at validation time means you avoid the bounce entirely, without spending IP reputation on a failed send.