Email Clients Rewrite Campaign Links: What Your Entry Click Stats Are Actually Counting

Answer First

Definition: Email click tracking links rewritten by email clients is what happens when a mail provider or security layer replaces the campaign URL your team built — the branded entry link — with a proxy or wrapper URL before the recipient’s browser ever reaches it. The recipient still lands on your page, but the request your entry logs actually record arrives from a third-party domain: Apple’s privacy proxy, Microsoft’s SafeLinks wrapper, or Google’s redirect service.

Why: These rewrites exist for reasons entirely outside your campaign: Apple Mail Privacy Protection hides the recipient’s IP and preloads message content in the background; Microsoft Safe Links scans URLs at click time to block phishing; Gmail routes links through a URL redirect so it can check them against Safe Browsing before you land. All three are correct, user-protecting behavior — and all three distort what a naive reading of entry click stats shows you: clicks that arrive from proxy domains, user agents that aren’t real browsers, referrers that are stripped or replaced, and totals that never match your email platform’s click count.

Example: You send a campaign pointing to go.yourbrand.com/summer-sale. A subscriber on an iPhone with Mail Privacy Protection enabled gets the message. Within minutes of delivery — before the person has opened the email or tapped anything — your entry’s access log shows a request for /summer-sale with no referrer, coming from an Apple-owned IP range. Your stats page shows a “click.” No human clicked. That is not a bug in your entry; it is Apple’s proxy doing its job.

Key Facts

• There are three mainstream rewrite mechanisms: Apple Mail Privacy Protection (per-device, opt-in via “Protect Mail Activity”), Microsoft Safe Links (organization-level, part of Defender for Office 365), and Gmail/Google click-wrapping (Google infrastructure, applied to messages in Gmail).
• All three operate before the click reaches your entry, so the entry only ever sees the tail end of a longer redirect chain — a chain you don’t control and may not even see.
• What gets distorted in entry-level stats: referrer (absent or replaced with a proxy domain), user agent (proxy signature instead of the recipient’s browser), origin (data-center IP ranges instead of consumer ISPs), and counts (fetches that never involved a human).
• Divergence between your email platform’s click count and your entry’s access count is expected, not evidence of failure — the two systems count different events.
• Practical limits of this guide: no single log field proves a click is “real” — only a combination of signals does, and those signals change when Apple, Microsoft, or Google update their clients, which happens without notice. Prefetch behavior varies by OS version and client. And recipient-side rewriting cannot be disabled by a sender, so the goal is interpretation, not prevention. This article covers the mechanisms and the log signatures they produce — it does not promise a way to make proxy fetches disappear.

Expert Explanation

A campaign click normally follows a chain of HTTP redirects: your email platform’s link → your entry (go.yourbrand.com/summer-sale) → the landing page. The redirect your entry performs is the hop you control, and how you configure it (301 vs. 302) matters for what downstream analytics record — a distinction covered in our guide to 301 vs. 302 redirects for campaign entries. What the three email-client mechanisms change is everything before that hop.

Apple Mail Privacy Protection’s tracking proxy

Mail Privacy Protection (available since iOS 15 and macOS Monterey, under “Protect Mail Activity”) works in two parts. First, it hides the recipient’s IP address from senders. Second, it downloads remote message content privately in the background when the message is delivered, rather than when it is viewed — Apple’s own documentation describes exactly this: “your IP address is hidden from senders and remote content is privately downloaded in the background when you receive a message.”

The practical consequence: for a subscriber with MPP enabled, Apple’s proxy fetches the remote content of your email — images, tracking pixels, and the destinations of your links — through Apple’s infrastructure shortly after delivery. Your entry therefore receives one or more requests that:

• originate from Apple’s IP ranges rather than a consumer ISP,
• carry no referrer (there is no browsing session behind the fetch),
• arrive in a burst minutes after the send, before any human could reasonably have clicked,
• and repeat later if the user actually taps the link (the real click fetches the content again, this time through the proxy as well, so you cannot tell them apart by origin alone).

Microsoft Outlook SafeLinks (Defender for Office 365)

Safe Links is a security feature of Microsoft Defender for Office 365, applied by the recipient’s organization during mail flow. Incoming messages have URLs rewritten to Microsoft’s wrapper prefix — https://<datacenter>.safelinks.protection.outlook.com/?url=<your-encoded-url> — and when the recipient clicks, the wrapper scans the URL against threat intelligence before redirecting to the real destination. Microsoft’s documentation states it plainly: “Scanned URLs are rewritten or wrapped using the Microsoft standard URL prefix,” and a clicked rewritten link is “scanned for malicious content before directing the user to the page.”

The log signature at your entry: the request arrives with the recipient’s real browser user agent, but the referrer is Microsoft’s safelinks domain, and the request only appears after SafeLinks resolves. Two extra wrinkles: rewriting is per-recipient and persists across forwards, and Microsoft itself stores click data when “Track user clicks” is enabled — so one human click can be counted by Microsoft, by your email platform, and by your entry, in three separate places with three different definitions of “click.”

Gmail / Google click-wrapping

Gmail has wrapped links in received messages for years, routing them through a Google URL redirect (google.com/url?... with your URL as a query parameter) so Google can check the destination before the user lands. When a Gmail user clicks your campaign link, the request your entry sees comes through Google’s redirect chain with google.com as the referrer — your landing analytics will show referral traffic from Google rather than from your email platform or the recipient’s context.

What each mechanism looks like in your entry logs

Mechanism	Rewrite happens	Request your entry sees	Referrer in logs	User agent in logs
Apple Mail Privacy Protection	Background proxy fetch at delivery + on click	Full request, often in a burst right after send	Absent (stripped)	Apple/proxy signature; Apple IP ranges
Microsoft Safe Links	Recipient org’s mail flow, per message	One request after the wrapper scans and redirects	safelinks.protection.outlook.com	Recipient’s real browser
Gmail click-wrapping	Google infrastructure, per message	Request via Google’s redirect chain	google.com	Recipient’s real browser

What this does to entry-level access statistics

Take all three together and the aggregate effects on the numbers in your entry’s access statistics are consistent: an inflated share of arrivals from proxy domains, user agents that cluster on a handful of data-center fingerprints, referrers that are missing or belong to Apple/Microsoft/Google instead of your campaign context, and a total request count that runs ahead of the email platform’s click count. None of this indicates your entry is misconfigured — it indicates the requests were rewritten upstream, which is the normal state of email on the modern internet.

Decision Framework

Use this checklist when a log entry makes you pause. No single item is conclusive; treat the pattern, not the field.

• Referrer: is it your expected source, a known proxy domain (safelinks.protection.outlook.com, google.com), or missing entirely? Missing or proxied is the norm for rewritten links, not a red flag.
• User agent: is it a mainstream browser fingerprint, or an Apple/proxy-style signature? A proxy UA with no referrer from Apple IP space is a prefetch pattern.
• Timing: did the request land within minutes of the send, clustered with other requests? Prefetches cluster at delivery. Real clicks spread over the campaign lifetime — a click three days after send is almost certainly human.
• Origin: consumer ISP ranges suggest a person; concentrated data-center ranges suggest a proxy. (Practical caveat: some corporate and privacy networks also proxy outbound traffic, so don’t treat any single range as definitive.)
• Redirect chain: the entry is the final hop; the wrapper hops precede it. If the request came via a wrapper URL, the click was scanned or rewrapped upstream — still a legitimate arrival.
• Cross-check with the platform: compare against your email platform’s own click data. Divergence is expected; a gap that grows or shrinks overnight while the entry’s status and destination stayed unchanged is the anomaly worth investigating.
• Change log: before explaining a count shift, confirm nothing changed on your side. The entry change log records status and destination edits — a destination change mid-campaign splits your counts across two configurations, and forgetting that produces phantom “drops.” This is the same evidence trail compliance auditors rely on, as covered in how entry management supports compliance audits.

When your platform reports clicks and your entry stats do not agree, resist the instinct to call it broken. The two systems measure different events: the platform counts clicks inside its tracking ecosystem (often deduplicated), while your entry counts every HTTP request it receives. Use the two numbers the way they were meant to be used — the platform’s count as the marketing signal, your entry’s access stats as the infrastructure signal. The same discipline applies when clicks exist but conversions do not: the mismatch is usually upstream, and checking the campaign entry before rewriting the ads is the right first move. If you do change a destination mid-campaign, remember the impact is traceable — the change-log pattern from our ad-landing-page article applies to entries too. And if you need to verify what a rewritten link actually does before a campaign ships, testing from a clean, isolated device — the approach in our cloud phone tutorial — shows you the exact request your entry will receive.

Key Takeaways

• Apple MPP, Microsoft SafeLinks, and Gmail all rewrite campaign links before the click reaches your entry, and each leaves a distinct signature in your logs.
• Proxy prefetches inflate entry counts, strip referrers, and arrive in delivery-time bursts — they are real HTTP requests, not fake data, but they are not human clicks.
• Tell a real click from a prefetch by combining referrer, user agent, timing, and origin — never by one field alone.
• Entry access counts and email-platform click counts measure different events; divergence is normal and does not mean anything is broken.
• Your entry’s status, access statistics, logs, and change history are the tools that make this interpretable — check the change log before blaming the numbers, and keep the evidence when you need to explain a campaign later.

FAQ

Does Apple Mail Privacy Protection click every link in my email? It can fetch every link destination in a message, yes. When Mail Privacy Protection (Protect Mail Activity) is on, Apple’s proxy downloads the message’s remote content — images, pixels, and linked pages — in the background when the message is delivered, before you open or click anything. That means your entry can receive a request with no human behind it. It is not an interactive click, but it is a real HTTP request, and your access logs will record it as one.

Are SafeLinks-wrapped clicks real people? Usually, yes — with an extra hop. Safe Links rewrites the URL to a safelinks.protection.outlook.com address and, at click time, scans it before redirecting to your entry. So a human click does reach your entry, but the referrer will be Microsoft’s wrapper domain and the request arrives only after the scan resolves. The count itself is a genuine click; it just has a proxy signature.

Why do my email platform’s click counts differ from my entry’s access stats? Because they measure different events. Your email platform typically counts clicks through its own pixel or proxy and may deduplicate or filter proxy behavior; your entry’s access statistics count every HTTP request that hits the entry, including prefetches, wrapper redirects, and repeat visits. The two systems are not broken — they are measuring different things. The gap is expected and is a signal to investigate, not a bug.

Can I stop email clients from rewriting my links? Not from your side. Apple Mail Privacy Protection is a per-user setting on the recipient’s device, Safe Links rewriting is controlled by the recipient organization’s Microsoft 365 security policies, and Gmail rewrites links on Google’s infrastructure. What you can do is log the evidence: keep entry logs, watch referrer and user agent signatures, and use the entry change log to rule out entry-side changes when counts shift.

Sources

• Apple Support — “Protect email privacy in Mail on Mac” (Mail Privacy Protection) — describes IP hiding and background download of remote content at message receipt.
• Microsoft Learn — “Safe Links in Microsoft Defender for Office 365” — describes URL rewriting to safelinks.protection.outlook.com, time-of-click scanning, rewriting per recipient, and click tracking.
• MDN — “Redirections in HTTP” — explains 3xx redirects, the Location header, and redirect chains, the hops that wrapper URLs introduce.
• IETF — RFC 9110, “HTTP Semantics” — defines the 3xx redirection status codes and the Referer header field that determine what a destination server can observe.