How Email Tracking Works: Pixels, Wrapped Links and IDs

The one mechanism: your client makes a request the sender logs

An email is a text file with instructions in it. When your client renders those instructions it goes and collects the parts the message refers to — the logo, the product photo, the signature image. Each of those collections is an ordinary HTTP request to whoever owns the hostname written in the HTML. That is the whole trick. A server that receives a request has no idea whether a human read anything, but it does know that the address that was promised a particular image just asked for it.

The request the sender cares about looks like this, and it is usually the only line in the message that is not visible when rendered:

Nothing about that tag harms your machine. It downloads a few bytes, the server writes a line in a log, and the campaign dashboard turns the line into a green dot beside your name. The damage is informational, not technical — which is precisely why it is worth understanding rather than just resent.

Anatomy of a tracking pixel

Pixel URLs are formulaic once you know what each slot is for. Read one left to right and you can usually tell the vendor, the campaign and whether your address travels in the clear.

The detector matches the host and path against 170 named services — 246 distinct URL fragments adapted from the open-source MailTrackerBlocker list plus vendor-documented endpoints — and treats an unlabelled tiny or hidden image as a beacon anyway.

Why the image is 1 by 1 and invisible

Trackers have no reason to be seen, and mail clients give them four reliable ways to hide. Any one of these, combined with a remote host, is what the detector is looking for:

• One pixel square. width="1" height="1" renders as a speck, and at that size it is indistinguishable from a layout spacer.
• No alternative text. A blocked image with alt="" leaves nothing in the layout, so the message looks complete without it.
• Zero-height styling. display:none, max-height:0, line-height:0 or visibility:hidden mean the element is never painted. Some clients still fetch the URL anyway.
• A transparent GIF. The payload is four bytes of nothing. The 1 by 1 transparent GIF is 43 bytes and is the same file in every tracker:

R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7

That base64 string decodes to a GIF header, one pixel, and a terminator. Because the file is identical everywhere, it tells you nothing about who is watching — only the host does. The useful inverse also holds: an image embedded as a data: URI contains its own bytes and makes no network request, so it cannot be a tracker no matter how small it is.

Click tracking: the second reporter is the link

Open tracking is a guess about attention. Click tracking is a fact about action, and it does not need images at all. The sender replaces every destination in the message with a URL on their tracking host, which logs the hit and then sends your browser onward:

Three families of URL tell you this is happening, and they are the three checks the detector runs on links:

• Wrappers. The host in the anchor is not the host you will end up on. Hover before clicking and the status bar shows the redirect.
• Campaign parameters. utm_source, utm_medium, utm_campaign, utm_content, plus vendor-specific ones like mc_eid or hsCtaTracking. These do not require a redirect — they travel with you to the destination and are read by analytics on arrival.
• Recipient identifiers. A per-contact token in the query string, and in the worst case your address itself, percent-encoded: e=you%40corp.com.

A wrapped link and a bare utm_ parameter are different exposures. The wrapper reports to the tracker at click time; the parameter reports to whatever analytics the destination runs. Both identify you, and neither one disappears if you only block images.

What identifies you, in order of precision

Not all tracking knows who you are. The three identification mechanisms rank cleanly by how little inference they need.

Most commercial email uses tier 1 because the vendor already has your address in a database and needs a cheap way to point at it. Tier 3 alone is why a pixel still tells a sender something useful even when the recipient ID is missing: the same mailbox at the same office IP at 8:40 each weekday morning is recognisable without a name on it.

Requests that are not tracking

A remote image is only a tracker if it exists to be measured. Four common things look like pixels and are not, and a detector that flags them is not worth trusting:

• The sender’s own logo served from their own domain, referenced without identifiers. Same family as the From address means the report goes to the brand, not to a third party — still a request, still an open signal, but not a new surveillance counterparty.
• An cid: reference to an attachment already inside the message. Nothing leaves your device.
• A data: URI that carries its own bytes.
• Layout spacers that are inline or absolute paths into the client’s own resources.

The distinction that matters in practice is whose server and what identifiers. A foreign host plus a per-recipient token is the profile signature; a same-domain logo is a brand being a brand.

Why some recorded opens were never read

The mechanism has a flaw senders hate and recipients should know about: a request is not a reader. Two deliberate proxies generate opens that correspond to nobody reading anything.

• Gmail rewrites image URLs to its own proxy hosts, so the pixel is fetched by Google and then served to you from mail-*.googleusercontent.com. The tracker still learns that an open happened, but the IP it logs is Google’s.
• Apple Mail Privacy Protection, shipped with iOS 15 and macOS Monterey in September 2021, prefetches remote images and hides your IP behind a proxy. It fetches images whether or not you look, which means a message can be marked read on delivery. Measurement vendors have warned publicly that open reporting became unreliable for Apple-mailbox recipients.

That asymmetry is why this guide keeps saying request rather than read. The tracker’s number is a count of fetches; your actual attention is not in that database.

How to see the tracking in a message you already have

Everything above is plain text in the message, which means you can check your own inbox in a couple of minutes. Thunderbird is the most direct: open a message and press Ctrl+U for the full source, or turn on all header rows in the message view. Gmail on the web and in its mobile apps hides the source one click deeper: open the message, click the three-dot menu on the message itself, then Show original, which opens the raw source in a new tab.

Outlook on the web and the desktop app do not expose a raw-source view in the reading pane. The universal workaround works in every client: save or forward the message as an attachment, keep it as an .eml file, and open that file in a text editor. Header block, HTML part, and every tracking URL are in it as written.

Reading it by eye is slow, though, because you are looking for one tag among thousands. Paste the same text into the email tracker detector and it separates the four things you care about: which pixels fire, which links report, which identifiers name you, and whether the sender is even authenticated. Nothing is uploaded — the parsing runs in that tab.

A whole message, read end to end

Here is what a typical outbound sales message yields when the source is parsed, which is the sample the detector labels Sales prospecting:

Six findings from one message, and every one of them was already in the file. The tracker did not have to guess; it only had to be readable.