The 7-step forward-path delivery (covered in Email Delivery Journey) is only half the story. When a message cannot be delivered, the SMTP infrastructure must communicate that failure back to the sender. This reverse-path communication relies on two mechanisms: Delivery Status Notifications (DSN) and bounce messages.
This post covers DSN — the protocol-level mechanism for requesting and generating delivery receipts.
The Envelope vs. the Header
To understand reverse-path routing, you must first understand the distinction between the SMTP envelope and the message headers.
| Concept | Example | Used For |
|---|---|---|
| Envelope From (MAIL FROM) | <[email protected]> |
Return-path for bounces and DSNs. Set by the sending MTA. |
| Envelope To (RCPT TO) | <[email protected]> |
Directs SMTP delivery. Set per-recipient. |
| Header From | From: Alice <[email protected]> |
Displayed to the user in their email client. |
| Header To | To: Bob <[email protected]> |
Displayed to the user. May differ from envelope. |
The Return-Path header, added by the final delivering MTA, records the
envelope MAIL FROM address. This is where bounces and DSNs are sent.
Delivery Status Notifications (DSN)
Defined in RFC 3461–3464, DSN extends SMTP (via the EHLO extension
mechanism) so that sending MTAs can request specific types of delivery
notifications:
| Notification Type | Meaning |
|---|---|
| Success | Confirm the message was delivered successfully. |
| Delay | Warn that delivery is taking longer than expected but is still being attempted. |
| Failure | Notify that delivery has permanently failed (bounce). |
| Relay | Report that the message was relayed to another destination. |
The NOTIFY Parameter
DSN is negotiated during the EHLO handshake. If the server advertises
DSN in its capabilities, the sending MTA may include NOTIFY= parameters
in the RCPT TO command:
RCPT TO: <[email protected]> NOTIFY=FAILURE,DELAY
The receiving MTA, if it supports DSN, will later generate a machine-
readable DSN message addressed to the envelope MAIL FROM address. The
DSN itself is a structured MIME message containing:
- A human-readable explanation.
- A machine-parsable
message/delivery-statusbody part with status fields per-recipient (Status:,Action:,Remote-MTA:, etc.). - Optionally, the original message content or headers (the
return of contentfeature).
DSN in Practice
DSN is opt-in — most MTAs do not request it by default. It is most commonly used in:
- Transactional email systems that need delivery confirmation.
- Automated mailing lists that suppress addresses after repeated failures.
- Bulk senders that monitor delivery health per-recipient.
Relationship to Bounces
While DSN is a structured, machine-readable protocol extension, a bounce is a simpler human-readable notification generated when the server cannot deliver a message. Bounces are covered in detail in SMTP Bounces & the Null Reverse-Path.