An open is not a read. What a read receipt actually proves, and what trips one without a person.

A read receipt says "opened", and it is very tempting to read that word as "they read it". The two are not the same thing, and the size of the gap between them is worth knowing if you are going to lean on the signal at all. What a read receipt actually records is narrower and stranger than the word suggests, and once you see what it measures, you read it correctly instead of trusting it too far.

What the signal actually is

A read receipt of this kind is a tiny invisible image, one transparent pixel, embedded in the email with an address that is unique to that message. When the email is displayed and the mail program loads its images, the recipient's software asks a server for that pixel. The server notes that the request arrived, and that noted request is what becomes "opened" on your side. Notice what did not happen. Nobody's eyes were measured. No text was confirmed read. A request for a small image arrived from somewhere, and the system turned that arrival into a word about a person. Most of the time the inference is fair: a request usually means a human opened the message and their software fetched the images. But it is an inference, and a few things make the request without a person reading anything.

What trips it without a read

The first is a mail provider or a security system that fetches images before the person ever sees the message. Some providers load every image in a message on delivery, to scan it or to cache it, which produces an "open" the instant the mail lands, hours before anyone looks. The second is caching and proxying, where the image is fetched once through an intermediary and then served from a copy, so a later genuine open can leave no new trace. The third is a preview pane that renders the message as the list is scrolled past, loading the pixel without the person stopping to read a word. The pattern in all three is the same: the fetch is real, the reader is not.

The gap runs the other way too

The signal can also stay silent when a real read happened. Many people, and many default settings, do not load images at all. A person can open your message, read every line, and reply, and because their software never asked for the pixel, your receipt shows nothing. So a missing open is not evidence the message was ignored. It is evidence of one of two very different things, a message not read or a message read with images off, and the receipt cannot tell you which.

What it actually proves, and how to read it

Put plainly: an open event proves that the pixel was fetched, once, from somewhere. That is genuinely useful. A fetch is far more information than the silence you have with no receipt at all, and most fetches really are a person opening your mail. But it is a signal, not a certificate. The honest way to read it is to treat an open as "very likely read", and to treat a non-open as "unknown", never as "ignored". The moment you turn "opened" into a certainty, or "not opened" into a slight, you are trusting the word over the thing it stands for.

Why I would rather you know this

I would rather the person using a read receipt understand what it can and cannot say than be quietly misled by a green checkmark. A tool that shows you an open is showing you a fetched pixel, and a good one does not pretend that fetch is a signed confession. Knowing the gap does not make the signal useless. It makes it usable, because you stop asking it for a kind of certainty it was never able to give.

The general shape

Any measurement that stands in for something you cannot directly see is only as trustworthy as the gap between the proxy and the real thing, and that gap is usually invisible until you go looking for it. A fetched pixel stands in for a human read. Most of the time they coincide, some of the time they do not, and the reading you make is only sound if you carry the gap in your head. Know what the number counts, not what you wish it counted, and it becomes a good instrument instead of a misleading one.

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your Gmail sent list, one tick sent and two blue ticks opened. Everything above is how I think the ticks should be read, as a strong signal and not a certificate. It costs 4 dollars a year, and the free tier covers 30 emails a month. You can find it at blueticks.io.