RFC 3464: Delivery Status Notification Format

Current Standard Delivery Status & Bounce Handling Obsoletes RFC 1894 DSNBounce Format

ELI5: When a package cannot be delivered, the courier gives you a form explaining what happened. RFC 3464 defines the standardized form that mail servers fill out when a message bounces, gets delayed, or is successfully delivered — structured so software can read it automatically.

Why This Exists

Before DSN formatting was standardized, every mail server generated bounce messages in its own free-form text format. Parsing these "bounce messages" required fragile heuristics — regular expressions that broke whenever a server changed its wording. RFC 3464 defines a machine-readable MIME content type (message/delivery-status) that makes automated bounce processing reliable.

This RFC works together with RFC 3461 (which defines how to request DSNs at the SMTP level) and RFC 3462 (which defines the multipart/report container that wraps the DSN).

How It Works

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

Human-readable explanation (text/plain) — free-form text for humans.
Machine-readable status (message/delivery-status) — the structured data defined by this RFC.
Original message (message/rfc822 or text/rfc822-headers) — the full original or just its headers, depending on the RET parameter from RFC 3461.

The delivery-status Body

The message/delivery-status part contains groups of header-like fields separated by blank lines:

; Per-message fields (one group)
Reporting-MTA: dns; mail.example.org
Original-Envelope-Id: msg-20260311-0042
Arrival-Date: Wed, 11 Mar 2026 10:30:00 -0500

; Per-recipient fields (one group per recipient)
Original-Recipient: rfc822;bob@example.org
Final-Recipient: rfc822;bob@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown
Last-Attempt-Date: Wed, 11 Mar 2026 10:30:05 -0500

Key Technical Details

Per-Message Fields

Field	Required	Description
`Reporting-MTA`	Yes	The MTA that generated this DSN, as a DNS hostname
`Original-Envelope-Id`	No	The ENVID from the original SMTP transaction (RFC 3461)
`DSN-Gateway`	No	Present when the DSN was translated from a foreign mail system
`Received-From-MTA`	No	The MTA that handed the message to the Reporting-MTA
`Arrival-Date`	No	When the original message arrived at the Reporting-MTA

Per-Recipient Fields

Field	Required	Description
`Final-Recipient`	Yes	The recipient address the MTA actually attempted delivery to
`Original-Recipient`	No	The ORCPT value from the SMTP session — the address the sender used
`Action`	Yes	One of: `failed`, `delayed`, `delivered`, `relayed`, `expanded`
`Status`	Yes	Enhanced status code per RFC 3463 (e.g., `5.1.1`)
`Diagnostic-Code`	No	The actual error string from the remote server, prefixed by type (usually `smtp`)
`Remote-MTA`	No	The MTA that returned the error
`Last-Attempt-Date`	No	When the last delivery attempt was made
`Will-Retry-Until`	No	For `delayed` actions, when the MTA will give up

Action Values

Action	Meaning
`failed`	Permanent failure — message will not be delivered (hard bounce)
`delayed`	Temporary failure — still retrying (soft bounce)
`delivered`	Successfully delivered to the recipient's mailbox
`relayed`	Forwarded to an environment that may not generate further DSNs
`expanded`	Delivered to a mailing list or alias that expanded to multiple recipients

Full DSN Message Example

From: mailer-daemon@mail.example.org
To: alice@sender.example.com
Subject: Delivery Status Notification (Failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="DSN-BOUNDARY-001"

--DSN-BOUNDARY-001
Content-Type: text/plain

Your message to bob@example.org could not be delivered.
The recipient's mailbox does not exist.

--DSN-BOUNDARY-001
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Original-Envelope-Id: msg-20260311-0042
Arrival-Date: Wed, 11 Mar 2026 10:30:00 -0500

Final-Recipient: rfc822;bob@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

--DSN-BOUNDARY-001
Content-Type: text/rfc822-headers

From: alice@sender.example.com
To: bob@example.org
Subject: Meeting tomorrow
Message-ID: <abc123@sender.example.com>

--DSN-BOUNDARY-001--

Common Mistakes

Parsing only the human-readable part. The text/plain section is for humans. Automated systems should parse the message/delivery-status part, which has a stable, defined structure.
Ignoring the Status code class. The first digit is critical: 2.x.x = success, 4.x.x = temporary failure (retry later), 5.x.x = permanent failure (stop trying). Treating all bounces the same damages your reputation.
Not matching Original-Envelope-Id. If you set ENVID in RFC 3461, use Original-Envelope-Id to correlate DSNs back to specific sends. Relying on Final-Recipient alone fails when aliases or forwarding are involved.
Confusing Final-Recipient with Original-Recipient. After forwarding, Final-Recipient may be a completely different address. Always check Original-Recipient when available.
Treating relayed as delivered. A relayed action means the message left the DSN-aware environment. You may never get a final status.

Deliverability Impact

Automated bounce classification. The Status field maps to RFC 3463 enhanced status codes. Code 5.1.1 (user unknown) means remove the address; 4.2.2 (mailbox full) means retry later. Correct classification is the foundation of list hygiene.
Feedback loop correlation. The Original-Envelope-Id lets you tie bounces to specific campaigns, API calls, or transactions — essential for debugging and analytics.
Hard vs. soft bounce handling. Treat Action: failed with 5.x.x status as permanent — suppress the address. Treat Action: delayed with 4.x.x as transient — retry with backoff but suppress after repeated failures.
Reputation protection. Processing DSNs promptly and removing invalid addresses prevents you from repeatedly hitting dead mailboxes, which mailbox providers track as a negative reputation signal.