Open and click tracking

An open is not an event you can observe

Email has no read receipt. There is no callback, no API, and nothing in SMTP that tells you a message was looked at. So the industry settled on a proxy measurement: embed a tiny image with a unique URL per recipient, and treat the request for that image as evidence that the message was opened.

<!-- The whole of open tracking: one image, one id per recipient. -->
<img src="https://track.example.com/o/9f2c1a7e.gif"
     width="1" height="1" alt="" style="display:none">

That is the entire mechanism. A dashboard can only report what that one HTTP request carries, and it carries four things:

• The identifier in the URL. Which recipient this is. It is the only part of the request you put there yourself.
• The source IP. Where the request came from, which is what puts the open on a map.
• The user agent. What software made the request, which becomes your device and email client breakdown.
• The timestamp. When the request arrived, which becomes your open time and any "best time to send" advice built on it.

Open rate, open location, device mix, time of day: all of it is squeezed out of those four values. The measurement was always an inference. What has changed is that the mail infrastructure now makes the request by itself, and the IP, the user agent, and the timestamp it sends are its own rather than the reader's.

Apple Mail opens your email for you

Apple Mail Privacy Protection, usually shortened to MPP, shipped with iOS 15 in September 2021 and is on by default. It is not a blocker. It is the opposite, and that is what makes it so destructive to the metric: instead of refusing to load your pixel, it loads your pixel for everybody. Apple's own description is blunt. Mail "downloads remote content in the background by default, regardless of whether you engage with the email." The pixel is requested for messages the recipient never looked at, and for messages they will never look at.

That accounts for the identifier: it fires for people who never read the message. Apple fills in the rest of the request itself, so take the other three values in turn.

• The IP is a relay. Apple routes the download "through two separate relays operated by different entities," so the geolocation of an Apple open is the geolocation of Apple's infrastructure, not the reader's city.
• The user agent is generic. It no longer carries the client version or the platform, so for those recipients your device and client breakdown is a guess.
• The timestamp is a download, not a read. It records the moment Apple chose to fetch the image, which quietly invalidates every send-time optimization feature built on time-of-open.

The scale is what turns this from a caveat into a broken instrument. Litmus, measuring more than a billion opens in May 2026, puts Apple Mail at 64.66% of all tracked opens, and reckons MPP touches roughly 55 to 60% of every open, from every client, that anyone records. Read that second number carefully. It does not say open rates are somewhat inflated. It says most of the rows in your opens table were written by a machine on a schedule, for messages that may never have been read.

There is an irony worth sitting with. The best public data on how thoroughly open tracking is broken comes from open tracking, because that is the only instrument anyone has. Litmus can only count the opens it can see, from the customers who use its analytics, which is a self-selected sample rather than a census. The number is directional and it is the best available, but it is measured with the same broken ruler.

Gmail sits in front of every image, and here it pays to be precise

Since 2013 Gmail has served remote images through its own proxy rather than letting the client hit your server. Your tracking pixel is fetched by Google, from a Google IP, with a Google user agent. This is what a Gmail open actually looks like arriving at your endpoint:

GET /o/9f2c1a7e.gif HTTP/1.1
Host: track.example.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko Firefox/11.0
             (via ggpht.com GoogleImageProxy)
X-Forwarded-For: 66.249.84.201

Nothing in that request belongs to the recipient. The proxy also caches, so a repeat open by the same person can be served from Google's cache and never reach you at all. Per recipient the identifier still resolves, so you learn that someone opened it, but "opened three times" is not a number Gmail reliably lets you observe. Cache-busting does not help, because the URL is already unique per recipient and it is that URL that Google caches.

Gmail is also widely blamed for prefetching pixels and inflating opens the way Apple does, and here the folklore outruns the evidence. Litmus documents that Gmail's prefetch is conditional, requiring the user to be logged into the Gmail app and coming from a Google IP, and cites SparkPost's estimate that it inflates open rates by up to about two percentage points. Two points is a rounding error next to Apple. If you are debugging a suspiciously high open rate, Gmail is almost never the culprit, and reaching for it first wastes the investigation.

The click is not a click either

Click tracking works the same way, by inference. Your links are rewritten to point at a tracking endpoint that records the hit and then redirects to the real destination.

<!-- What ships is not your URL. It is a hop through the tracker. -->
<a href="https://track.example.com/c/9f2c1a7e?u=https%3A%2F%2Fexample.com%2Fpricing">
  See pricing
</a>

// The click endpoint: record, then forward.
// Note what this is: a GET with a side effect. Anything that fetches it counts.
app.get("/c/:recipient", async (req, res) => {
  await recordClick(req.params.recipient, req.query.u);
  res.redirect(req.query.u);
});

Look at what that endpoint is: a GET request with a side effect. It records a click for anything that fetches the URL, and plenty of things fetch the URL that are not people. Microsoft's Safe Links, part of Defender for Office 365, is documented to scan URLs before the message is delivered and again at time of click, and to rewrite them so that clicks route through Microsoft. Mimecast, Proofpoint, and Barracuda run comparable products. Every recipient behind a corporate mail gateway may be behind one, and you cannot tell from your side which ones.

The result is a phantom click: a scanner traverses every link in the message, on delivery, with no human involved, and your tracker faithfully records each one. This is the same machinery that breaks single-use tokens, covered in link prefetching and security scanners. The difference is that a consumed magic link produces a loud bug report, while a phantom click just makes your campaign look successful.

What Link Tracking Protection actually strips

The most repeated claim about email click data is that Apple's Link Tracking Protection strips your UTM parameters and destroys campaign attribution. It is worth checking that against Apple's own sources, because it is not what either of them says.

Apple's announcement describes a feature that removes tracking information "from the links users share in Messages and Mail," and from links in Safari Private Browsing, while promising "the links will still work as expected." The scope is narrower than the claim. And WebKit is specific about which parameters qualify: known cross-site click identifiers, such as gclid, fbclid, msclkid, and mc_eid.

utm_source, utm_medium, and utm_campaign are not on that list. They are campaign labels, not per-user identifiers, and the stripping targets parameters that identify a person across sites. Nor does an ESP's redirect-based click tracking depend on those parameters in the first place: the identifier is in the path of the tracking URL, which is not touched.

So the honest position is that Link Tracking Protection is real, documented, and mostly not your problem. The thing genuinely corrupting your click numbers is not Apple removing parameters. It is scanners adding clicks.

Why click-to-open is the worst number on the dashboard

Click-to-open rate, clicks divided by opens, is usually sold as the robust metric, the one that survives because the distortions cancel out. They do not cancel out, because the numerator and the denominator are contaminated by different machines.

• The denominator is inflated by Apple. Mail Privacy Protection downloads pixels for consumer recipients whether or not they read anything, which is where most of the fake opens come from.
• The numerator is inflated by corporate scanners. Safe Links and its competitors traverse links for recipients behind enterprise gateways, which is where most of the fake clicks come from.

Those two populations barely overlap. A consumer on an iPhone generates a fake open and no fake click; an employee behind a mail gateway generates a fake click and often no Apple-prefetched open. The ratio is not a noisy version of the truth that you can correct with a fudge factor. It is a quotient of two differently-wrong numbers, and it can move because your audience's employer changed security vendors.

What you can still measure

The useful reaction to all of this is not to stop measuring. It is to stop treating inferred human attention as a measurement, and to move your reporting onto signals that are actually events.

• Delivery and bounces. These happen at the SMTP layer. A 5xx is a fact, not an inference, and it is the one part of the pipeline no proxy rewrites.
• Spam complaints. A real human pressed a real button, and the mailbox provider tells you. Google Postmaster Tools reports this directly, and Gmail's sender guidelines make it consequential: senders are told to keep the user-reported spam rate below 0.1% and to never let it reach 0.3%. It is the rare email metric that is both trustworthy and graded.
• Unsubscribes. A compliant one-click unsubscribe happens on a POST, which is exactly why scanners do not trigger it. The same property that makes it scanner-proof makes it a clean signal.
• Conversions on your own server. A session that reaches your site, signs in, and buys something is first-party data you own end to end. Attribute it to the send with a campaign parameter and measure the outcome rather than the gesture.
• Trends, not levels. An absolute open rate is close to meaningless. The same number for the same segment, tracked over time with the same instrument, still detects a deliverability cliff. Compare campaigns to each other, never to an industry benchmark, and never across a period in which a mailbox provider changed its behavior.

You can also filter the obvious machines. Opens that fire within seconds of delivery, a click that arrives before any open, every link in a message clicked at once, requests from known proxy ranges and scanner user agents: each is a reasonable heuristic and none is a fix. Scanners increasingly render links in a full browser precisely to look like real users, and Apple's relays are indistinguishable from Apple's relays. Filtering improves the number without making it true, so it is worth doing, and it is not worth believing.

Sources

• Apple Legal: Mail Privacy Protection - remote content downloads in the background regardless of whether you engage
• Apple Support: Use Mail Privacy Protection on iPhone
• Litmus: Email Client Market Share - May 2026, over 1 billion opens, from Litmus customers rather than a census
• Litmus: how Gmail prefetching of images skews open data - prefetch is conditional; SparkPost estimates up to about two percentage points
• Microsoft Learn: Complete Safe Links overview for Defender for Office 365 - URLs are scanned before delivery and rewritten for time-of-click checks
• Apple Newsroom: Apple announces powerful new privacy and security features - scopes Link Tracking Protection to links shared in Mail and Messages
• WebKit: Tracking Prevention in WebKit - names gclid, fbclid, msclkid and mc_eid; utm_ parameters are not listed
• Gmail: Email sender guidelines - keep spam rate below 0.1%, never reach 0.3%