What this RFC defined
RFC 3798 defined the Message Disposition Notification (MDN) format, the standardised read receipt mechanism for email. When a recipient’s mail client read, deleted, or processed a message with a Disposition-Notification-To: header, it could send an MDN back to the requesting address using the format RFC 3798 specified.
Where you would have seen it in practice
Read receipt requests in corporate email environments between 2004 and 2017 followed the MDN format defined by RFC 3798. The machine-readable message/disposition-notification MIME part it defined allowed automated systems to process receipt confirmations without parsing free-form text. Legal and compliance systems that track email receipt and reading used RFC 3798 MDNs as evidence of delivery.
How it connects to other RFCs
RFC 3798 was obsoleted by RFC 8098 in 2017. It built on RFC 6522 (multipart/report) and RFC 5322 (message format). RFC 8098 updated the syntax and improved interoperability guidance for MDNs without changing the fundamental notification mechanism, so existing deployments generating MDNs per RFC 3798 are compatible with RFC 8098 processing systems.
Current status
RFC 3798 was obsoleted by RFC 8098 in February 2017. New MDN implementations should reference RFC 8098. The format changes between the two were minor, so RFC 3798 MDNs remain processable by RFC 8098-compliant systems. RFC 8098 is the current read receipt standard.
Message Disposition Notifications
RFC 3798 defined Message Disposition Notifications (MDNs), commonly called “read receipts”, in May 2004. An MDN is a response indicating what happened to a message after delivery: displayed to the user, dispatched (forwarded), processed automatically, or deleted without display. Senders request an MDN by including a Disposition-Notification-To header pointing to the address where the receipt should be sent. The receiving mail client generates the MDN when the user takes the action (typically opening the message).
Why read receipts often do not work
MDN generation is entirely optional at the recipient side. Every major mail client (Gmail, Outlook.com, Apple Mail) either disables MDN by default, asks the user each time, or requires explicit configuration to enable. Users who value privacy generally decline to send MDNs. Enterprise environments sometimes enforce MDN generation via policy, but for consumer mail, read receipts are unreliable at best. If your workflow depends on knowing whether a message was read, MDN is not the mechanism to rely on; pixel tracking or in-app confirmations are more reliable.
Superseded by RFC 8098
RFC 3798 was obsoleted by RFC 8098 in February 2017. The changes were incremental: internationalization support, integration of errata, and clarification of the multipart/report structure that carries the MDN. The core semantics are unchanged; an implementation targeting RFC 3798 is still compatible with RFC 8098. New work should reference RFC 8098 as the current standard.
RFC 3798 (May 2004) defined the Message Disposition Notification (MDN) format, the machine-readable read receipt mechanism for email. Senders request an MDN via the Disposition-Notification-To header; recipient mail clients generate a multipart/report response when the user opens or otherwise processes the message. Obsoleted by RFC 8098 in 2017 (backward compatible; new work should target 8098). Not to be confused with RFC 3464 Delivery Status Notifications, which report envelope-level delivery events rather than user disposition.
RFC 3798 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Standardized read receipt format for email |
| Trigger | Sender adds Disposition-Notification-To header to outgoing message |
| Response format | multipart/report; report-type=disposition-notification per RFC 6522 |
| Generated by | Recipient Mail User Agent (MUA), not the server |
| Published | May 2004 (obsoleted by RFC 8098, February 2017) |
| Reliability | Low: modern clients default to ignoring or asking; consumer response rate under 5% |
| Legal weight | Weak: forgery is trivial, most jurisdictions do not accept MDN as sole receipt evidence |
| Modern successor | RFC 8098 (incremental revision, backward compatible) |
The Disposition-Notification-To header
This header is the sender-side trigger for the entire MDN mechanism. Placed in the message header block per RFC 5322, it names one or more addresses that should receive the MDN when the recipient mail client processes the message. Without this header, no MDN is expected or generated.
Syntax
| Form | Example | Notes |
|---|---|---|
| Bare address | Disposition-Notification-To: receipts@example.com | Minimal valid form |
| With display name | Disposition-Notification-To: "Delivery Team" <receipts@example.com> | Angle brackets required around address |
| Multiple addresses | Disposition-Notification-To: receipts@example.com, audit@example.com | Rare: most implementations use one address |
| IP literal | Disposition-Notification-To: user@[192.0.2.10] | Legal per RFC 5322 but rejected in practice |
Common mistakes
Disposition-Notification-To: Delivery Team receipts@example.com is a syntax error; the display name form requires <address> around the address. Parsers reject or ignore the header entirely.Client behavior when this header is present
| Client | Default behavior | User can change |
|---|---|---|
| Outlook desktop | Prompt: ask user each time | Yes: always send, never, or ask |
| Outlook.com web | Show notification, default no response | Limited |
| Thunderbird | Prompt by default | Yes: per-identity granular control |
| Apple Mail | Ignore header entirely | No built-in UI; third-party plugin only |
| Gmail (web, mobile, IMAP) | Ignore header entirely | No option exists |
| Yahoo Mail, iCloud, ProtonMail | Ignore header entirely | No option exists |
| Exchange with policy | Auto-respond per Group Policy | No: admin controlled |
Complete MDN header field reference
Beyond the sender-side trigger, MDN uses a family of headers on the response side. These appear inside the message/disposition-notification MIME part of the returned MDN, not in the original message.
| Header | Purpose | Format | Required? |
|---|---|---|---|
Reporting-UA | Identifies the mail client that generated the MDN | product-name; version | Optional |
Original-Recipient | Recipient address on the original envelope | rfc822; address | Optional |
Final-Recipient | Address that actually processed the disposition | rfc822; address | Required |
Original-Message-ID | References Message-ID of the original message (correlation key) | <id@domain> | Recommended |
Disposition | What happened to the message (the core payload) | action-mode/sending-mode; type/modifier | Required |
Disposition-Notification-Options | Sender request for specific MDN behaviors (rare) | parameter list | Optional (on original) |
MDN-Gateway | Identifies gateway if MDN relayed through non-SMTP system | smtp; hostname | Optional |
Disposition types
The Disposition header carries the core payload of the MDN. RFC 3798 section 3.2.6 defines six standard type values. Each describes what the recipient did with the message.
| Type | Meaning | Emitted when | Frequency in practice |
|---|---|---|---|
displayed | Message was shown to the user | User opened the message in their client | Most common MDN type |
dispatched | Forwarded to another destination (fax, print, voice) | Client bridged the message to another medium | Rare today |
processed | Handled automatically without display | Automated workflow consumed the message | Common in enterprise workflows |
deleted | Deleted without being displayed | User deleted before opening | Some clients refuse to send this |
denied | Recipient explicitly refused to send an MDN | User clicked “No” on the prompt | Common with prompt-by-default clients |
failed | MDN generation could not complete | Parser error or system failure | Very rare |
Modifiers
| Modifier | Position | Meaning |
|---|---|---|
manual-action | action-mode | User clicked the action explicitly |
automatic-action | action-mode | Client acted without user involvement |
MDN-sent-manually | sending-mode | User approved sending the MDN |
MDN-sent-automatically | sending-mode | Client sent the MDN without asking |
error | type-suffix | Disposition happened but with reported error |
warning | type-suffix | Disposition happened but with reported warning |
failure | type-suffix | Disposition attempt failed |
The message/disposition-notification MIME structure
MDN responses are formatted as multipart/report per RFC 6522 with three MIME parts in a defined order. The outer Content-Type parameter report-type=disposition-notification is what tracking systems use to distinguish MDN from sibling DSN reports.
Parsers must handle the multipart boundaries correctly, decode each part according to its Content-Transfer-Encoding, and extract the disposition-notification headers from part 2. The parsing logic mirrors what the DSN parsing guide covers for the sibling delivery-status format under RFC 3464; both use the same multipart/report MIME structure.
Client support matrix (2026)
MDN support varies dramatically across mail clients. This asymmetry is the primary reason MDN cannot be relied on for any operational use case. Response rate in a mixed consumer audience is typically under 5%.
| Client | Version | Request MDN | Generate MDN | Default | User setting |
|---|---|---|---|---|---|
| Outlook Desktop | 2016+ | Yes | Yes | Prompt each time | Full control |
| Outlook.com Web | Current | Yes | Yes | Ignore | Limited |
| Outlook Mobile | Current | No | No | Ignore | None |
| Thunderbird | 60+ | Yes | Yes | Prompt each time | Full per-identity control |
| Apple Mail macOS | Current | No | No | Ignore | Third-party plugin only |
| Apple Mail iOS | Current | No | No | Ignore | None |
| Gmail (all surfaces) | Current | No | No | Ignore | None (Workspace admin only) |
| Yahoo Mail | Current | No | No | Ignore | None |
| iCloud Mail | Current | No | No | Ignore | None |
| ProtonMail | Current | No | No | Ignore | None (privacy-first) |
| Exchange with policy | 2016+ | Yes | Yes | Auto-respond | Admin controlled |
| Zimbra | Current | Yes | Yes | Prompt | Per-account |
MDN vs DSN: side-by-side
MDN and DSN are sibling mechanisms that operators frequently confuse. Both use the multipart/report format from RFC 6522, both return machine-parseable status information to the sender, and both surface in bounce-processing pipelines. But they describe entirely different events at different points in the mail flow.
| Aspect | DSN (RFC 3464) | MDN (RFC 3798 / 8098) |
|---|---|---|
| What it reports | SMTP delivery outcome | Recipient user interaction |
| Generated by | Mail Transfer Agent (MTA) | Mail User Agent (MUA) |
| When generated | During SMTP conversation | After delivery, on user action |
| Scope | Envelope-level | Message-level (per recipient action) |
| Report-type parameter | delivery-status | disposition-notification |
| Status format | Enhanced status codes (RFC 3463) | Disposition type values |
| Reliability | Deterministic (server-generated) | Discretionary (user-dependent) |
| Typical use | Bounce classification, suppression lists | Read tracking (rarely reliable) |
| Response rate | Near 100% on hard bounces | Under 5% consumer, 60-80% enterprise |
Privacy and abuse considerations
The mechanism reveals recipient behavior to the sender: whether they opened a message, when they opened it, whether they deleted without reading, whether they forwarded it. This is unwanted disclosure from the recipient perspective. Documented abuse patterns include:
Modern client design responds to these concerns. This pattern of “default deny” is why MDN response rates crashed after 2015 as clients updated their defaults. The mechanism still works between cooperating parties (both sender and recipient explicitly opt in), but does not work for surveillance-oriented use cases.
Programmatic MDN generation
Generating a compliant MDN programmatically requires constructing the multipart/report MIME message with the correct headers, part order, and disposition-notification block.
Common libraries handle multipart/report reasonably well. Python email module supports it natively via MIMEMultipart('report'). Node.js nodemailer requires manual construction. PHP PHPMailer supports it through custom parts. In every case, correctness matters: the report-type parameter must be exactly disposition-notification, the second part Content-Type must be message/disposition-notification, and the Disposition header must follow the exact format from RFC 3798 section 3.2.6.
Legal and compliance context
| Compliance need | Weak (informational) | Strong (evidentiary) |
|---|---|---|
| Prove message was displayed | MDN with disposition=displayed | Certified email service with notarized timestamp |
| Prove message was delivered | 250 OK at SMTP layer | ISP-level delivery attestation, journaled audit log |
| Prove message was forwarded | MDN with disposition=dispatched | Journaling with cryptographic signature |
| Prove message was refused | MDN with disposition=denied | Signed refusal receipt from certified service |
| Regulatory notice delivery | Not sufficient alone | Registered Email, De-Mail (DE), PEC (IT), certified mail |
| Legal service of process | Not sufficient alone | Service by registered mail per local rules |
Combined with server-side Received header analysis and authentication verdicts, MDN can add a supplementary data point in compliance workflows. Practitioners should treat it as: “the recipient client asserted this happened at this time.” Informational, never authoritative.
Migration from RFC 3798 to RFC 8098
RFC 8098 replaced RFC 3798 in February 2017. The revision was incremental rather than fundamental. The core MDN semantics (disposition types, header fields, MIME structure) are unchanged.
| Aspect | RFC 3798 (2004) | RFC 8098 (2017) | Impact if you rely on 3798 |
|---|---|---|---|
| Disposition types | 6 types (displayed, dispatched, processed, deleted, denied, failed) | Identical | None |
| Modifiers | Defined set (manual-action, MDN-sent-manually, etc.) | Identical | None |
| Header syntax | Disposition-Notification-To per RFC 2822 | Same, references RFC 5322 | None |
| MIME structure | multipart/report with 3 parts | Same, clarifications on edge cases | Minor: some ambiguities in 3798 resolved |
| Internationalized addresses | Not supported | Supported via RFC 5337 / RFC 6531 | Update parsers if you handle non-ASCII addresses |
| Errata integration | Errata reported separately | Integrated into main text | None (informational only) |
| Character encoding | Limited guidance | Explicit UTF-8 support | Update parsers for UTF-8 disposition text |
Related standards and further reading
- RFC 8098: The current MDN standard (replaces 3798)
- RFC 6522: The multipart/report container format used by MDN and DSN
- RFC 3464: DSN, the sibling delivery-status mechanism
- RFC 5322: Internet Message Format (where Disposition-Notification-To lives)
- RFC 4021: Registration of mail and MIME header fields (formalizes MDN headers)
- RFC 2045 through 2049: MIME, the foundation for multipart/report
- RFC 5321: SMTP, which transports MDN messages
- RFC 6152: SMTP 8-bit MIME extension (needed for internationalized MDN)
- RFC 5337: Internationalized DSN and Disposition Notifications
- RFC 6530: Overview of internationalized email
- RFC 6531: SMTP extension for internationalized email
- RFC 5965: Feedback Reports (ARF), a third report family for spam complaints
- RFC 5598: Internet Mail Architecture (frames where MUA vs MTA responsibilities lie)
- DSN Parsing Guide: reading RFC 3464 bounce reports (parses same multipart/report format)
- Feedback Loops (FBL) and ARF Guide: RFC 5965 complaint reports
- Authentication-Results Header: parsing SPF, DKIM, DMARC verdicts
- Message-ID Header: the correlation identifier MDN references via Original-Message-ID
- Received Headers and Email Trace Chain: server-side receipt evidence
- Content-Type and MIME Structure: multipart handling
- Hard Bounce vs Soft Bounce: bounce classification patterns
- Suppression Lists Best Practices: what to do with bounce/complaint signals
Frequently asked questions
What is the Disposition-Notification-To header used for?
It is the sender-side header that requests a Message Disposition Notification (read receipt) from the recipient mail client. Placed in the message header block per RFC 5322, its value is one or more addresses that should receive the MDN when the recipient opens or otherwise processes the message. Without this header, no MDN is expected. With it, the recipient client evaluates policy and user preference to decide whether to send a response.
Why do most Gmail messages never generate a read receipt?
Gmail does not implement MDN. It ignores the Disposition-Notification-To header entirely and offers no user setting to opt in. This applies to Gmail web, Gmail mobile apps, and Gmail accessed via IMAP. Google Workspace administrators can enable a proprietary read-receipt feature within their tenant, but that is Google-specific and not RFC 3798 compliant. For any consumer Gmail recipient, MDN is effectively unimplemented.
Is an MDN legal proof that the recipient read my message?
Generally no. Most jurisdictions do not accept MDN as authoritative evidence because the MDN is asserted by the recipient client, is entirely optional at the recipient side, and can be forged trivially by anyone with SMTP access. Courts have consistently treated MDN as weak evidence at best. For legal service or regulatory notice, use certified email services (Registered Email, De-Mail in Germany, PEC in Italy) or physical registered mail per local rules.
How is MDN different from DSN?
DSN (defined by RFC 3464) reports what happened at the SMTP delivery layer: whether the receiving server accepted, deferred, or refused the message. It is generated by mail transfer agents during SMTP conversation processing. MDN (RFC 3798, now RFC 8098) reports what happened at the mail user agent layer after delivery: whether the recipient displayed, deleted, or otherwise processed the message. Both use the same multipart/report container from RFC 6522, but they answer different questions. See the side-by-side comparison table above.
Should I update my code from RFC 3798 to RFC 8098?
For sender-side code (generating the Disposition-Notification-To header on outbound messages), no. The header syntax is identical between the two RFCs. For receiver-side parsing, yes if you handle internationalized addresses (RFC 8098 adds proper support via RFC 5337). For generator-side (implementing MDN generation 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 8098 parsers.
What alternative mechanisms exist for tracking whether an email was read?
Modern engagement tracking uses invisible tracking pixels (1×1 images loaded from a sender-controlled server) or click tracking on links (redirect through sender-controlled URLs). Both work independently of MDN and do not require recipient client cooperation. However, both are increasingly blocked by privacy features: Apple Mail Privacy Protection pre-loads all images from Apple proxies, breaking pixel accuracy; Gmail and Outlook filter or defer image loading for many senders; browser tracking prevention breaks click tracking in some environments. The reality of 2026 is that reliable read tracking at the individual recipient level does not exist for consumer email. Aggregate engagement metrics remain useful; per-recipient certainty does not.
Can a spammer use MDN to attack me?
Yes, this is a documented denial-of-service pattern. A malicious sender spoofs the Disposition-Notification-To header pointing at a victim address, sends volume to MDN-generating recipients, and each recipient generates an MDN back to the victim. The victim sees an unsolicited flood of MDN responses from legitimate mail systems. Modern MDN implementations mitigate this by refusing to send MDN when the Disposition-Notification-To address differs from the envelope sender (Return-Path), which breaks the spoofing vector. Verifying sender authentication before honoring MDN requests is the current best practice.
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.
