What is a delivery receipt vs. read receipt?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

A delivery receipt confirms that your email successfully reached the recipient's mail server. A read receipt asks the recipient to confirm they opened it. Same email, two different checkpoints.

Here's the catch: delivery receipts are automatic (the server sends them back without asking anyone), but read receipts require the recipient's mail client to cooperate. Most people disable them. So you can reliably know an email got there, but not if anyone actually read it.

Delivery receipts use DSN (Delivery Status Notification), a standard protocol built into email servers. When your email reaches the recipient's server, their server can send back a DSN saying "got it" or "rejected it". These are reliable because servers handle them automatically. You'll see DSNs when an email bounces (permanent failure) or gets temporarily delayed.

Read receipts use MDN (Message Disposition Notification), which requires the recipient's mail client (Gmail, Outlook, Apple Mail, etc.) to ask "This sender wants to know if you opened this. Send a read receipt?" Most clients let users refuse. Many default to refusing automatically. Some corporate environments disable read receipts entirely for privacy reasons.

If you're sending marketing emails through an ESP like Mailchimp or Brevo, you're not using read receipts anyway. You're tracking opens with a tiny invisible image (called a tracking pixel). When the recipient's client loads that image, the ESP counts it as an open. Still not perfect (Apple Mail pre-loads images, some clients block them), but more reliable than hoping someone clicks "yes" on a read receipt prompt.

For transactional email, delivery receipts are more useful. If you're sending password resets or order confirmations through Postmark or SendGrid, you want to know if the server accepted the message. Most transactional ESPs log delivery status automatically. Read receipts don't help here because even if someone opened it, they're not going to click "send read receipt" for a password reset.

Bottom line: delivery receipts tell you the server got it. Read receipts ask the recipient to tell you they opened it, but most won't. If you need real open tracking, use an ESP's built-in analytics, not read receipts.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Ask RME's AI for help with your setup

I read this on the Email Almanac about delivery receipts vs. read receipts: "Delivery receipts confirm server arrival automatically using DSN. Read receipts ask the recipient's mail client to send confirmation using MDN, but most users disable them. Marketing ESPs use tracking pixels instead. Transactional senders care more about delivery receipts to confirm the server accepted the message." Help me understand how this applies to MY specific situation. I need: 1. Whether delivery receipts or read receipts (or neither) matter for my use case 2. If I'm using an ESP, what tracking I actually have vs. what I think I have 3. How to interpret delivery status when troubleshooting 4. Whether tracking pixels work for my recipients (corporate environments, privacy tools) --- My details (fill in what applies): - Email platform/ESP: e.g. Mailchimp, SendGrid, Gmail, Outlook - Sending type: [marketing campaigns, transactional, one-to-one business email] - What I'm trying to confirm: [did it reach their server? did they open it? did they read it?] - Current challenge: [e.g. recipient claims they never got it, need proof of delivery, wondering why open rates are low] - Recipient environment: corporate email, personal Gmail, unknown

Edit the yellow boxes, then send to the AI of your choice.