What this RFC defines
RFC 8098 defines the MDN (Message Disposition Notification) format, the email equivalent of a read receipt. When a recipient’s mail client reads, deletes, or processes a message and MDN is enabled, it sends a structured notification back to the address specified in the Disposition-Notification-To: header of the original message.
Where you see it in practice
The read receipt request you can add to outgoing messages in Outlook or Thunderbird uses the MDN mechanism defined by this RFC. The Disposition-Notification-To: header in your sent message requests the notification. Many recipients’ mail clients suppress MDNs by default or ask the user before sending them, so read receipts are unreliable in practice. Enterprise environments sometimes enforce MDN responses for internal mail tracking.
How it connects to other RFCs
RFC 8098 obsoletes RFC 3798. It uses the multipart/report MIME type defined in RFC 6522 and the message format defined in RFC 5322. It is structurally similar to DSNs (RFC 3464) but covers user-triggered disposition events (read, deleted, processed) rather than automated delivery failures.
Current status
RFC 8098 is the current MDN standard, published February 2017. Read receipts remain a niche feature in consumer email but are used in enterprise and legal contexts where message receipt confirmation matters. RFC 8098 supersedes RFC 3798 with updated syntax and improved interoperability guidance.
The current MDN standard
RFC 8098 is the current standard for Message Disposition Notifications, published in February 2017 and obsoleting RFC 3798. The wire format is a multipart/report with content subtype message/disposition-notification, containing fields like Reporting-UA (the user agent that generated the MDN), Final-Recipient, Original-Message-ID, and Disposition (the action taken: displayed, dispatched, processed, deleted, denied, failed).
Disposition types explained
The Disposition field is structured as action-mode/sending-mode; disposition-type/disposition-modifier. Action-mode is manual (user explicitly acted), automatic (mail rules acted), or automatic-action (system processed). Sending-mode is MDN-sent-manually or MDN-sent-automatically. Disposition-type is displayed, dispatched, processed, deleted, denied, or failed. For example, “manual-action/MDN-sent-manually; displayed” means the user manually opened the message and manually authorized sending the receipt. This granularity supports sophisticated tracking use cases but is rarely fully populated by real clients.
Where MDN is used successfully
MDN sees the most reliable deployment in enterprise workflows where mail clients are centrally managed and policy compels MDN generation. Some legal and compliance workflows require MDN as evidence of delivery and review, though the recipient can still refuse the receipt. In consumer contexts, MDN is best treated as a hint rather than a guarantee. Applications that need reliable delivery confirmation should use DSN (RFC 3464) for delivery, and out-of-band tracking (web pixels, app callbacks) for read status.
RFC 8098 (February 2017) is the current Message Disposition Notification (MDN) standard, the read-receipt format for email. Obsoletes RFC 3798. The changes are incremental: internationalization support via RFC 5337, integrated errata, UTF-8 in disposition text. Core semantics (Disposition-Notification-To trigger header, multipart/report container per RFC 6522, 6 disposition types) are unchanged. Backward compatible with RFC 3798. Sibling of DSN (RFC 3464) and ARF (RFC 5965).
RFC 8098 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Machine-readable read receipt format for email |
| Trigger | Sender’s Disposition-Notification-To header per RFC 5322 |
| Generated by | Recipient Mail User Agent (MUA), not the server |
| Container | multipart/report; report-type=disposition-notification |
| Disposition types | displayed, dispatched, processed, deleted, denied, failed |
| What changed from 3798 | Internationalization, UTF-8 support, errata integration, MIME edge case clarifications |
| Published | February 2017 (obsoletes RFC 3798) |
| Reliability | Under 5% consumer response rate; effectively unimplemented at Gmail, Yahoo, Apple Mail, iCloud, ProtonMail |
Concrete changes from RFC 3798 to RFC 8098
| Aspect | RFC 3798 (2004) | RFC 8098 (2017) | Impact if code targets 3798 |
|---|---|---|---|
| Disposition types | 6 types (displayed, dispatched, processed, deleted, denied, failed) | Identical | None |
| Modifiers | Defined set (manual-action, MDN-sent-manually, etc.) | Identical | None |
| Disposition-Notification-To syntax | Per RFC 2822 | Per RFC 5322 | None (spec update only) |
| Internationalized addresses | Not supported | Supported via RFC 5337 integration | Update parsers if you handle non-ASCII addresses |
| Character encoding | Limited guidance | Explicit UTF-8 support in disposition text | Update parsers to handle UTF-8 in Disposition field |
| Errata integration | Errata reported separately | Integrated into main text | None (informational only) |
| MIME structure clarifications | Some ambiguities | Explicit clarification of edge cases | None for correctly implemented parsers |
The message/disposition-notification MIME structure
MDN header field reference
| Header | Purpose | Required? |
|---|---|---|
Reporting-UA | Mail client that generated the MDN | Optional |
Original-Recipient | Recipient address on original envelope | Optional |
Final-Recipient | Address that actually processed disposition | Required |
Original-Message-ID | References Message-ID of original | Recommended |
Disposition | Core payload: what happened to the message | Required |
MDN-Gateway | Identifies gateway if MDN relayed through non-SMTP | Optional |
Disposition types and modifiers
| Type | Meaning | Emitted when |
|---|---|---|
displayed | Message shown to user | User opened the message |
dispatched | Forwarded to another destination (fax, print, voice) | Client bridged to another medium (rare today) |
processed | Handled automatically without display | Automated workflow consumed the message |
deleted | Deleted without being displayed | User deleted before opening (many clients refuse) |
denied | Recipient explicitly refused to send MDN | User clicked “No” on prompt |
failed | MDN generation could not complete | Parser error or system failure |
Migration and interoperability
Related standards and further reading
- RFC 3798: Legacy MDN specification (obsoleted by RFC 8098)
- RFC 6522: multipart/report container
- RFC 5337: Internationalized DSN and MDN
- RFC 3464: DSN (sibling format, delivery outcomes)
- RFC 5965: ARF (abuse reports, third report family)
- RFC 5322: Internet Message Format (Disposition-Notification-To header per section)
- RFC 3798 Guide: predecessor with client support matrix
- DSN Parsing Guide: parsing the sibling delivery-status format
- Feedback Loops and ARF Guide: third report family
- Message-ID Header: correlation identifier MDN references
Frequently asked questions
Should I update my code from RFC 3798 to RFC 8098?
For sender-side code (generating Disposition-Notification-To on outbound), no. The header syntax is identical. For receiver-side parsing, update if you handle internationalized addresses (RFC 8098 adds proper support). For generator-side (implementing MDN in a mail client or middleware), reference RFC 8098 as the current standard, though the practical differences are small and RFC 3798 output remains fully compatible with RFC 8098 parsers.
What actually changed between RFC 3798 and RFC 8098?
Four things: internationalized email address support (via RFC 5337 integration), explicit UTF-8 support in disposition text, integration of RFC 3798 errata into the main text, and clarification of some MIME structure edge cases that were ambiguous in RFC 3798. No changes to disposition types, modifiers, header field names, or the trigger mechanism. The core wire format is unchanged.
Why is MDN still unreliable even after RFC 8098?
RFC 8098 modernized the specification but did not change client deployment. Gmail, Yahoo, iCloud, ProtonMail, and Apple Mail continue to ignore Disposition-Notification-To. Only Outlook, Thunderbird, and enterprise Exchange with policy actually respond. Consumer response rate remains under 5%. The reliability problem is architectural (MDN is optional at recipient side) not specification-level (which RFC).
How does RFC 8098 handle non-ASCII addresses?
RFC 8098 integrates RFC 5337, which extends DSN and MDN for internationalized email addresses per SMTPUTF8. Final-Recipient and Original-Recipient can carry UTF-8 addresses when the surrounding SMTP transport supports SMTPUTF8. Legacy RFC 3798 parsers would encounter these as opaque bytes; RFC 8098 parsers handle them correctly. For interoperability with legacy systems, downgrade paths per RFC 6533 apply.
Is there a successor to RFC 8098 planned?
Not currently. RFC 8098 has been stable since 2017. The MDN mechanism has declining industry relevance (consumer mail clients trend toward ignoring it entirely, privacy-first products reject it outright), so no active IETF work targets a replacement. Modern engagement tracking uses invisible pixels and click tracking, which are separate mechanisms not governed by MDN standards.
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.
