← RFC Reference

RFC 3461: SMTP Delivery Status Notification Extension

Why This Exists

Basic SMTP (RFC 5321) only guarantees you will hear about failures — the receiving server generates a bounce message if delivery ultimately fails. But senders often need more:

• Positive confirmation that a message was delivered to the recipient's mailbox
• Delay notifications when a message is stuck in a queue
• Selective reporting — only notify on failure, or only on success
• Envelope-level tracking using an opaque identifier the sender can correlate back to the original submission

Without this extension, senders are blind: silence could mean successful delivery or a lost message. RFC 3461 adds SMTP parameters that let the originating MTA explicitly request delivery status notifications (DSNs) and control their content.

How It Works

The DSN extension is negotiated during the SMTP EHLO handshake. When the receiving server advertises DSN, the sender can use two new sets of parameters:

MAIL FROM Parameters

• RET=FULL or RET=HDRS — controls whether DSN messages include the full original message body or just the headers. HDRS is recommended for large messages.
• ENVID=value — an envelope identifier (up to 100 xtext-encoded characters) that will be returned in any DSN, allowing the sender to correlate the notification with the original message.

RCPT TO Parameters

• NOTIFY=conditions — a comma-separated list of: SUCCESS, FAILURE, DELAY, or the special value NEVER. This controls when a DSN is generated.
• ORCPT=type;address — the original recipient address (before any alias expansion or forwarding), so the DSN can report the address the sender actually intended.

SMTP Session Example

EHLO sender.example.com
250-mail.example.org Hello
250-SIZE 52428800
250-DSN
250 STARTTLS

; Request DSN with envelope ID, return headers only on bounce
MAIL FROM:<alice@sender.example.com> RET=HDRS ENVID=msg-20260311-0042
250 OK

; Notify on success or failure, preserve original recipient
RCPT TO:<bob@example.org> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;bob@example.org
250 Accepted

; Suppress all DSNs for this recipient
RCPT TO:<bcc-copy@archive.example.com> NOTIFY=NEVER
250 Accepted

DATA
354 Start mail input
[message content]
.
250 OK

Key Technical Details

NOTIFY Values

If NOTIFY is omitted, the default behavior is equivalent to NOTIFY=FAILURE — you only get notified on permanent failure.

ENVID Encoding

The ENVID value uses xtext encoding: printable ASCII characters pass through unchanged, but + and = (and characters outside the printable ASCII range) are encoded as +XX where XX is the hex value. This keeps the parameter safe for SMTP transport.

Relay Behavior

Intermediate MTAs that support DSN must propagate the DSN parameters when relaying. If an intermediate MTA does not support DSN, it must still generate appropriate bounce messages per standard SMTP rules, though the fine-grained DSN controls will be lost.

Common Mistakes

• Combining NEVER with other values. NOTIFY=NEVER,FAILURE is invalid. NEVER must appear alone.
• Using DSN parameters without checking EHLO. If the server does not advertise DSN, including these parameters will cause a syntax error (code 501).
• Expecting DSN from all servers. DSN support is optional. Many large mailbox providers do not advertise it, meaning you cannot force Gmail or Outlook to send you success notifications.
• Using RET=FULL for large messages. This causes the entire original message (including attachments) to be included in the DSN, which can hit size limits or waste bandwidth.
• Forgetting ORCPT during forwarding. If your server expands aliases or forwards mail, omitting ORCPT means the DSN will report the final address, not the one the sender used.

Deliverability Impact

DSN support is critical infrastructure for professional email sending:

• Bounce processing. Programmatic bounce handling relies on DSN to identify which recipient failed and why. The ENVID parameter lets you correlate bounces back to specific campaigns or transactions.
• List hygiene. NOTIFY=FAILURE (the default) ensures you learn about invalid addresses. Prompt removal of bouncing addresses protects your sender reputation.
• Suppressing unnecessary traffic. Use NOTIFY=NEVER for BCC copies or archive addresses where you do not need delivery confirmation.
• Delay awareness. NOTIFY=DELAY alerts you to delivery problems before they become permanent failures, giving you time to investigate.

Related RFCs