Gmail read receipts without OAuth: what pixel tracking can and cannot tell you

If you have ever wondered whether the email you sent was actually read, you have probably discovered two uncomfortable facts. Gmail's own read receipts only exist on Workspace accounts, and every third party tracker you look at asks for permission to read your mailbox.

The second fact is the interesting one, because it is not technically necessary. This post is about how read receipts actually work in email, why the number they give you lies in both directions, and why so many implementations ask for far more access than the job requires.

Why email cannot do what WhatsApp does

WhatsApp shows you two blue ticks because one company controls both ends of the conversation. The app on the recipient's phone reports back to the same server that delivered the message. The tick is a genuine acknowledgement from the client.

Email has no such channel. It is federated by design: your message leaves your provider, crosses one or more relays, and lands in software nobody in the chain controls and nobody can compel to report anything back.

There is a standard that tries. A Disposition-Notification-To header politely asks the recipient's client to confirm that the message was displayed. It fails for two reasons that no implementation can fix. Most clients either ignore the header or ask the recipient for permission first, and the recipient can simply decline. Gmail exposes it only to Workspace accounts, and even there it remains a request rather than a fact.

So every consumer read receipt product on the market does the same thing instead.

What a tracking pixel really is

You embed a reference to a remote image in the outgoing HTML, with a unique identifier per message:

<img src="https://example.com/o/9f3c1a7e.png" width="1" height="1" alt="">

The server hosting that path returns a transparent one pixel image and records the request: identifier, timestamp, user agent, IP address. That record is your open event. There is no other mechanism. Every tool that shows you ticks, dots, or notifications is doing this, however it is dressed up in the interface.

Notice what the record actually proves. It proves that something requested an image. It does not prove that a human looked at a screen.

The number lies in both directions

It is worth being specific about this, because the failure modes are not symmetric and knowing them changes how you read the data.

False positives, opens that were not reads. Apple Mail Privacy Protection fetches remote content through a proxy for every message, by design, before anyone opens anything. Corporate mail gateways, spam filters and link scanners fetch images to inspect them. Some clients prefetch. A single forward to three colleagues produces three more requests, all attributed to your original recipient.

False negatives, reads that were not opens. A recipient who blocks remote images, or reads in plain text, can read your message from start to finish with nothing recorded at all. Anyone reading on a locked down corporate client is often invisible to you.

And one case that is neither. Gmail serves remote images through its own image proxy. The fetch still happens when the recipient displays the message, so you do keep the open event, but the IP belongs to Google rather than to your recipient, so any geolocation or device detail is worthless. Re-opens may be served from the proxy cache and never reach you at all, which means repeat view counts on Gmail recipients are systematically undercounted.

The practical consequence is that the signal is asymmetric. Zero opens over several days is reliable information and worth acting on. A high open count is not.

The part that is actually a choice: how much access you need

Here is where implementations diverge, and where it is worth reading the permission prompt.

Many trackers request Gmail API scopes:

https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/gmail.send

Those scopes grant standing server side access to your mail: subjects, bodies, attachments, recipients, the whole mailbox, usually with a refresh token that keeps working while you are not looking. Products ask for them because it makes the implementation easier. If you can send on the user's behalf, you can inject your pixel server side and you never have to touch the browser. If you can read the mailbox, you can reconcile opens against threads on your own backend.

None of that is required to put a tick next to a sent message. A browser extension can do the whole job locally:

{
  "permissions": ["storage"],
  "host_permissions": ["https://mail.google.com/*"]
}

A content script inserts the pixel into the compose window before the message is sent, and renders the tick by writing into the Sent list in the DOM. The subject line, the body and the recipient never leave the browser. The server only ever needs to know that identifier 9f3c1a7e was requested at a given time, which is the minimum required for the feature to exist at all.

The tradeoff is real and worth stating. The DOM approach breaks when Gmail changes its markup, and it cannot follow mail you send from your phone. Server side OAuth is more robust and works everywhere. That is a legitimate engineering choice. It is just rarely presented to the user as a choice, which is the part I object to.

Reading your own data honestly

Three habits that make this kind of tracking useful rather than misleading:

1. Treat a single open as noise and a pattern as signal. Two opens ten minutes apart from the same client tells you something. One open thirty seconds after you sent it usually tells you a scanner ran.
2. Exclude your own opens. Reading your message in your Sent folder should not count, and if your tool counts it, your numbers are inflated from the start.
3. Never build a workflow on the absence of tracking data being neutral. It is not neutral. It correlates with privacy conscious and corporate recipients, which is often exactly the group you care about.

Disclosure

I build one of these tools, so weigh the above accordingly. BlueTicks shows WhatsApp style ticks in the Gmail Sent list, one tick when the message is sent and two blue ticks when it has been opened. It is the extension shaped implementation described above: no OAuth, no mailbox access, subjects and recipients stay in the browser. There is a free tier with a monthly cap, and 4 dollars a year for the paid one. It is on the Chrome Web Store and on Firefox Add-ons.

If you take one thing from this post, let it be the permission prompt. Whatever tool you use, the question worth asking is not whether it tracks opens accurately, because none of them can. The question is how much of your mailbox it needed in order to try.