Answer First
Definition: Email link rewriting — what Microsoft calls Safe Links wrapping, what Gmail does with its URL protection, and what ESPs do with their click trackers — replaces a URL in an email message with a wrapper URL on the scanner’s own domain. When a recipient clicks, the request reaches the wrapper first, the scanner checks the destination, then an HTTP redirect carries the click to the original link. For a campaign entry on your branded subdomain, that means the human click is neither the first nor the only request your entry’s access statistics record.
Why: A security scanner cannot redirect a click before it knows the destination is safe, so it interposes a verification step between the click and your entry. That adds a redirect hop, changes the referrer the destination sees, and produces requests your console counts as clicks even when no person is clicking — delivery-time scans, link previews, and forwarded mail follow the chain too. The result: entry click counts run above the email tool’s count, and “email clicks higher than console clicks” becomes a measurement artifact instead of a campaign verdict.
Example: You send a spring campaign pointing at go.example.com/spring-sale. A recipient on Microsoft 365 with Defender for Office 365 sees the link rewritten to nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.example.com%2Fspring-sale. When they click, the wrapper checks the URL, then 302-redirects to go.example.com, which your PushULink entry forwards to the landing page. Your console records the entry hit — and also the delivery-time scan and any preview or forwarding client that follows the chain. Console clicks can exceed the email tool’s unique click count without any campaign problem.
Key Facts
- Safe Links wraps and scans. Defender for Office 365 rewrites URLs in inbound mail to a Microsoft wrapper, https://
.safelinks.protection.outlook.com, scans URLs at delivery, and checks them again at time of click, then redirects. - Wrapping is the recipient’s policy, not yours. Safe Links applies per recipient-tenant policy — there is no default policy, but the Built-in protection preset covers Defender-licensed recipients, and tenants can disable rewriting with “Do not rewrite” lists or API-only checks. You cannot switch it off from your side.
- Gmail and ESPs wrap too. Gmail routes links through a Google-owned wrapper (google.com/url?q=…) before the destination, and ESP link wrappers (Mailchimp, HubSpot, Klaviyo-style) add their own tracking hop. Some messages end up double-wrapped; Microsoft notes that wrapping a link before Defender processes it can prevent Safe Links from processing it.
- Entry stats count requests, not humans. Your PushULink entry’s access statistics record every HTTP request that reaches the entry: redirected browsers, scanner checks that follow the chain, preview scrapers, forwarded mail.
- Microsoft keeps its own click count. Safe Links’ “Track user clicks” setting stores SafeLinks click data separately — a third number for the same click.
| Rewriter | Message link becomes | Click route | What your entry sees |
|---|---|---|---|
| Microsoft Safe Links | https:// | Wrapper → check → 302 → your entry | Hits referred from the SafeLinks host, plus delivery-time and preview hits |
| Gmail URL protection | https://www.google.com/url?q= | Google wrapper → redirect → your entry | Hits referred from google.com / mail.google.com |
| ESP link wrapper | https:// | ESP tracker → 302 → your entry | Hits referred from the ESP’s tracking domain |
Practical limits. No analytics tool can perfectly separate scanner traffic from human clicks. Not all recipients are wrapped: Safe Links ignores some formats (RTF/TNEF, S/MIME) and respects per-tenant allow lists, so only part of your traffic carries wrapper evidence. Referrers are unreliable too: mobile mail clients and strict Referrer-Policy settings often send none, so a missing wrapper referrer proves nothing. Wrapper hostnames vary by region and change over time — match on the suffix, not the exact host.
Expert Explanation
The request chain after a rewrite
- Delivery-time scan. The message’s URLs are checked for reputation during mail flow; unknown URLs can be detonated in the background depending on policy.
- The click. The recipient clicks the rewritten link; the browser requests the wrapper host.
- Time-of-click verification. The wrapper checks the URL against block lists and reputation data, then responds with an HTTP redirect (typically 302) to the original link.
- Your entry. The browser follows the redirect to your branded entry; the access statistics record a hit, and the entry redirects (301 or 302) to the landing page.
- Previews and forwarding. Outlook link previews, Teams, Slack, LinkedIn unfurlers, and auto-forwarding rules can follow the same chain with no human clicking.
Steps 1, 3, and 5 all have paths into your entry’s statistics — one human click can produce several recorded hits, and some hits correspond to no click.
Why email clicks and console clicks diverge
Email platforms count unique recipient interactions with their own tracking layer, and Microsoft’s “Track user clicks” setting keeps SafeLinks click tracking data separately in the portal. Your console counts every HTTP request the entry receives. The two measure different things by design.
The referrer shifts too. Under HTTP semantics, the Referer header a destination receives identifies the page the request came from — after a rewrite, that is the wrapper host, not your campaign page. Analytics sessions can land as “referral from safelinks.protection.outlook.com” or “google.com” rather than your campaign source. UTM parameters usually survive — the wrapper carries the original URL, query string included — but referrer-based attribution changes.
The divergence can also run the other way. If your entry uses 301 permanent redirects, browsers cache the redirect and repeat clicks can skip the entry entirely, so console counts can run below real clicks — sometimes only the scanner’s verification request is recorded. The 301 vs 302 choice for a campaign entry has real measurement consequences.
Spotting wrapper-originated traffic
- Referrer is the wrapper host: *.safelinks.protection.outlook.com, google.com/url, mail.google.com, or an ESP tracking domain.
- Timing is wrong for humans: hits at delivery time, bursts within the same second (verification plus redirect-following), or traffic outside working hours.
- Requests look mechanical: identical user agents repeating in short windows, no-referrer requests arriving right after a wrapper-referred one, and the same pattern in destination-side logs.
- The message source shows it: the wrapper URL carries your encoded entry in a url= parameter.
Decision Framework
Use this checklist before concluding a campaign underperformed when email clicks run higher than console clicks:
- Align the windows. Compare the email platform’s click metric and the console’s access statistics over the same dates.
- Confirm wrapping happened. Open the message source of a few received copies and look for safelinks.protection.outlook.com or google.com/url wrappers.
- Segment by referrer. Filter console or analytics traffic for wrapper hosts and measure what share of entry hits they explain.
- Check timing. Delivery-time spikes are scanning and preview traffic, not readers.
- Look for duplicate patterns. The same user agent hitting within seconds, or repeated hits from a preview client.
- Test the chain yourself. Send a test message, click from inside the mailbox, and compare with a direct incognito click.
- Check destination-side evidence. Landing-page server logs for the wrapper referrer and repeated fetches.
- Review your entry’s redirect type. A cached 301 makes console counts lower than real clicks, not higher.
- Only then draw a conclusion. If steps 2–7 explain the gap, the campaign may be fine — the console number is a request count, not a unique-human count.
If the numbers still look wrong, the problem may be the entry itself: verify the entry’s status and destination before rewriting the campaign, and check whether the landing page changed after the ad was approved.
Key Takeaways
- A rewritten link means the human click is never the first or only request your entry records.
- Console click counts are request counts; email tools count unique recipient clicks — they measure different things by design.
- Wrapper-originated traffic is identifiable: wrapper-host referrers, delivery-time timing, mechanical patterns, destination-side logs.
- The gap is usually a measurement artifact — diagnose before declaring a campaign underperformed; the entry is often fine and the scanner is doing its job.
- Keep the evidence trail: entries with status, access statistics, logs, and traceable changes are what you need when explaining a click discrepancy to a stakeholder or auditor.
FAQ
Q: Why does my console show more clicks than my email platform reports?
A: Because they count different things. The email platform counts unique recipient clicks on its own tracking layer, and Microsoft’s portal separately stores SafeLinks click tracking data. Your console counts every HTTP request the entry receives: delivery-time scans, verification that follows the redirect, preview clients, forwarded mail. One human click can produce several console hits.
Q: Can I stop Safe Links or Gmail from rewriting my campaign links?
A: Not from your side. Rewriting happens in the recipient’s mailbox or tenant, not yours. Microsoft tenants can configure Safe Links policies — including “Do not rewrite” lists — but you do not control recipients’ tenants, and consumer Gmail wrapping is not something a sender can disable. Plan for the extra hop: keep the entry live, monitor wrapper-referred traffic, and treat console numbers as request counts.
Q: How can I tell a scanner verification request apart from a real click?
A: Look for the wrapper host as referrer, hits arriving at delivery time or in bursts within the same second, repeated identical user agents, and no-referrer requests arriving right after a wrapper-referred one. Destination-side logs usually show the same pattern. No single signal is conclusive — combine them before judging.
Q: Does link wrapping break my campaign attribution?
A: It can shift it. The referrer the landing page sees becomes the wrapper host, so analytics may attribute sessions to a referral from safelinks.protection.outlook.com or google.com instead of your campaign source. URL-based parameters such as UTM tags usually survive because the wrapper preserves the original URL, including its query string — verify with a test click.
Sources
- Microsoft Learn — Safe Links in Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/defender-office-365/safe-links-about
- RFC 9110, HTTP Semantics (redirects and the Referer header): https://www.rfc-editor.org/rfc/rfc9110
- MDN — Redirections in HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- MDN — Referer header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer