What this RFC defines
RFC 3464 defines the DSN (Delivery Status Notification) format, the machine-readable structure used in bounce messages. When an email fails to deliver, the bouncing server generates a DSN that includes the original message headers, a human-readable explanation, and a machine-readable status block with standardised status codes.
Where you see it in practice
The structured bounce messages your ESP processes to identify hard bounces (user unknown) versus soft bounces (mailbox full) use the DSN format from RFC 3464. The three-part status code in bounce messages (5.1.1 for unknown user, 4.2.2 for mailbox full, 5.7.1 for policy rejection) is defined in RFC 3464’s status code field. When your ESP marks an address as a hard bounce after a 5.x.x DSN, it is parsing this format.
How it connects to other RFCs
RFC 3464 works alongside RFC 5321 (SMTP) and RFC 5322 (message format). RFC 6522 defines the multipart/report MIME type that wraps DSN messages. RFC 3798 (MDN, read receipts) uses a similar format. RFC 5965 (ARF, abuse reports) is a related feedback format used by mailbox providers for complaint reporting.
Current status
RFC 3464 is a current standard, published January 2003. The DSN format it defines is universally supported by MTAs and ESPs. The status codes it defines (enhanced mail system status codes) are the basis for the bounce classification logic in every major email verification and sending platform.
The DSN message format
RFC 3464 defines the Delivery Status Notification (DSN) format, which is what bounce messages use to convey structured information about delivery outcomes. A DSN is a multipart/report message with three parts: a human-readable explanation for the recipient, a machine-readable per-recipient status report (Content-Type: message/delivery-status), and the original message headers (or the entire original message). The machine-readable part contains fields like Action (failed, delayed, delivered, relayed), Status (5.1.1, 4.4.7, etc), Diagnostic-Code, and Final-Recipient.
Reading a bounce message
The Status field in a DSN follows RFC 3463 enhanced status codes: X.Y.Z, where X is the class (2 success, 4 transient, 5 permanent), Y is the subject (0 other, 1 addressing, 2 mailbox, 3 mail system, 4 network, 5 protocol, 6 media, 7 security), and Z is a detail. A status of 5.1.1 means permanent failure, addressing problem, bad destination mailbox (user unknown). Understanding this taxonomy is essential for automated bounce handling: you retry on 4.x.x, unsubscribe on 5.1.x, and investigate on 5.7.x (policy-related, often deliverability issues).
DSN request flags
SMTP senders can request DSN reporting behavior via the DSN extension (advertised as DSN in EHLO). RCPT TO commands can include NOTIFY=SUCCESS, NOTIFY=FAILURE, NOTIFY=DELAY parameters. Most transactional email uses NOTIFY=FAILURE to receive bounces without success confirmations. Bulk email services like SendGrid and Mailgun handle DSN parsing automatically and expose bounces through webhooks, so most senders never see the raw DSN format. If you handle mail directly (via Postfix, Exim, or a custom MTA), understanding RFC 3464 is essential for bounce handling.
RFC 3464 (January 2003) defines the Delivery Status Notification (DSN) format, the machine-readable structure of bounce messages. A DSN is a multipart/report; report-type=delivery-status message per RFC 6522, with three parts: human-readable text, machine-readable delivery-status block, and original message (or its headers). Enhanced status codes (X.Y.Z per RFC 3463) surface bounce classification (5.1.1 user unknown, 4.2.2 mailbox full, 5.7.1 policy rejection). Sibling of MDN (RFC 3798, RFC 8098) and ARF (RFC 5965). Obsoletes RFC 1894.
RFC 3464 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Machine-readable format for delivery status (bounces, delays, receipts) |
| Generated by | Mail Transfer Agent (MTA) when a delivery event needs reporting |
| MIME wrapper | multipart/report; report-type=delivery-status (RFC 6522) |
| Status code format | X.Y.Z enhanced codes per RFC 3463 (class.subject.detail) |
| Action values | failed, delayed, delivered, relayed, expanded |
| Sender request | NOTIFY parameter on RCPT TO (per RFC 5321 DSN extension) |
| Published | January 2003 (obsoletes RFC 1894) |
| Typical use | Bounce classification, suppression list management |
The DSN multipart/report structure
A DSN is transported as a standard email message with a specific MIME structure. The outer Content-Type carries the report-type parameter that identifies it as a DSN (as opposed to an MDN or ARF, which use the same multipart/report envelope).
| Part | Content-Type | Purpose | Required? |
|---|---|---|---|
| 1 (human-readable) | text/plain | Free-form explanation for the sender | Yes |
| 2 (machine-readable) | message/delivery-status | Structured per-recipient status block | Yes |
| 3 (original) | message/rfc822 or text/rfc822-headers | Original message or its headers | Recommended |
Complete delivery-status field reference
The second MIME part (Content-Type: message/delivery-status) is where the machine-readable status lives. It contains a per-message header block followed by one or more per-recipient header blocks separated by blank lines.
| Field | Scope | Purpose | Required? |
|---|---|---|---|
Reporting-MTA | Per-message | The MTA that generated this DSN | Required |
Received-From-MTA | Per-message | MTA that delivered the message being reported on | Optional |
Arrival-Date | Per-message | When Reporting-MTA received the original | Optional |
Original-Envelope-Id | Per-message | ENVID from RCPT TO (for correlation) | Optional |
Original-Recipient | Per-recipient | Address as sent (from ORCPT parameter) | Recommended |
Final-Recipient | Per-recipient | Address after aliases/forwarding resolved | Required |
Action | Per-recipient | What happened: failed, delayed, delivered, relayed, expanded | Required |
Status | Per-recipient | Enhanced status code X.Y.Z per RFC 3463 | Required |
Diagnostic-Code | Per-recipient | The actual SMTP reply from the far MTA | Recommended |
Remote-MTA | Per-recipient | MTA that produced the Diagnostic-Code | Optional |
Last-Attempt-Date | Per-recipient | When Reporting-MTA last tried delivery | Optional |
Will-Retry-Until | Per-recipient | For delayed action, when retries stop | Optional (delayed only) |
Action values
| Action | Meaning | Sender should |
|---|---|---|
failed | Permanent delivery failure | Stop retrying; usually add to suppression list if 5.x.x address error |
delayed | Transient failure, will retry | Wait for eventual failed or delivered |
delivered | Successful final delivery | Only sent when NOTIFY=SUCCESS was requested |
relayed | Passed to non-DSN system; no further reports | Treat as terminal success |
expanded | Alias/list expanded; per-member reports may follow | Watch for per-member DSNs if requested |
Enhanced status codes (RFC 3463)
The Status field carries the X.Y.Z enhanced code from RFC 3463. X is the class (2 success, 4 persistent transient, 5 permanent), Y is the subject, Z is the detail.
| Y (subject) | Meaning | Common Z values |
|---|---|---|
| 0 | Other / Undefined | 4.0.0 transient generic, 5.0.0 permanent generic |
| 1 | Addressing | 5.1.1 no such user, 5.1.2 bad domain, 5.1.3 bad address syntax, 5.1.6 destination mailbox has moved, 5.1.10 recipient overquota |
| 2 | Mailbox | 4.2.2 mailbox full, 5.2.0 other mailbox status, 5.2.1 mailbox disabled, 5.2.3 message too large |
| 3 | Mail system | 4.3.0 mail system full, 5.3.4 message too big for system |
| 4 | Network / Routing | 4.4.1 no answer from host, 4.4.7 message expired |
| 5 | Mail protocol | 5.5.0 protocol error, 5.5.2 syntax error, 5.5.4 invalid command arguments |
| 6 | Message content / Media | 5.6.1 media not supported, 5.6.3 conversion required but not supported |
| 7 | Security / Policy | 5.7.0 other security, 5.7.1 delivery not authorized (SPF/DMARC/blocklist), 5.7.25 no PTR record, 5.7.26 DMARC alignment failure |
A complete DSN example
Requesting DSN behavior with NOTIFY and ORCPT
SMTP senders control DSN generation via the RFC 5321 DSN extension (advertised as DSN in EHLO response). RCPT TO commands accept parameters:
DSN vs MDN vs ARF: which is which
| Aspect | DSN (RFC 3464) | MDN (RFC 3798/8098) | ARF (RFC 5965) |
|---|---|---|---|
| What it reports | Delivery outcome | User interaction (read/deleted/etc) | Abuse/spam complaint |
| Generated by | MTA | MUA (mail client) | Receiving ISP (feedback loop) |
| Report-type | delivery-status | disposition-notification | feedback-report |
| Trigger | Delivery event (auto) | User opens message | User hits “Mark as spam” |
| Reliability | Near 100% on failures | Under 5% consumer | Depends on FBL registration |
| Typical use | Bounce processing | Read tracking (rarely useful) | Complaint suppression |
Common DSN parsing pitfalls
MAIL FROM:<>) to prevent loops. If you generate DSNs yourself, follow this rule. If you receive a DSN with a non-null Return-Path, be cautious about generating a bounce for it.Related standards and further reading
- RFC 6522: multipart/report container format
- RFC 3463: Enhanced Mail System Status Codes (the X.Y.Z taxonomy)
- RFC 3798 / RFC 8098: Message Disposition Notifications (MDN, sibling format)
- RFC 5965: Feedback Reports (ARF, abuse complaint format)
- RFC 5337: Internationalized DSN and MDN
- RFC 6533: Internationalized DSN status codes
- RFC 5321: SMTP DSN extension (NOTIFY, ORCPT, RET, ENVID parameters)
- DSN Parsing Guide: production-ready parsing patterns
- Hard Bounce vs Soft Bounce: 4.x.x vs 5.x.x classification
- Suppression Lists Best Practices: acting on bounce signals
- Feedback Loops and ARF Guide: complaint reporting
- Authentication-Results Header: understanding 5.7.x rejections
- Received Headers and Trace Chain: correlating DSN with the delivery path
Frequently asked questions
What is the difference between a DSN and a bounce message?
A bounce message is any email generated in response to a delivery failure. A DSN is the standardized, machine-readable format for bounces defined by RFC 3464. Most modern MTAs generate DSN-formatted bounces, but non-DSN bounces still exist (usually from older systems, non-standard MTAs, or custom bounce handlers). ESPs typically parse both DSN and non-DSN bounces via heuristics on the message body. The DSN parsing guide covers both cases.
How do I know whether a bounce is permanent or temporary?
Read the Status field of the machine-readable delivery-status part. The first digit indicates persistence: 5 is permanent (do not retry, address the underlying issue, typically add to suppression list for address errors), 4 is persistent transient (retry per your schedule until it becomes 5.x.x or delivered), 2 is success (only surfaced if NOTIFY=SUCCESS was requested). See Hard Bounce vs Soft Bounce for classification patterns.
Why do some bounces have both a 550 SMTP code and a 5.1.1 DSN code?
The 550 is the three-digit SMTP reply from the receiving server per RFC 5321; the 5.1.1 is the enhanced status code per RFC 3463 that adds semantic detail. Both codes are meant to be present in modern DSNs (RFC 5321 section 3.7.5 says servers advertising ENHANCEDSTATUSCODES should include both). The three-digit code tells you the class; the X.Y.Z code tells you the specific reason. Parse both, but prioritize the X.Y.Z code for classification because it is standardized across MTAs.
How does DSN relate to the DSN SMTP extension?
The DSN extension is defined across RFC 3461 (SMTP protocol side) and RFC 3464 (the message format itself). RFC 3461 defines the EHLO advertisement (DSN), the NOTIFY parameter on RCPT TO, and the RET and ENVID parameters on MAIL FROM. RFC 3464 defines the format of the resulting DSN message. The two together let a sender request specific reporting behavior and receive machine-readable results.
Why should DSN messages have an empty Return-Path?
To prevent bounce loops. If a DSN cannot be delivered (the sender’s mailbox is full or does not exist), the next MTA would generate a DSN of the DSN, which could bounce again, and so on. RFC 3464 (via RFC 5321 section 6.1) mandates that DSNs use a null envelope sender (MAIL FROM:<>), and receivers must not generate DSNs for messages that arrived with a null envelope sender. This breaks the loop at the second layer.
Are DSN messages ever generated at the MUA level like MDNs?
No. DSN is strictly an MTA-generated format for delivery status. Read-receipt-style feedback from mail clients uses the sibling MDN format per RFC 3798 / RFC 8098, which is different in generator (MUA not MTA), trigger (user action not delivery event), and payload (disposition types not action/status). They share only the outer multipart/report envelope from RFC 6522. See the side-by-side comparison table above.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
