Tracking and Measurement Distortion

Every engagement-based deliverability practice — sunset policies, warm-up segments built on "recent openers," open-rate benchmarks — rests on two tracking mechanisms that privacy features and security scanners now systematically distort. This article explains how the tracking works, catalogs each distortion source, and states which metrics an operator can still trust.

Provenance: the three Litmus help-center articles cited moved to a JavaScript-only Validity knowledge base (knowledge.validity.com) that cannot be fetched statically; content here is from Wayback Machine snapshots of the original help.litmus.com pages (captures 2024-09-16, 2024-12-11, and 2025-02-13; in-page "last updated" dates 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, with a per-recipient unique URL on the sender's or ESP's tracking domain. When the mail client renders the message and fetches remote images, the pixel request hits the tracking server, which logs an "open" along with the requesting IP, user agent, and timestamp. Litmus describes its own analytics identically: "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."

Structural consequences, before any privacy feature is considered:

• No image load → no open recorded. Clients with images disabled, plain-text rendering, or text-only clients produce false negatives. An "open rate" is really a pixel-load rate.
• Every image load → an open recorded, including the sender previewing the campaign in the ESP or a browser, the message being posted to a website or social media, or a tracking code reused across templates (all documented Litmus failure modes).
• Total vs unique: raw pixel hits are total opens; ESPs dedupe to unique opens per recipient because they hold the subscriber mapping.
• ESPs already filter obvious machine loads: Litmus notes 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 to point at the sender's/ESP's redirect (tracking) domain with an encoded identifier; the redirect server logs the hit and issues an HTTP redirect to the original destination. As Litmus puts it: 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 (it must rewrite links at send time), which is why analytics-only tools like Litmus do not offer click tracking.

The tracking domain itself carries reputation: URL blocklists and content filters evaluate the redirect domain in the body, so a shared tracking domain spreads reputation across every sender using it (see Content & Design).

Distortion source 1: Apple Mail Privacy Protection (MPP)

Introduced with iOS 15 / macOS Monterey (2021). Available in Apple Mail on iOS, iPadOS, visionOS, macOS, and iCloud.com — it applies to any mailbox read through Apple Mail clients, not just @icloud.com addresses.

What Apple's own documentation says it does

From Apple's legal/privacy page:

• Remote content is downloaded "in the background by default — regardless of whether you engage with the email." The pixel fires on receipt-side prefetch, not on human viewing.
• Downloads route 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 an Apple proxy IP, not the recipient's.
• Purpose as stated: 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 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 off, two independent options appear: Hide IP Address (IP masking without prefetch) and Block All Remote Content (no remote loads at all; the user sees a banner and can load content manually).
• Per the legal page, Hide IP Address "will still mask your IP address" even when MPP itself is disabled.

The feature is presented at first launch and is opt-out; adoption among Apple Mail users is near-universal in practice. Setting paths: iOS/iPadOS/visionOS Settings > Apps > Mail > Privacy Protection; Mac Mail > Settings > Privacy; iCloud.com Settings > Privacy & Security.

What this does to sender data

Signal	Effect under MPP
Open event	Fired for ~every delivered message to an Apple Mail user, engaged or not — false positives at scale
Open timestamp	Reflects Apple's prefetch schedule, not reading time; useless for send-time optimization on this segment
Open count / re-opens	Suppressed; multiple human views are not distinguishable
Recipient IP	Replaced by Apple relay egress IP — geolocation resolves to Apple infrastructure, roughly regional at best
Device / client fingerprint	Masked; the proxy fetch does not reveal the real client details
Live content (countdown timers, geo-targeted images)	Rendered at prefetch time/location, not at view time

Caveats operators should know: prefetch is not perfectly guaranteed for every message (devices must be on power/network for background activity), so MPP opens are close to — but not exactly — 100% of delivered volume to that segment. Identify MPP opens in event data by the Apple proxy user-agent and Apple-owned IP ranges on pixel requests.

MPP does not touch clicks: a click still comes from the real user action (though the IP on the subsequent landing-page visit may be masked by iCloud Private Relay for Safari users, the click event itself is genuine).

Distortion source 2: Microsoft Safe Links (click-side)

Safe Links is Microsoft Defender for Office 365's URL protection. It matters to senders because it both rewrites their links and generates non-human fetches of them.

Mechanics, from Microsoft's Safe Links policy documentation:

• Coverage is default-on: although there is no default Safe Links policy object, 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 SKUs). Standard/Strict presets and custom policies layer on top; 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 at *.safelinks.protection.outlook.com with the original URL encoded as a parameter, enabling time-of-click verification. Every click bounces through Microsoft before reaching the sender's tracking redirect.
• Real-time scanning / detonation: the option "Apply real-time URL scanning for suspicious links and links that point to files" (ScanUrls) triggers scanning of linked content, with "Wait for URL scanning to complete before delivering the message" (DeliverMessageAfterScan, recommended On) holding delivery until scans finish. These scans fetch the sender's URLs from Microsoft infrastructure — each fetch of a wrapped tracking link registers at the ESP as a "click" that no human made, typically seconds after delivery.
• API-only mode: "Do not rewrite URLs, do checks via SafeLinks API only" leaves URLs intact in the body; supported Outlook clients call Safe Links at click time instead. Under this mode sender links are not visually rewritten but time-of-click checks still occur.
• Do-not-rewrite lists: admins can exempt URLs (DoNotRewriteUrls) from wrapping during mail flow, but Microsoft notes exempted URLs "might still be blocked at time of click" unless also allowed in the Tenant Allow/Block List.
• Click telemetry: "Track user clicks" (TrackUserClicks) defaults to on; blocked-URL warning pages can prevent click-through entirely (AllowClickThrough $false), meaning a genuine user click on a falsely-flagged tracking domain never reaches the sender at all — a false-negative click path that pairs with the detonation false positives.

Senders see the effects most heavily on B2B lists (Microsoft 365 tenants). Corporate recipients behind Strict-preset policies produce the most aggressive pre-delivery link fetching.

Distortion source 3: other gateway and security scanners

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

• Fetch every link in a message at or shortly after delivery to check destinations ("link detonation" / sandboxing) — including the unsubscribe link, which is why RFC 8058 one-click unsubscribe uses POST rather than GET (see List-Unsubscribe): scanners issue GETs, so a GET-actioned unsubscribe gets triggered by robots.
• Rewrite links through their own redirectors (e.g., urldefense.com, Mimecast link protection), adding a second redirect hop in front of the ESP's tracking redirect.
• Fetch the tracking pixel during content scanning, producing scanner "opens" from datacenter IPs.

Behavioral signatures that distinguish scanner clicks from human clicks:

Heuristic	Scanner/bot pattern	Human pattern
Timing after delivery	Seconds to ~2 minutes after SMTP accept, often before any open	Minutes to days later, usually after an open
Coverage	Every (or nearly every) link in the message clicked, including unsubscribe and footer links	One or a few content links
Ordering	Links hit in DOM order, near-simultaneously	Irregular, single
Source IP	Datacenter / security-vendor ASN (Microsoft, Proofpoint, Barracuda ranges), often one IP clicking across many recipients	Residential/mobile ISP or corporate egress of the recipient
User agent	Headless/generic agents, or agents inconsistent with the open's client	Consistent browser/device agents
Post-click behavior	No landing-page session, no subsequent page views	Normal web session

Operational bot-click filtering: score events against several of these heuristics rather than any single one (some scanners click only a random subset of links, and some corporate egress IPs serve both scanners and humans). Never fire irreversible actions — unsubscribe, preference change, one-click purchase — on a bare GET.

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

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 from the sender's server. Effects, corroborated by Litmus's analytics limitations page:

• IP and geolocation masked: pixel requests come from Google proxy IPs; device detail is reduced to the proxy's user-agent string.
• Caching suppresses repeat opens: once cached, subsequent views may be served without re-fetching from the sender, undercounting re-opens. Litmus reports these as "image cache opens" and excludes them from engagement (read-time) reporting because "engagement is also masked by the providers' processes."
• Yahoo and AOL run an equivalent proxy/cache; Litmus notes that since August 2018 "both Yahoo! Mail and AOL are processed by the same backend servers" and are indistinguishable ("Yahoo/AOL Mail via Yahoo/AOL's Image Cache").
• Unlike Apple MPP, the Gmail proxy fetch historically occurs at view time, so a Gmail proxied open still indicates a human open — it distorts who/where/what device, not whether. (Gmail has at times prefetched images for some messages; treat Gmail opens as directionally human but not guaranteed.)

What analytics vendors themselves concede (Litmus)

Litmus's own documentation of its Email Analytics limits is a useful honest baseline for what pixel analytics can and cannot claim:

• No tracking of recipients with images disabled or text-only clients; analytics is "a way to break down your open rate," i.e., a lens on the openers only.
• No reliable forward or print data for any inbox provider anymore (dropped for privacy and accuracy).
• Apple MPP and provider image caches get dedicated caveats; affected opens are segregated or excluded from engagement reports.
• Webmail (Gmail, Outlook.com, Yahoo, AOL) uses asynchronous loading that keeps fetching after the reader moves on, so read-time/engagement tracking is excluded for all webmail; untrackable clients export a read time of -1.
• Client identification is coarse: all modern Windows Outlook versions (2016+) "return the same identifiers"; Outlook for Mac renders via WebKit and reports as Apple Mail; Lotus Notes is untrackable.
• Pixel hits from ESP previews, shared/posted campaign pages, and reused tracking codes all count as opens unless purged before send.

If a dedicated analytics vendor documents this much noise, an ESP's raw open metric carries at least the same noise plus MPP prefetch inflation.

Operational consequences

Which metrics remain trustworthy

Metric	Trust level	Notes
Delivered / bounce rates	High	SMTP-level, unaffected by tracking distortion
Spam complaint rate	High	FBL-based; a genuine human negative signal
Unsubscribe (POST one-click)	High	RFC 8058 POST resists scanner GETs
Conversions / on-site activity	High	Requires a real session; the strongest positive signal
Clicks (bot-filtered)	Medium-high	Genuine after filtering scanner patterns above
Clicks (raw)	Medium	Inflated by Safe Links/gateway detonation, esp. on B2B
Opens, aggregate trend	Medium-low	Still usable for relative comparison within a stable audience mix (MPP inflation is roughly constant across campaigns)
Opens, individual-level	Low	An "open" from an Apple Mail user proves delivery, not attention
Open timestamps, geo, device	Low	Proxied/prefetched for Apple, Gmail, Yahoo/AOL segments

Aggregate open rate retains one legitimate use: a sudden drop still signals a delivery problem (even prefetch opens require the message to reach the mailbox — MPP opens are effectively an inbox-placement proxy for the Apple segment).

Adjusting sunset policies for MPP-inflated opens

The classic rule "suppress after N months without an open" is now broken in both directions: MPP users look permanently engaged (never sunset, list rots), while images-off users look permanently dormant (engaged readers get purged). Redesign (extends List Hygiene & Sunset Policies):

1. Segment recipients by open trustworthiness using pixel user-agent/IP: MPP-proxy opens, provider-cache opens, direct opens.
2. For MPP-affected recipients, define inactivity by clicks, conversions, site logins, purchases — never opens. Lengthen the lookback window accordingly (clicks are rarer than opens; a 90-day no-open rule might become a 180–365-day no-click/no-conversion rule).
3. For recipients with trustworthy direct opens, opens may still contribute, weighted below clicks.
4. Keep the out-of-band validation step (website/purchase activity) — it is now the primary signal, not a fallback.
5. Exclude bot-filtered clicks from re-engagement triggers so a Safe Links detonation doesn't "rescue" a dead address; conversely never count a scanner GET on the win-back confirmation link as consent.

The same correction applies to warm-up segmentation: "most engaged" segments built for IP warm-up should rank by click/conversion recency, not opens, or they will be padded with unengaged Apple users.

Send-time and content optimization

• Send-time optimization models trained on open timestamps are polluted by prefetch schedules; train on click timestamps only.
• Live/dynamic content (countdown timers, geo-personalized images) renders at Apple's prefetch or Google's proxy fetch — design so the prefetch-time render is still acceptable.
• A/B tests judged on opens measure mostly noise for the Apple segment; judge subject-line tests on clicks/conversions or restrict the open-based readout to non-proxied opens.

Related

• Metrics and Benchmarks — thresholds that these caveats qualify
• List Hygiene and Sunset Policies — the sunset workflow adjusted above
• List-Unsubscribe & One-Click — why one-click unsubscribe is POST-based (scanner GETs)
• Content & Design for Deliverability — tracking-domain reputation
• Seven-Step Delivery Model — where measurement sits in the campaign loop