Email Read Receipts: What MDNs Prove and What They Don’t

An email read receipt can show that a mail user agent reported a disposition such as displayed. It does not prove that the intended person read, understood, or even personally opened the message. The request is optional, the recipient can decline it, and the returned receipt can be forged like ordinary email.

The standards name this receipt a Message Disposition Notification, or MDN. It sits after delivery in the message lifecycle. That makes it different from an SMTP acceptance reply, a delivery status notification, and an image-tracking event.

Start with the machine-readable receipt

A sender requests an MDN with one header. A useful Message-ID gives the later receipt something to correlate with:

Hypothetical original message

Message-ID: <invoice-7842@sender.example>
Disposition-Notification-To: receipts@sender.example

RFC 8098 is precise about this header: it is a request. The receiving user agent is free to ignore it, and the recommended default is not to send a receipt without the user's consent.

If the recipient's client does return an MDN, the message uses multipart/report with a machine-readable message/disposition-notification part. A minimal part can look like this:

Hypothetical returned MDN

Content-Type: message/disposition-notification

Reporting-UA: mail.reader.example; ExampleMail 4.2
Final-Recipient: rfc822; recipient@example.net
Original-Message-ID: <invoice-7842@sender.example>
Disposition: manual-action/MDN-sent-manually; displayed

Read the last line from right to left.

displayed means the client displayed the message to someone reading that mailbox. The standard explicitly says this does not guarantee the content was read or understood.

MDN-sent-manually says the user explicitly allowed this particular receipt to be sent. Its alternative, MDN-sent-automatically, means a previously configured client rule sent it.

manual-action describes how the disposition happened. It can still appear when a user previously configured the client to respond automatically to valid requests. That is why each token matters. Treating the whole line as a Boolean read=true throws away the evidence you actually received.

What other MDN dispositions mean

RFC 8098 defines four disposition types:

• displayed: a client displayed the message, without proving it was read or understood.
• dispatched: the message was forwarded, printed, faxed, or otherwise sent somewhere, possibly without being displayed first.
• processed: a rule or server processed it. A human may never see it.
• deleted: the message was deleted. The recipient may or may not have seen it.

The strongest fair objection is: “But if I received a manually sent displayed receipt, surely that proves the person read the message.” It is stronger evidence than a silent inbox, but it still reports a client-side disposition. It does not identify who was at the screen, measure attention, prove comprehension, or prevent a forged receipt.

The RFC's security section is unusually direct: MDNs can be forged as easily as ordinary internet email, and they do not provide non-repudiation or proof of delivery. Authenticate and correlate a returned message, but do not turn the format itself into legal proof or an identity guarantee.

Keep delivery, display, and action on separate rungs

I would put these events on an evidence ladder because they come from different systems and answer different questions.

A delivery status notification is not a read receipt. The SMTP DSN extension lets a sender request reports for SUCCESS, FAILURE, or DELAY, and RFC 3464 defines the machine-readable delivery-status format. A DSN comes from the delivery path. An MDN comes later from the recipient side of the mailbox.

An image event is different again. The tracking-pixel guide explains why a fetch can come from a person, privacy relay, cache, or scanner. Combining weak signals does not magically produce certainty. Preserve the source and meaning of each event.

How should an application store receipt evidence?

Store an MDN as an append-only event linked to the original message. I would keep at least:

• the raw receipt or a durable reference to it;
• the original Message-ID and the receipt's Original-Message-ID;
• the final recipient reported by the MDN;
• the action mode, sending mode, disposition type, and any modifier as separate fields;
• the receipt's own authentication and transport evidence;
• the time your system received it, without replacing the original send or delivery timestamps.

Key the workflow with an internal send ID and use Message-ID as one correlation field. A Message-ID is sender-supplied and can be missing, malformed, or duplicated. The Message-ID guide covers that collision boundary.

Keep the contact state at mdn_received with the original disposition fields beside it instead of flattening the event into read. That keeps the observation honest and lets later application events carry more weight.

When is requesting a read receipt reasonable?

Request one when the recipient expects the workflow and the receipt is a convenience, not a hidden surveillance mechanism or a required proof. Closed business environments can define their own policy for automatic receipts, but the public internet does not give the sender control over the recipient's client.

A missing MDN is not a failure. The client may not support the mechanism, the user may refuse, a privacy policy may suppress it, or the receipt may be lost. Silence is not evidence that the message was unread.

Also keep MDNs out of loops. RFC 8098 forbids requesting an MDN for an MDN and limits a user agent to one MDN per recipient for a particular message. A forged request can otherwise become a privacy leak or an amplification path.

Email verification belongs before this entire sequence. It can evaluate address, domain, routing, risk, and mailbox evidence before a send, but it does not prove inbox ownership or later reading. The validation, verification, and confirmation guide separates those states, while the verified-address bounce guide shows why later delivery evidence must remain a separate clock.

A useful read-receipt system keeps the same discipline: store the event that occurred, name the system that observed it, and stop before the claim becomes stronger than the evidence.