What actually happens when you open your Sent folder
Every pixel-based tracker works the same way. When you send, a tiny image is placed in the message with a unique address. When a mail client displays the message, it fetches the image, and the tracker's server records the fetch as an open.
The copy in your own Sent folder contains the same image. So when you open a sent message to check what you wrote, your Gmail displays it, fetches the pixel, and the server records an open. Seconds after you look at Sent, the checkmark turns green. It is the most common complaint about every tracker on the market, and it undermines every other number the product shows: if the tracker cannot tell you from your recipient, why believe anything else it says?
Why the request is indistinguishable from a recipient's
Gmail does not fetch images from your browser. It fetches them through its own image proxy, which then serves the image to the page. The proxy identifies itself with a fixed user agent and comes from Google's network, whoever the reader is. When you view your sent message in Gmail, the request that reaches the tracker is:
- the same user agent as for any Gmail reader,
- from the same Google network,
- with the same referrer.
Nothing in that request says whether the person behind it is the recipient reading in Gmail or the sender re-reading in Gmail. At the HTTP level, the two are the same event.
There is a second, smaller path. Sometimes Gmail web renders the copy you just composed directly, fetching the pixel with a mail.google.com referrer from your own browser rather than through the proxy. That request does carry something distinctive: it comes from your own network.
What commercial trackers do about it
The best-known tracker holds a patent on a mechanism that, after sending, replaces the copy in your Sent folder with a clean copy that has no pixel in it. That requires reading, writing and deleting messages in your mailbox through the Gmail API, which is one of the reasons commercial trackers ask for the full Gmail scope. It also does not help when the message is quoted in a reply, or when you read your sent mail somewhere the tracker cannot reach, which is why vendors document residual self-opens in the official Gmail mobile app.
Extensions add heuristics on top: recognising sender activity in the browser, and mobile apps that know which account is reading. Those work as far as they reach.
What MailSignals does without the Gmail API
MailSignals requests no Gmail scope, so it cannot rewrite your Sent copy. Instead it uses two facts the request itself does not contain: the extension is running in your browser and can see what is on screen, and the message was registered from your own network.
- +0.6 s Your own view Pixel loaded Your own Gmail loaded the image while showing the copy in your Sent folder. Who: You.
- +9 min Your own view Pixel loaded You were viewing this message in Gmail at the time, so this is your own open. Who: You.
The extension reports a view for each sent message you have expanded on screen while the tab is visible, on load, on every expansion, and on a 20-second heartbeat. On the server, four automatic paths use that:
| Order of arrival | What catches it |
|---|---|
| The view report arrives before the pixel fetch | The classifier sees a view within 20 seconds and judges the fetch your own on the spot |
| The pixel fetch arrives first (the common case) | When the view report lands, every counted open within 20 seconds of it is withdrawn |
| Both are in flight at the same moment | A database trigger that runs after the open is committed re-checks and withdraws it before any alert or statistic sees it |
| Gmail rendered your Sent copy directly | The fetch carries a Gmail referrer and the same salted network hash the message was registered from; no view report is needed |
The third row is worth a sentence. In a local emulator both halves finish in about a millisecond and the case never happens. Against real cloud infrastructure the gap is wide enough to fall through, and the project's end-to-end suite caught it on the first production run. Withdrawal also rebuilds the open counters from every event rather than subtracting one, because subtracting drifted the moment two corrections raced.
The one setting that fixes it at the source
Whatever tracker you use, the self-open exists because your mail client loaded the image. Stop it loading images and the problem disappears. In Gmail:
- Web: Settings → See all settings → General → Images → Ask before displaying external images.
- Android and iOS: Menu → Settings → your account → Images → Ask before displaying external images.
Do it on every device you read mail on. It costs you one click on the rare message where you want the images, and it removes the ambiguity rather than papering over it.
Two things do not help, or help less than people think. Sending a test to yourself proves nothing, because a message whose every recipient is you is never tracked in the first place. And a reply that quotes your original carries your pixel too; Gmail collapses quoted text and does not load images inside it until someone expands the quote, so this is rarer in Gmail than in other clients, but it exists.
Related: the feature page, with the five paths in detail · what else Gmail's proxy hides · the full rule table.