Tracking and Measurement Distortion

If your sunset policy, your warm-up segments of "recent openers" or your open-rate benchmarks depend on engagement data, they depend on two tracking mechanisms that privacy features and security scanners now distort systematically. Below is how open and click tracking work, what distorts each one, and which metrics you can still trust.

A note on sources: the three Litmus help center articles cited have moved to a Validity knowledge base (knowledge.validity.com) that only loads with JavaScript and cannot be retrieved as static pages. The content here comes from Wayback Machine snapshots of the original help.litmus.com pages (captured 2024-09-16, 2024-12-11, and 2025-02-13; the pages show "last updated" dates from Aug 2023 – Nov 2024).

How tracking works

Open tracking: the 1×1 pixel

Open tracking inserts a transparent 1×1 image (the "tracking pixel") into the HTML body. Its URL is unique to each recipient and points to the tracking domain of the sender or the ESP. When the mail client displays the message and fetches remote images, the request for the pixel reaches the tracking server, which logs an "open" together with the requesting IP address, the user agent and a timestamp. Litmus describes its own analytics in the same way: "Email Analytics uses a 1x1 tracking pixel, similar to how most ESPs provide open rate metrics. Every time this pixel is loaded, we detect an open."

Some consequences follow from the design itself, before any privacy feature comes into play:

• If no image loads, no open is recorded. Clients with images turned off, plain-text display or text-only clients produce false negatives. An "open rate" is really a pixel-load rate.
• Every image load records an open. That includes the sender previewing the campaign in the ESP or in a browser, the message being posted on a website or on social media, and a tracking code reused across templates (all failure modes that Litmus documents).
• Total and unique opens: raw pixel hits are total opens. ESPs remove duplicates to count unique opens for each recipient, because they know which subscriber each request belongs to.
• ESPs already filter out obvious loads by machines. Litmus notes that some providers "discard any [pixel loads] that appear to be multiples, for example if more than 4 hits are recorded in less than one second… to counteract proxy opens that some inbox providers use to speed email loading."

Click tracking: wrapped redirect links

Click tracking rewrites every href in the message so that it points to the redirect (tracking) domain of the sender or the ESP, with an encoded identifier. The redirect server logs the hit and sends an HTTP redirect to the original destination. In Litmus's words, recipients "are redirected to a special web server hosted by your ESP that makes a note of the 'hit' and then sends them on their way." Only the sending platform can do this, because the links must be rewritten when the message is sent. That is why tools that only provide analytics, such as Litmus, do not offer click tracking.

The tracking domain has a reputation of its own. URL blocklists and content filters evaluate the redirect domain found in the body, so a shared tracking domain spreads reputation across every sender that uses it (see Content & Design).

Distortion source 1: Apple Mail Privacy Protection (MPP)

MPP was introduced with iOS 15 and macOS Monterey (2021). It is available in Apple Mail on iOS, iPadOS, visionOS and macOS, and on iCloud.com. It applies to any mailbox read in Apple Mail, not only to @icloud.com addresses.

What Apple's own documentation says it does

From Apple's legal and privacy page:

• Remote content is downloaded "in the background by default — regardless of whether you engage with the email." The pixel is fetched in advance when the message arrives, not when a person views it.
• Downloads pass through two separate relays: "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 sender therefore sees the IP address of an Apple proxy, not the recipient's.
• Its stated purpose is to prevent senders from learning "when and how many times you opened their email, whether you forwarded the email, your Internet Protocol (IP) address, and other data."

From the macOS Mail support guide (Mail > Settings > Privacy):

• With Protect Mail Activity turned on, "your IP address is hidden from senders and remote content is privately downloaded in the background when you receive a message (instead of when you view it)."
• With it turned off, two independent options appear: Hide IP Address (the IP address is hidden, but content is not fetched in advance) and Block All Remote Content (nothing remote loads at all; the user sees a banner and can load the content manually).
• According to the legal page, Hide IP Address "will still mask your IP address" even when MPP itself is turned off.

The feature is offered when Mail is first opened and stays on unless the user turns it off. In practice, almost all Apple Mail users have it on. The settings are in Settings > Apps > Mail > Privacy Protection on iOS, iPadOS and visionOS, in Mail > Settings > Privacy on the Mac, and in Settings > Privacy & Security on iCloud.com.

What this does to sender data

Operators should know one caveat: the advance fetch is not guaranteed for every message, because devices must be on power or connected to a network for background activity. MPP opens are therefore close to, but not exactly, 100% of the volume delivered to these recipients. You can identify MPP opens in event data by the Apple proxy user agent and Apple's IP address ranges on the pixel requests.

MPP does not affect clicks. A click still comes from a real action by the user. The IP address of the following visit to the landing page may be hidden by iCloud Private Relay for Safari users, but the click event itself is genuine.

Distortion source 2: Microsoft Safe Links (clicks)

Safe Links is the URL protection in Microsoft Defender for Office 365. It matters to senders because it both rewrites their links and fetches them without any person clicking.

How it works, according to Microsoft's documentation of Safe Links policies:

• Coverage is on by default. There is no default Safe Links policy object, but the Built-in protection preset security policy "provides Safe Links protection to all recipients by default" in any organization licensed for Defender for Office 365 (Plan 1/2, included in Microsoft 365 E5 and various business plans). The Standard and Strict presets and custom policies apply on top of it. Policy changes take up to 6 hours to apply.
• URL rewriting: the default email setting is "Safe Links checks a list of known, malicious links when users click links in email. URLs are rewritten by default". Links in the delivered message point to *.safelinks.protection.outlook.com, with the original URL encoded as a parameter, which allows verification at the time of the click. Every click passes through Microsoft before it reaches the sender's tracking redirect.
• Real-time scanning and detonation: the option "Apply real-time URL scanning for suspicious links and links that point to files" (ScanUrls) scans the linked content, and "Wait for URL scanning to complete before delivering the message" (DeliverMessageAfterScan, recommended On) holds delivery until the scans finish. These scans fetch the sender's URLs from Microsoft's infrastructure. Each fetch of a wrapped tracking link registers at the ESP as a "click" that no person made, typically seconds after delivery.
• API-only mode: "Do not rewrite URLs, do checks via SafeLinks API only" leaves the URLs in the body unchanged, and supported Outlook clients call Safe Links when the user clicks. In this mode the sender's links do not look rewritten, but checks at the time of the click still happen.
• Lists of URLs not to rewrite: administrators can exempt URLs (DoNotRewriteUrls) from being wrapped as mail flows through. Microsoft notes that exempted URLs "might still be blocked at time of click" unless they are also allowed in the Tenant Allow/Block List.
• Click telemetry: "Track user clicks" (TrackUserClicks) is on by default. Warning pages for blocked URLs can prevent the user from continuing to the link at all (AllowClickThrough $false). A genuine click on a tracking domain that was flagged by mistake then never reaches the sender. This path produces false negatives for clicks, alongside the false positives from detonation.

Senders see these effects most on B2B lists (Microsoft 365 tenants). Corporate recipients under the Strict preset policy produce the most aggressive fetching of links before delivery.

Distortion source 3: other gateway and security scanners

Other products follow the Safe Links pattern. Secure email gateways (Proofpoint, Mimecast, Barracuda, Cisco IronPort, advanced protection in Google Workspace, and many antivirus products) commonly:

• Fetch every link in a message at delivery or shortly after, to check the destinations ("link detonation" or sandboxing). That includes the unsubscribe link. This is why one-click unsubscribe under RFC 8058 uses POST rather than GET (see List-Unsubscribe): scanners send GET requests, so an unsubscribe that acts on a GET gets triggered by robots.
• Rewrite links through their own redirectors (e.g., urldefense.com, Mimecast link protection), which adds a second redirect in front of the ESP's tracking redirect.
• Fetch the tracking pixel while scanning content, which produces "opens" by scanners from data center IP addresses.

Patterns of behavior that tell scanner clicks from human clicks:

To filter out bot clicks in practice, score each event against several of these heuristics rather than any single one. Some scanners click only a random selection of links, and some corporate outgoing IP addresses serve both scanners and people. Never trigger an action that cannot be undone, such as an unsubscribe, a change of preferences or a one-click purchase, on a bare GET request.

Distortion source 4: image proxies at Gmail (and at Yahoo and AOL)

Gmail rewrites all image URLs through its image proxy (googleusercontent.com). The recipient's client fetches images from Google's cache, and Google's proxy fetches them from the sender's server. The effects, confirmed by Litmus's page on the limitations of its analytics:

• The IP address and geolocation are hidden. Pixel requests come from the IP addresses of Google's proxy, and device details are reduced to the proxy's user-agent string.
• Caching suppresses repeat opens. Once an image is cached, later views may be served without fetching it again from the sender, so repeat opens are undercounted. Litmus reports these as "image cache opens" and excludes them from its reports of engagement (reading time), because "engagement is also masked by the providers' processes."
• Yahoo and AOL run an equivalent proxy and cache. Litmus notes that since August 2018 "both Yahoo! Mail and AOL are processed by the same backend servers", and that the two cannot be told apart ("Yahoo/AOL Mail via Yahoo/AOL's Image Cache").
• Unlike Apple MPP, the Gmail proxy has historically fetched images when the message is viewed, so an open through the Gmail proxy still indicates that a person opened the message. It distorts who opened it, where and on what device, but not whether it was opened. (Gmail has at times fetched images in advance for some messages, so treat Gmail opens as mostly human but not guaranteed.)

What analytics vendors themselves admit (Litmus)

Litmus documents the limits of its own Email Analytics. That documentation is a useful, honest baseline for what analytics based on pixels can and cannot claim:

• It cannot track recipients with images turned off or text-only clients. Its analytics are "a way to break down your open rate", in other words a view of the recipients who opened, and only of them.
• No reliable data on forwarding or printing remains for any inbox provider (Litmus dropped it for reasons of privacy and accuracy).
• Apple MPP and provider image caches get their own caveats. The opens they affect are separated out or excluded from engagement reports.
• Webmail (Gmail, Outlook.com, Yahoo, AOL) loads content asynchronously and keeps fetching after the reader has moved on, so tracking of reading time and engagement is excluded for all webmail. Clients that cannot be tracked export a reading time of -1.
• Identification of the client is coarse. All modern Windows versions of Outlook (2016+) "return the same identifiers". Outlook for Mac renders with WebKit and is reported as Apple Mail. Lotus Notes cannot be tracked.
• Pixel hits from ESP previews, from campaign pages that have been shared or posted, and from reused tracking codes all count as opens unless they are removed before sending.

If a specialist analytics vendor documents this much noise, an ESP's raw open metric carries at least as much, plus the inflation from MPP's advance fetching.

Operational consequences

Which metrics you can still trust

The overall open rate keeps one legitimate use: a sudden drop still signals a delivery problem. Even opens from advance fetching require the message to reach the mailbox, so for recipients at Apple, MPP opens act in effect as a measure of inbox placement.

Adjusting sunset policies for opens inflated by MPP

The classic rule, "suppress after N months without an open", now fails in both directions. MPP users look engaged forever, so they are never sunset and the list decays. Users with images turned off look dormant forever, so engaged readers get removed. Redesign the policy as follows (this extends List Hygiene & Sunset Policies):

1. Group recipients by how far their opens can be trusted, using the user agent and IP address of pixel requests: opens through the MPP proxy, opens from provider caches, and direct opens.
2. For recipients affected by MPP, define inactivity by clicks, conversions, site logins and purchases, never by opens. Lengthen the lookback period to match, since clicks are rarer than opens. A 90-day rule based on opens might become a 180–365-day rule based on clicks and conversions.
3. For recipients whose direct opens can be trusted, opens may still count, with less weight than clicks.
4. Keep the check against activity outside email (visits to the website, purchases). It is now the main signal, not a fallback.
5. Do not let bot clicks trigger re-engagement, so that a detonation by Safe Links does not "rescue" a dead address. In the same way, never count a scanner's GET on the confirmation link of a win-back campaign as consent.

The same correction applies to warm-up segments. The "most engaged" segments built for IP warm-up should be ranked by how recently recipients clicked or converted, not by opens, or they will be filled with unengaged Apple users.

Optimizing send times and content

• Models that optimize send times and are trained on open timestamps are polluted by the schedules of advance fetching. Train them on click timestamps only.
• Live or dynamic content (countdown timers, images personalized by location) is rendered when Apple fetches it in advance or when Google's proxy fetches it. Design the content so that the version rendered at the time of the advance fetch is still acceptable.
• A/B tests judged on opens mostly measure noise for recipients at Apple. Judge subject-line tests on clicks and conversions, or limit the reading of opens to opens that did not pass through a proxy.

Related articles

• Metrics and Benchmarks, with the thresholds that these caveats qualify
• List Hygiene and Sunset Policies
• List-Unsubscribe & One-Click, including why one-click unsubscribe uses POST
• Content & Design for Deliverability, including the reputation of tracking domains
• Seven-Step Delivery Model