MDN: what RFC 8098 actually defines

A sender sometimes wants more than proof that a mailbox accepted a message. They want confirmation a human actually saw it, or that the recipient's client processed it in some specific way. Delivery and disposition are two different questions, and for years only the first had a standard answer.

"Read receipts" existed in mail clients long before any RFC defined them. Different vendors implemented the idea differently, sometimes triggering the notification silently without the recipient's knowledge. That inconsistency created an interoperability problem, since no two clients agreed on the header or the format, and a privacy problem, since a message could report back on when and whether it was read without the recipient ever choosing that.

What MDN defines

RFC 8098 defines Message Disposition Notification (MDN): the multipart/report subtype message/disposition-notification. It obsoletes RFC 3798, which itself obsoleted the original RFC 2298.

A Disposition-Notification-To header on the original message triggers an MDN. That header names the address that receives a resulting notification, if one is ever generated.

How MDN works

A sender adds a Disposition-Notification-To header to the message, naming an address to receive the notification. From there:

1. The message reaches the recipient's mail client.
2. If that client supports MDN, and the recipient or a client policy allows it, the client watches for a defined disposition event: the message being displayed, deleted, dispatched, or processed.
3. When that event happens, the client generates an MDN report describing it and sends it to the address named in Disposition-Notification-To.

Every step past the first is optional on the recipient's side. Sending an MDN is always the recipient client's choice. Nothing in RFC 8098 forces a client, or a human, to generate one just because the original message requested it.

Anatomy of an MDN

Two sets of fields matter here: what the original message carries, and what the resulting report carries.

Header fields on the original message:

Fields inside the MDN report itself:

Disposition is the field that actually answers the question. It's composed of three parts: an action-mode (manual-action or automatic-action, whether a human or the client itself triggered the notification), a sending-mode (MDN-sent-manually or MDN-sent-automatically), and a type (displayed, deleted, dispatched, or processed). A full value reads like manual-action/MDN-sent-manually; displayed.

Worked example

An original message requesting a receipt:

From: sender@example.com
To: recipient@example.net
Subject: Contract for review
Disposition-Notification-To: sender@example.com

If the recipient's client supports MDN and the recipient opens the message, the resulting report includes:

Content-Type: message/disposition-notification

Original-Recipient: rfc822;recipient@example.net
Final-Recipient: rfc822;recipient@example.net
Original-Message-ID: <a1b2c3@example.com>
Disposition: manual-action/MDN-sent-manually; displayed

Disposition: manual-action/MDN-sent-manually; displayed reports that a human opened the message, and the client sent the notification as a direct, immediate result rather than through an automated background process.

Where MDN falls short

Most modern webmail doesn't generate MDNs by default. Gmail is among them: a message can carry Disposition-Notification-To and Gmail simply won't act on it unless the user manually chooses to send a receipt.

That's not a violation of the standard. RFC 8098 deliberately leaves a recipient's mail client free to ignore the request entirely. An MDN can reveal exactly when and whether a message was read. That's the same privacy and tracking concern that kept receipts inconsistent before the RFC existed, and it's why support stayed uneven afterward too.

An MDN also only confirms disposition after successful delivery. It says nothing about delivery itself, whether the message reached a mailbox at all. That's a separate question, and a separate standard's job.

Check it yourself

Send a message with a Disposition-Notification-To header to a mail client known to support MDN. Thunderbird and Outlook both do. Watch for the receipt prompt the client shows the recipient before it generates and sends the report.

Where it fits

MDN and DSN answer different questions about the same original message. DSN confirms delivery outcome, whether a mailbox accepted the message. MDN confirms disposition, what happened to it after a human's mail client received it. They're two separate notification types, and a message can request either, both, or neither.

An MDN generated automatically, rather than triggered by a manual user action, should itself carry Auto-Submitted: auto-notified, as defined in Auto-Submitted. That keeps an automated notification from looking like a normal reply and triggering a reply loop with another automated system on the other end.

For the wider set of standards MDN sits inside, see the reference hub.

FAQ

Does every mail client support MDN?

No. Support varies widely, and several major webmail providers, Gmail included, don't generate MDNs by default even when a message requests one.

Can a sender force a read receipt?

No. Requesting one via Disposition-Notification-To is only a request. The recipient's mail client, or the recipient themselves, decides whether to honor it.

What's the difference between a DSN and an MDN?

A DSN confirms delivery to a mailbox, generated automatically by an MTA. An MDN confirms disposition, like being displayed, generated only if the recipient's mail client and the recipient allow it.

Why did MDN adoption stay low?

Privacy concerns. An MDN can reveal exactly when and whether a message was read, which is sensitive enough that many mail clients disable the feature by default.

RFC reference

RFCs covered: RFC 8098. Superseded / updated by: None. RFC 8098 itself obsoletes RFC 3798, which obsoleted RFC 2298.