A legal team needed proof that a contract termination notice had been received. They sent it by email and requested a read receipt. The recipient's email client prompted them to send a receipt—and they declined. The sender had no proof of reading, and the legal question of whether notice was properly given became complicated.
Email delivery and read notifications seem like they should be straightforward, but they're not. The standards exist, but implementation is inconsistent, and recipients have significant control over what information they share. Understanding DSN and MDN helps you know what you can and can't reliably track.
DSN: Delivery Status Notification
DSN is a standard (RFC 3461) for reporting whether an email was successfully delivered to the recipient's mail server.
When you send an email, you can request a DSN. If the receiving server supports it, you'll get a notification when the email is delivered successfully, when it fails permanently (bounces), or when it's delayed.
DSN operates at the server level. It tells you whether the email reached the recipient's mail server, not whether it reached their inbox or whether they read it. A successful DSN means the server accepted the message—it might still end up in spam or be filtered.
Bounce messages are a form of DSN. When an email can't be delivered, the receiving server (or an intermediate server) generates a DSN explaining why. These are the "delivery failed" messages you receive when an address is invalid or a server is unreachable.
DSN is relatively reliable because it's handled by servers, not users. Servers either support it or don't, but they don't actively refuse to send notifications the way users can refuse read receipts.
MDN: Message Disposition Notification
MDN is a standard (RFC 8098) for reporting what happened to an email after delivery—specifically, whether the recipient read it.
When you request an MDN (commonly called a "read receipt"), you're asking the recipient's email client to notify you when they open the message. If they agree, you get a notification confirming the message was displayed.
The critical difference from DSN: MDN requires recipient cooperation. Email clients typically prompt users before sending read receipts, and users can decline. Many people always decline. Some email clients don't support MDN at all. Corporate policies often disable read receipts entirely.
This makes MDN unreliable for tracking. You might request receipts for 1,000 emails and get 50 back. That doesn't mean only 50 were read—it means only 50 recipients agreed to send receipts. The other 950 might have read the email and declined the receipt, or might not have read it at all.
How to request notifications
Requesting DSN and MDN involves specific email headers.
For DSN, you set options during the SMTP transaction using the NOTIFY parameter. You can request notification on success, failure, delay, or never. The specifics depend on your email client or sending system.
For MDN, you include a Disposition-Notification-To header in your email specifying where to send the receipt. When the recipient opens the email, their client checks for this header and (if configured to do so) sends a notification to that address.
Most email clients have user-facing options for requesting read receipts. In Outlook, it's in the message options. In Gmail, it's available for Workspace accounts. The client handles the technical details.
For programmatic sending, you need to set the appropriate headers yourself. Your email library or service should support this, though the exact method varies.
Why MDN is problematic
Several factors make read receipts unreliable and sometimes counterproductive.
User control means low response rates. Most email clients ask before sending receipts, and many users reflexively decline. You can't force someone to confirm they read your email.
Privacy concerns drive rejection. Read receipts reveal information—that the recipient exists, that they read the email, when they read it. Privacy-conscious users and organizations disable receipts entirely.
Spam and phishing exploit receipts. Requesting a read receipt confirms to spammers that an address is valid and monitored. Many security-conscious users never send receipts for this reason.
Professional norms vary. In some contexts, requesting read receipts is seen as mistrustful or micromanaging. The request itself can damage relationships.
Technical inconsistency means receipts don't work uniformly. Different email clients handle MDN differently. Some don't support it. Some support it but default to declining. Some send receipts automatically. You can't rely on consistent behavior.
When DSN and MDN are useful
Despite limitations, these notifications have legitimate uses.
DSN for critical transactional email helps confirm delivery. If you're sending password resets or important notifications, DSN confirmation that the server accepted the message provides some assurance.
DSN for bounce management is essential. Bounce notifications (a type of DSN) tell you which addresses are invalid so you can remove them from your list. This is standard email hygiene.
MDN for specific high-stakes communications might be appropriate. Legal notices, contract documents, or other communications where proof of receipt matters might warrant read receipt requests—with the understanding that you won't always get them.
MDN for internal communications in controlled environments can work. If your organization configures email clients to send receipts automatically, internal read receipts become reliable. But this requires IT policy enforcement.
Alternatives to MDN
Given MDN's unreliability, other approaches often work better for tracking engagement.
Pixel tracking (open tracking) doesn't require recipient cooperation. An invisible image in the email loads when the email is opened, notifying your server. This has its own limitations (image blocking, privacy features) but doesn't depend on user consent for each email.
Click tracking confirms engagement more reliably than open tracking. If someone clicks a link in your email, you know they engaged with it. This is stronger evidence than a read receipt.
Response tracking works for emails that request replies. If someone replies, they definitely read the email. For communications where response is expected, this is natural confirmation.
Delivery confirmation services for legal purposes provide certified delivery with proof. These are specialized services for situations where legal proof of delivery is required—not standard email infrastructure.
DSN and MDN in practice
For most email programs, here's the practical guidance.
Use DSN for bounce handling. Ensure your email system processes bounce notifications to maintain list hygiene. This is standard practice and doesn't require special configuration in most cases.
Don't rely on MDN for engagement tracking. Read receipts are too unreliable. Use pixel tracking and click tracking instead, understanding their limitations.
Request MDN selectively if at all. For specific high-importance messages where you want to know if the recipient read it, requesting a receipt is reasonable. But don't expect responses, and don't use it routinely.
Understand that neither proves reading. DSN proves server acceptance, not inbox delivery. MDN proves the email was displayed, not that it was actually read or understood. Neither provides the certainty that registered mail or in-person delivery provides.
Frequently asked questions
Can I force someone to send a read receipt?
No. MDN requires recipient cooperation. Their email client asks permission, and they can decline. There's no way to force a receipt, and attempting to circumvent this would be a privacy violation.
Why don't I get bounce notifications for all failed emails?
Not all servers send DSN. Some silently discard undeliverable email. Some send bounces to addresses that don't reach you. Bounce handling is imperfect, which is why list hygiene requires multiple signals.
Are read receipts the same as open tracking?
No. Read receipts (MDN) require recipient consent and are sent explicitly. Open tracking uses invisible images that load without explicit consent. They measure similar things but work differently and have different reliability.
Should I request read receipts for marketing emails?
Generally no. It looks unprofessional, won't generate useful data (most recipients will decline), and might trigger spam filters. Use standard open and click tracking instead.