KoltrixRead receipts and delivery receipts: what they prove and what not
Delivery receipts, read receipts and open pixels all try to answer 'did they get it?' Here is what each really tells you, when it fails and what to use instead.
On this page(10 sections)
You send an important email and want proof that it arrived, or proof that it was read. Email offers several features that sound like proof. They are called delivery receipts, read receipts, return receipts and open tracking, and people often mix them up.
None of them is a guarantee. Each answers a narrower question than it appears to, and each fails in ordinary, predictable ways. This guide explains what each one really tells you, why the answers are weaker than they look, and what to rely on when you need evidence.
Four different questions
"Did they get it?" is really four questions:
- Did the receiving server accept the message? This is about transport.
- Did the message reach the mailbox? This is about placement: inbox, spam folder or somewhere else.
- Did the person open it? This is about attention.
- Did the person understand it and act? This is about the outcome you care about.
Email has tools for the first three, with decreasing reliability. For the fourth, you need a reply or an action in your product.
Delivery receipts
A delivery receipt tries to tell the sender that the message was delivered. There are two things people mean by this.
The server's acceptance
When your system sends a message by SMTP, the receiving server answers with a status. A 250 means it accepted the message for delivery. This is the strongest transport signal you get, and it is immediate. It means the receiving server took responsibility for the message. It does not say what that server did next. It may have placed the message in the inbox, put it in spam, held it for scanning or silently dropped it.
If you send through an email API, you also get your own events, such as "accepted", "delivered" and "bounced". What those words mean is defined by the provider. In most systems, "delivered" means the remote server accepted the message, not that the person saw it. What happens after a 202 response walks through the stages for a send.
Delivery status notifications
SMTP also has an optional extension, delivery status notifications (DSNs), where the sender asks the receiving system to send back a report on success, failure or delay. In practice:
- Failure reports are common and useful. A bounce is a DSN. Hard vs soft bounces explains how to read them, and SMTP enhanced status codes explains the codes.
- Success reports are rarely honored. Many servers ignore the request, and some strip it for privacy. Do not build a process that depends on receiving one.
So the absence of a success DSN means nothing. The presence of a failure one means a lot.
Read receipts
A read receipt is a request, built into the message, that asks the recipient's mail client to notify you when the message is opened. Technically it is a header (Disposition-Notification-To) that requests a message disposition notification.
Here is the catch: it is only a request. The recipient's client decides what to do.
- Many clients ignore the request entirely.
- Some ask the recipient "The sender asked for a read receipt. Send one?" and many people say no.
- Some clients can be set to send them automatically, but that is a personal setting, and many organizations turn it off for privacy reasons.
- A receipt means the message was displayed or marked as read in that client, not that the person read it. A preview pane or an accidental click counts the same.
A read receipt that arrives is a modest piece of evidence. A missing one proves nothing. Requesting receipts on ordinary mail also looks demanding to many recipients, and people tend to react badly to it, so save it for rare cases.
Open tracking
Marketing and transactional tools do not usually use read receipts. They use a tracking pixel: a tiny image in the HTML whose address is unique to that message. When the client loads the image, the sender's server records an "open".
This works without the recipient's agreement, which is why it is common and also why it is unreliable and sensitive.
- Images may be blocked. If the client does not load remote images, there is no open. Some privacy-minded readers block them on purpose.
- Images may be loaded automatically. Some mail clients and privacy features fetch images in advance, through a proxy, whether or not the person opens the message. Apple's Mail Privacy Protection is the best-known example, and it inflates open numbers. Lifecycle email metrics that matter discusses what to use instead.
- Security scanners can fetch links and images. A scan may register a click or open before a human sees the message.
- Plain-text readers never load it. People who read the text version produce no open.
- The message can be clipped. If the pixel sits at the end of a long HTML message, it can be cut off. See Gmail clipping.
An open is a weak signal that can be wrong in either direction. A real person may have read it with images blocked, and a machine may have "opened" a message nobody saw. Treat open numbers as a trend across many messages, never as evidence about one person.
Link clicks
A click is stronger than an open, because someone or something requested a unique link. It is still imperfect, as scanners follow links, but clicks on a specific action link, such as "Confirm your address", are a good sign when they are followed by the action itself.
What none of them can tell you
- Whether the message went to spam. A receipt may arrive for a message in the junk folder, and a missing one does not mean junk. For placement, see inbox placement testing.
- Whether the person understood the message.
- Whether it was the intended person. A shared mailbox or an assistant may have handled it.
- Whether the message was received in the sense a court or a contract would require. If you need legal proof of notice, ask a lawyer about registered delivery methods in your jurisdiction.
What to use instead
For important messages, design for evidence the recipient creates on purpose.
| Need | Better than a receipt |
|---|---|
| Confirm the address is real | A confirmation link the person must click |
| Confirm a decision | A reply with a specific word, or a button that records the choice in your product |
| Know a payment notice was seen | An in-app status or a receipt page showing the payment state |
| Reach someone who has not responded | A follow-up on another channel after a set time |
| Know the message was not rejected | Your delivery events and bounce handling |
The principle is simple: measure the action you want, not the proxy for attention. Email not received: debugging covers what to do when someone says they never got your message, and tracing delivery with Received headers shows how to follow it hop by hop.
A fair way to use each
- Delivery events from your provider: use them to detect bounces and to know the receiving server accepted a message. Alert on rising bounce rates.
- DSN failure reports: act on them. They tell you an address is bad.
- Read receipts: request them rarely, and expect many replies of "no".
- Open tracking: use it only in aggregate. Be open with your recipients about it in your privacy notice, and consider whether you need it at all.
- Click and action events: build your decisions on these where you can.
Privacy and trust
Tracking a person's reading habits without telling them can feel invasive, and in some places it needs disclosure or consent. Say in your privacy notice that you use tracking images and links, offer a way to opt out where the law expects it, and do not track more than you will use. Staff messages inside a company deserve extra care. A read receipt on a message to a colleague can read as surveillance.
Key takeaways
- A 250 response or a "delivered" event means the receiving server took the message, not that anyone saw it.
- Read receipts are optional requests that recipients can decline, so a missing one proves nothing.
- Open tracking is easily distorted by image blocking, privacy proxies and scanners. Use it as a trend, never as proof about one person.
- Design important messages so the recipient leaves evidence, such as a click, reply or recorded choice.
- Be honest about tracking in your privacy notice and use as little of it as you need.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
