DSN vs MDN: delivery receipts are not read receipts
A DSN reports what a mail transport system did with a message. An MDN reports a later disposition by a recipient's mail user agent, such as displayed or deleted. Calling both a delivery receipt hides an important boundary.
Updated July 15, 2026
The practical comparison
| Question | DSN | MDN |
|---|---|---|
| Full name | Delivery Status Notification | Message Disposition Notification |
| Generated by | Mail transfer/delivery system | Recipient's mail application |
| Typical events | failed, delayed, delivered, relayed | displayed, deleted, processed, dispatched |
| Human read proven? | No | No—display can be automatic and users can decline reports |
Why MDNs are weak read evidence
MDN requests are optional. Recipient software or policy may ignore them, ask the user, or send a disposition without proving comprehension. A displayed disposition means the client displayed the message, not that the person read or acted on it.
Why DSN delivery is also limited
A delivery result describes transport to the stated destination or relay. It does not reveal inbox versus spam placement or what happens after acceptance. For authentication and path evidence, inspect the received message's headers; for a delivery failure, inspect its DSN.
Which one should you use?
- Use DSN data to handle bounces, delays, invalid recipients, and delivery operations.
- Treat MDNs as optional recipient-client signals, not reliable engagement analytics.
- Use explicit product events or confirmations for business-critical acknowledgements instead of assuming email display equals consent or completion.