Email open tracking explained (and why it's increasingly unreliable)

An open is a log entry for an HTTP request, not evidence that anybody read anything. The sending platform embeds an image at a URL unique to one recipient and one send; when something requests that image, the request is recorded as an open. The gap between those two sentences has been widening for a decade, because a growing share of the things that fetch that image are machines: Apple's privacy relay downloads it in the background whether or not the message was opened, Gmail fetches it through Google's own proxy, and security gateways request everything in a message before delivering it.

What actually happens when an open is recorded

The mechanism is small enough to describe completely. Your platform generates a URL containing an identifier for the recipient and the send, and puts it in an img tag sized one pixel by one pixel, usually transparent. It sends the message as HTML.

Somewhere downstream, something issues an HTTP GET for that URL. Your server records the timestamp, the source IP address, the User-Agent string, and matches the identifier back to the recipient. That row is your open.

Four facts follow directly from the mechanism, and every limitation in this post is one of them restated:

• A message rendered without loading images produces no open. Plain-text reading, image blocking and preview panes with remote content disabled are all silent.
• A request from a machine looks identical to a request from a person, because it is the same request.
• Repeat requests are indistinguishable from repeat reads. A cached image re-fetched on scroll is a second open.
• Every field you record describes the fetcher, not the reader. The IP address, the user agent and the timing all belong to whatever made the request.

Apple Mail Privacy Protection fetches your pixel whether or not anyone opened it

Apple's Mail Privacy Protection, shipped with the 2021 releases of its operating systems, is the largest single break in the mechanism. Apple's own description is unambiguous: Mail "downloads remote content in the background by default — regardless of whether you engage with the email".

The routing is deliberate too. Apple says it "routes all remote content downloaded by Mail through two separate relays operated by different entities. The first knows your IP address, but not any third-party Mail content you receive. The second knows the remote Mail content you receive, but not your IP address." The design goal is stated as denying senders a stable identifier: "Senders can't use your IP address as a unique identifier to connect your activity across websites or apps to build a profile about you."

What lands in your logs, then, is a genuine HTTP request, at a time Apple chose, from an IP address that is not the reader's, for a message that may never have been displayed. It is not a false positive in the sense of a bug. It is a correct record of an event that carries no information about a human.

The signature is recognisable in aggregate. Opens clustered within seconds or minutes of delivery, exactly one per message, from address space that is not the recipient's organisation. What nobody can honestly tell you is what share of your list this affects: Apple publishes no adoption figures for the feature, and every percentage in circulation is a vendor's estimate from its own customer base. Segment your own data by that signature rather than importing somebody's number.

Gmail proxies every image, so the request you log is Google's

Gmail does not let your server talk to the reader's device at all. The Workspace admin documentation states it plainly: "When your users open email messages, Gmail uses Google's secure proxy servers to serve images that might be included in these messages", and the stated reason is that "This protects your users and domain against image-based security vulnerabilities." Administrators can maintain an image URL proxy allowlist to exempt internal URLs, which is the exception that confirms the default.

Three consequences for anyone reading open logs:

Geography is meaningless. The IP address is Google's. Any "opened from Mumbai" reporting derived from it is reporting where a Google server is.

Device and client detection is meaningless for the same reason — the user agent belongs to the fetcher.

De-duplication behaves oddly. Because the image is served from Google's cache rather than fetched from you each time, the relationship between reads and logged requests is not one to one in either direction.

None of this is Google doing something underhand. It is an image proxy behaving exactly as an image proxy should, and open tracking was always parasitic on the absence of one.

The other machines that open your mail before your prospect does

Beyond the two large ones, a queue of software touches a message between acceptance and a human.

Security gateways and mail filters fetch remote resources to inspect them. This is standard behaviour for anything scanning for malicious content, and it happens on delivery, not on reading.

Link and image scanners in corporate perimeters do the same at organisation scale, which is why open rates on enterprise domains behave differently from open rates on small-business domains for reasons that have nothing to do with interest.

Archiving and compliance systems render and store messages, loading remote content as they go.

Preview panes display a message when a reader selects the one above it with a keyboard. This one is a genuine human action producing a genuine open, and it still does not mean anybody read the message.

Your own team clicking through the sent copy in a shared mailbox. Small, constant, and easy to forget when a number looks encouraging.

Click tracking has the same disease, with a rewriting layer on top

Clicks are commonly described as the reliable alternative. They are better, and they are not clean.

Microsoft Defender for Office 365's Safe Links feature "provides URL scanning and rewriting of inbound email messages during mail flow, and time-of-click verification of URLs and links in email messages". The scanning half is the problem for measurement: Microsoft states that "As long as Safe Links protection is turned on, URLs are scanned prior to message delivery, regardless of whether the URLs are rewritten or not", and that "URLs that don't have a valid reputation are detonated asynchronously in the background". A brand-new tracking domain is precisely a URL without an established reputation. There is also a policy option to "Wait for URL scanning to complete before delivering the message", which holds a message until the scan finishes.

The rewriting is at least visible. Safe Links replaces the URL with one under nam01.safelinks.protection.outlook.com or the equivalent for the tenant's data centre region, which means you can identify Microsoft-mediated traffic in your click logs by the referrer and the request pattern. That is more than you get with a pixel, and it is worth building the filter.

The one-click unsubscribe standard has the same failure mode in a more consequential place. RFC 8058 requires an HTTP POST rather than a GET for exactly this reason, and it says so directly: "Anti-spam software often fetches all resources in mail header fields automatically, without any action by the user, and there is no mechanical way for a sender to tell whether a request was made automatically by anti-spam software or manually requested by a user." The specification pins the required header value as List-Unsubscribe=One-Click and requires that both the List-Unsubscribe and List-Unsubscribe-Post headers be covered by a valid DKIM signature.

That sentence from the RFC is the honest summary of this whole subject, written by the people who standardise email, about a problem serious enough to change a protocol over. There is no mechanical way to tell.

What an open rate is still good for

Three uses survive, and they are narrower than the metric's prominence suggests.

A large, sudden drop is a signal worth chasing. If opens on a stable segment fall by half overnight, something changed — placement, a broken tracking domain, a DNS record. The absolute level is uninterpretable; a step change in it is not.

Comparing two variants sent at the same time to the same segment cancels much of the machine traffic, because both arms are exposed to the same prefetchers. This makes opens a usable relative measure inside a controlled test and a useless absolute one outside it.

Detecting outright breakage. Zero opens across a whole campaign usually means the tracking domain is not resolving, not that nobody read the mail.

What it is not good for is any statement of the form "42% of recipients read this". Why open-rate benchmarks are the least trustworthy number in outbound covers what happens when teams build targets on top of that claim.

The cost of carrying a tracking pixel at all

The pixel is not free, and the costs are rarely counted against the data.

It makes every message an HTML message with a remote image. A cold email whose entire argument is that a person wrote it to one other person is structurally an HTML document containing an invisible image from a third-party host. That is a signal, and it points the wrong way.

It adds a hostname whose reputation you may not control. Tracking links are typically served from a subdomain pointed at the platform via CNAME, or worse, from a hostname shared across many senders. A shared tracking domain that another customer gets listed on a URI blocklist affects your messages, and you will have no visibility into why.

It creates a second thing that can break. A tracking domain with an expired certificate produces broken images in every message, which readers do see.

It is a data-protection surface. Recording who read what, and when, from which address, is processing personal data in most jurisdictions your recipients live in.

For a one-to-one cold programme, the honest cost-benefit favours turning it off or sampling it. For a large newsletter where trend data drives editorial decisions, keeping it is defensible. Those are different products and the same word covers both.

Instrument replies instead, and be strict about it

A reply requires a human to compose text. No prefetcher does that, no scanner does that, and no relay does that on someone's behalf. It is the earliest event in an outbound funnel that cannot be manufactured by a machine, which makes it the earliest one worth building targets on.

Doing it properly means matching replies on the In-Reply-To and References headers rather than on a subject line, excluding automatic responses by header rather than by eye, and separating positive replies from refusals under a written rule. How to construct a reply rate that can be compared with itself sets out the denominator and the sample sizes involved, and the cold email benchmark calculator will put a confidence interval on whatever you measure.

There is one question opens were genuinely being used as a proxy for, and it deserves its own instrument: whether the messages are reaching the inbox at all. That is answered by placement seed tests, which mail monitored mailboxes across providers and report the folder each probe reached. A campaign drifting into Promotions while the open rate looks healthy is the exact failure a seed test catches and a pixel hides — and the broader question of what receiving servers actually measure explains why acceptance and placement are different events.

Autocloz reports reply and positive-reply rate per step in campaign analytics and classifies inbound replies in the unified inbox across email, LinkedIn, SMS, WhatsApp and calls. Its free plan covers 5 users and 10 mailboxes with the seed tests and DMARC monitoring included — start free if you would rather measure the thing that cannot be prefetched.

What open tracking cannot tell you, and what Autocloz does not do

It cannot tell you that a person read your message. It can tell you that something requested an image, and the population of things that request images now includes at least one machine on the path of most enterprise mail.

It cannot be corrected with a filter list. Filtering known prefetcher address ranges removes the ones you can identify and leaves the ones you cannot, which biases the remainder in an unknown direction rather than cleaning it. A partially corrected open rate is harder to reason about than an uncorrected one, because it feels trustworthy.

It cannot tell you about placement. A message in the spam folder that a security scanner prefetched records an open.

And it cannot be compared across platforms. Two vendors' open rates differ by their prefetch filtering, their de-duplication window and their pixel placement, which is worth knowing before reading any comparison of sending tools — including the sort of head-to-head on the Smartlead comparison page.

Autocloz specifically: it records opens and reports them, and it does not present them as a measure of readership or build automated decisions on top of them. It cannot detect Apple Mail Privacy Protection with certainty, because the request is indistinguishable from a genuine one at the protocol level and only the aggregate pattern is suggestive. It does not sell an open-rate benchmark to compare yourself against. And it will not claim that any configuration of tracking makes the number true — the mechanism records requests, and requests are not readers.