Email tracking pixels: what the sender learns when you open

What a tracking pixel actually is

There is no special technology involved, which is exactly why it is everywhere. It is three ordinary things put together:

An image nobody is meant to see: Usually one pixel across and transparent, or a spacer that looks like part of the layout. Nothing about the picture matters; it exists to be fetched.
A URL that belongs to you alone: The address of that image carries an identifier unique to the copy of the message you were sent. Two people opening the same newsletter fetch two different URLs.
A request that is the whole point: Your mail client asks the sender's server for that image. The server does not have to answer usefully — it only has to write down that it was asked, by whom, and when.

Nothing is installed, nothing is executed, and no rule is broken. It is the ordinary behaviour of a mail client displaying a picture, turned into a signal.

What one request tells the sender

More than most people expect from an image, and it arrives whether or not you reply:

That the address is live and read by a human. The most valuable fact of the lot: it moves the address from a list to a confirmed target, and confirmed addresses get sold and reused.
When you opened it — to the second, and every time you open it again. Opening a message three times over a week is three data points about your habits.
Your IP address, and therefore roughly where you are and which network you are on. Not a street, usually a city and a provider.
Your device and mail client, from the user agent the request carries.
That the message travelled, when the same unique URL is fetched from two very different places — which is what forwarding looks like from the outside.

The image is a request, and the request is the report. Nothing here is retrieved for your benefit, so nothing is lost by not making it.

What it does not tell them

Worth being precise about, because the fear is usually larger than the fact:

Not who you are: A pixel identifies the message, not the person. What ties it to a name is the address it was sent to — which is the part a throwaway address withholds.
Not what you did next: Opening a message says nothing about whether you read it, believed it, or acted on it. Only a click says that.
Nothing at all, if it never loads: An unfetched pixel produces no record. There is no fallback signal, no retry and no second channel — silence is indistinguishable from never having received the message.

How this inbox handles it

Remote images are blocked from the moment a message opens, and you turn them on for the message in front of you with one click. What is worth explaining is how, because the how is what makes it dependable:

A message body is HTML written by a stranger, so it is not rendered inside the page. It is served from its own address, into a sandboxed frame, under a policy of its own — and that policy is what blocks the images:

the policy the message is served under

Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline';
                         img-src data:; media-src 'none'; font-src 'none';
                         script-src 'none'; form-action 'none';
                         frame-ancestors 'self'; base-uri 'none';
                         sandbox allow-popups allow-popups-to-escape-sandbox

Blocking by policy rather than by editing the message is the decision that matters. Rewriting HTML means finding every attribute that can fetch something — src, srcset, background, a URL inside a style rule — and missing one silently defeats the whole exercise. A policy does not have to find anything: nothing may be fetched unless it is named, and only data: is named.

Inline images still show: img-src data: is always allowed, because an image carried inside the message asks nobody for anything. That is why some pictures appear even with blocking on.
Nothing else may load at all: No scripts, no remote fonts, no video, no nested frames, no form submissions. A font hosted by the sender is a tracking request like any other, and it is closed too.
A blocked image leaves a mark: A discreet hatched box, so a message with a missing picture does not look broken — and only when blocking is on, so a legitimate image is never drawn on a hatched background.

The frame is sandboxed as well, which is a different protection for a different problem: policy stops the message reaching out, and the sandbox stops it reaching in. Neither depends on the other being right.

What other inboxes do about it

Blocking is not the only approach, and the one your other mailbox takes decides what a sender actually gets from you. There are three, and they protect you to very different degrees:

Fetching the image on your behalf: The webmail provider requests every remote image itself and serves you a copy. The sender sees a request from the provider rather than from you, so your address and your location stay out of it — but the open is still recorded, and it is recorded the moment the message is displayed.
Fetching everything, for everyone: Some clients pre-load the contents of every message that arrives, whether or not anybody opens it. That is the strongest of the three for the reader: a pixel that fires for every message tells the sender nothing about which ones were read. It is also why open rates stopped meaning very much.
Blocking, and asking: What most desktop clients do and what happens here: nothing remote loads until you say so. The difference is that a proxy decides for you and this does not — the request is simply never made unless you make it.

None of the three requires anything of the sender, and none of them can be detected from the outside with certainty. That is worth remembering in the other direction too: if you send mail and read open rates, a large share of your opens are proxies and a large share of your non-opens are people who read the message with images off.

The tracker that blocking images does not stop

Every link in a commercial message can carry the same identifier the pixel does, and usually does. The address you see is not always the address you visit: click and you often land on a redirector that records the click and then forwards you.

This matters more than the pixel, in both directions. A click proves a human read the message and chose to act, which is worth far more to a sender than an open — and unlike an open, it is entirely under your control.

Read the destination before you click. Hover or long-press: a link whose visible text and real target disagree is worth suspicion on its own.
Type the destination yourself when it is a site you already know. Nobody needs to send you to your own account page.
Never click to unsubscribe from mail you did not sign up for. On genuine marketing it works; on a message sent to a guessed address it is a reply, and it confirms exactly what the pixel wanted to know.

Links here open in a tab of their own and carry no referrer, so the destination is not told which message sent you. That protects the mailbox — not the click itself.

Read receipts, and why none is ever sent

Some messages ask outright: a header requesting that your mail client confirm delivery or reading. In an ordinary client that is a dialogue box, and the polite answer is often the wrong one.

Here the question cannot arise. This service receives only — there is no sending path at all, so a request for a receipt has nothing to reply with. It is not a setting that could be switched on by mistake; the capability does not exist.

The plain-text version is the quietest thing you can read

Almost every formatted message carries a plain-text copy alongside the HTML — senders include it because some clients need it. It has no images, no styles and no way to fetch anything, so reading it makes exactly zero requests.

The inbox offers it under the message. For a confirmation code or a link you were expecting, it is usually the faster read as well as the quieter one.

What the address itself gives away

All of the above is about one message. The address is about all of them, and it is the stronger signal by a distance:

One address used everywhere ties everything together. Two companies holding the same address are two companies holding the same identifier, whether or not they ever compare notes. A broker who buys both lists compares them for a living.
A throwaway address withholds the part that identifies you, which is why a pixel that does fire from one tells the sender far less than the same pixel in your real inbox.
An address per service turns a leak into a name. When mail starts arriving at the address only one company ever had, you know which one.

The guide to signing up without your real address covers that habit properly, including the alias — a second address that reaches the mailbox and cannot read it.

Five habits that actually reduce what leaks

Leave images off. They are off by default here; on for one message when you need them is a decision, not a default.
Read the plain-text version when the message is a code, a link or a receipt. It cannot fetch anything.
Treat a click as louder than an open, and type known destinations instead of following them.
Use a different address per service, and hand out the alias rather than the address.
Delete the message when you are done with it. Everything goes in 5 days anyway, but a message you have finished with has no reason to sit there.

None of this makes you invisible, and anybody promising that is selling something. It removes the easy signals, which is the part that is actually in your hands.

What this site holds about a public mailbox, and for how long, is set out in full on the privacy page — including the sentence that matters most, which is that anyone who knows a public address can read it.

Questions

Can the sender tell that I opened their email?

Only if something in the message loaded from their server. That is almost always an image. If remote images never load, an open leaves no trace at all — there is no second mechanism that reports it.

Does a temporary email address stop tracking?

It changes what the tracking is worth rather than whether it happens. A pixel that fires still says the message was read; what it cannot say is who read it, because the address it was sent to is not yours in any lasting sense.

Are remote images blocked by default here?

Yes, on every message, before it is displayed. They are blocked by the security policy the message body is served under rather than by editing the message, so there is no attribute that can be overlooked. One click shows them for the message you are reading.

Why do some images appear even with blocking on?

Because they came with the message rather than from a server. An image embedded as a data: URI is part of the file you already have, and displaying it asks nobody for anything, so it is always allowed.

What exactly happens when I press “Show images”?

The message is reloaded with remote images permitted, and every image URL in it is fetched — including any pixel. No referrer is sent with those requests, so the sender is not told which page you were reading, but the request itself is the signal and it has now been made.

Do you send read receipts?

No, and it is not a setting. This service receives mail and never sends any, so a message asking for a receipt has nothing here that could answer it.

Can a message run scripts in my browser?

No. The body is rendered in a sandboxed frame under a policy that permits no scripts at all, and the frame has neither access to the page around it nor the ability to navigate it.

Is clicking a link worse than loading an image?

For what it tells the sender, yes. An open says a message was displayed; a click says a person read it and decided to act, and it usually passes through a redirector that records exactly which link and when.

Does the plain-text version track anything?

It cannot. Plain text has no images, no styles and no way to reference anything outside itself, so displaying it makes no network requests whatsoever.