Answer First
Definition: Email client link rewriting is a security behavior in which a mail provider replaces the URL in a delivered message with a rewritten link on its own domain — Gmail routes clicks through www.google.com/url, and Outlook Safe Links wraps them under safelinks.protection.outlook.com — so the destination can be scanned before the reader is sent onward. Your branded entry link is still embedded inside the wrapper; it just gains a redirect layer in front of it.
Why: The wrapper sits between the reader and your entry, so what your entry records is no longer a plain browser click: scanners pre-fetch URLs and inflate click counts, the referrer arrives from the proxy rather than a direct click, and divergence between email-platform reports and entry logs is infrastructure behavior, not a defect. Understanding email client link rewriting is the difference between chasing phantom discrepancies and reconciling numbers you can trust.
Example: You send a campaign entry at go.example.com/summer-sale. To a Gmail recipient, the link arrives as https://www.google.com/url?q=https%3A%2F%2Fgo.example.com%2Fsummer-sale.... In a Microsoft 365 organization, the same link arrives wrapped as https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.example.com%2Fsummer-sale.... Only after the wrapper’s check does the reader’s browser actually request your entry.
Key Facts
- Gmail rewrites message links to a Google-controlled URL (
google.com/url); Outlook and Defender for Office 365 wrap them using the standardsafelinks.protection.outlook.comprefix. - Rewriting is decided by the recipient’s mail infrastructure, not by you. You cannot opt a link out from the sender side.
- Wrappers scan URLs before delivery and re-check them at click time; scanning can fetch your URL in the background, generating requests that are not human clicks.
- The reader’s browser still reaches your entry — after one extra redirect hop — but the referrer and metadata it carries come from the proxy layer.
- Query parameters usually survive wrapping because the full target URL is embedded, but downstream sanitizers can strip them, and referrer fidelity is not guaranteed.
- Safe Links rewrites per recipient, including on forwards and replies, and offers admin controls such as “Do not rewrite the following URLs” lists — but those controls belong to the recipient’s organization.
- The result: entry access statistics and logs mix scanner fetches with real arrivals, so raw totals will not match email-platform click reports — expect the gap.
Expert Explanation
What Gmail actually does
Gmail applies link protection to stored messages: links are rewritten so that a click first hits a Google-controlled URL with the original destination encoded as a parameter, most commonly https://www.google.com/url?q=<encoded-url>&sa=D.... Google’s infrastructure checks the destination against known-malicious lists before issuing the redirect that sends the browser to your entry. Because the rewriting is applied to the stored message, it appears regardless of which email client the recipient uses.
What Outlook Safe Links actually does
Microsoft’s Safe Links, part of Defender for Office 365, documents its mechanics explicitly: “Scanned URLs are rewritten or wrapped using the Microsoft standard URL prefix: https://<DataCenterLocation>.safelinks.protection.outlook.com.” Wrapping happens during mail flow, per recipient, and is reapplied when a message is forwarded or replied to. When the reader clicks, Safe Links checks the URL at time of click and only then redirects to the target. The same documentation notes URLs are scanned prior to delivery and that URLs without a valid reputation can be detonated asynchronously in the background — a fetch of your URL that never involves a human.
The hidden redirect layer in front of your entry
Whether the wrapper is Google’s or Microsoft’s, the reader’s browser now traverses: wrapper URL → your entry → final destination. Every redirect costs an extra HTTP round trip, as MDN’s guide to HTTP redirections notes, and browsers follow the chain transparently. But your entry, which typically responds with a 301 or 302 redirect, sits in the middle of that chain, and its logs record the middle hop. When you later ask “why does the entry log show a request from this reader with a google.com referrer?”, the answer is this layer: the request your entry receives is the tail end of a proxy-mediated click, not a direct hit.
Why pre-fetching inflates click counts
The same security machinery that protects the reader also touches your URL: pre-delivery scanning, reputation checks, and background detonation all fetch the destination — including your entry — before any human clicks. Link-unfurlers and preview services add more. Every one of these lands in your entry’s access statistics as a click, even though no reader was involved — which is why a campaign reporting 5,000 clicks in the email platform can show noticeably more requests in the entry’s logs. The two systems count different events, and yours includes non-human traffic by design.
What happens to referrers and query parameters
The referrer your entry sees changes. Instead of arriving from the campaign page or another referring site, the browser arrives with a referrer from the wrapper domain (https://www.google.com/ or the safelinks.protection.outlook.com host) — or no referrer at all, depending on referrer policy. Query parameters are more resilient: Gmail and Safe Links both embed the complete target URL, query string included, so UTM parameters usually survive the wrapper. The risk is downstream — additional link sanitizers or security pipelines in the recipient’s environment may strip or reorder known tracking parameters. The reliable posture is: expect the entry link and its parameters to survive the wrapper, verify it in a test message, and never gate campaign logic on exact referrer strings.
Gmail vs Outlook at a glance
| Behavior | Gmail link protection | Outlook Safe Links |
|---|---|---|
| Wrapper domain | www.google.com/url | <datacenter>.safelinks.protection.outlook.com |
| When applied | On the stored message, per recipient environment | During mail flow, per recipient, including forwards and replies |
| Scanning | Before delivery and at click | Before delivery, at click, plus background detonation for unknown URLs |
| After the check | Browser redirected to the original URL (your entry) | Browser redirected to the original URL (your entry) |
| Admin opt-outs | Controlled by the recipient org’s Google admin | ”Do not rewrite” lists and click-tracking settings controlled by the recipient org’s Microsoft admin |
| Typical effect on entry logs | Extra scanner requests, proxy referrer | Extra scanner requests, proxy referrer, per-recipient rewrites |
Decision Framework
Verify a managed entry survives rewriting
Work through this checklist after each major send:
- Open a test message’s source (or inspect the hover target) and confirm the wrapper domain; decode the wrapped URL and confirm your entry link is embedded with its query parameters intact.
- Click through in a controlled test and confirm the chain wrapper → entry → destination, and that the entry returns the status you configured (for example, 301 or 302).
- In the PushULink Console or via the OpenAPI, check the entry’s status and access statistics for the send window; look for request bursts at odd hours or scanner-like user agents.
- Cross-check email-platform click counts against entry statistics per send, using time windows and deduplication (same entry, same minute, same request pattern) rather than raw totals.
- Confirm the wrapper still lands on the approved destination — the same discipline you’d apply when the ad is approved but the landing page changes.
- Record the baseline. Because every change to an entry is traceable, later policy shifts at recipient providers show up in your logs as explainable anomalies instead of mystery data.
Practical limits
You cannot prevent rewriting — it is a property of the recipient’s infrastructure, and any admin exemption (such as a Safe Links “do not rewrite” list) belongs to the recipient’s organization, not to you. Scanner requests will always be mixed into entry logs; you can identify and discount them, not eliminate them. Referrer and query-parameter fidelity is best-effort, so don’t gate campaigns on exact referrer strings or on every parameter surviving every sanitizer. Finally, behavior varies by client and policy: consumer Gmail, Workspace, Outlook desktop, Outlook on the web, and third-party clients each handle wrappers slightly differently, so verify in the environment your audience actually uses.
Reconcile email clicks against entry logs
The gap direction is predictable: entry statistics run at or above the email platform’s click count, because the platform counts the click on the wrapper while your entry also records scanner fetches, retries, and preview requests. Establish an expected band per campaign type and treat differences inside it as normal. If the numbers diverge badly, check the entry first — status, statistics, logs — before touching the campaign, exactly as you would when ads get clicks but no conversions. Keep the log evidence organized: a traceable record of what each request was and when it arrived is the evidence trail compliance audits expect you to produce.
Key Takeaways
- Email client link rewriting is stable, documented infrastructure behavior; design for it rather than fighting it.
- Gmail and Outlook both interpose a proxy hop, so your entry’s logs always include non-human traffic.
- The wrapper preserves your entry link; verify occasionally that the full chain still lands on the approved destination.
- Reconcile email clicks against entry logs by time window and deduplication, and expect entry counts to run higher.
- If numbers diverge badly, check the entry first — status, statistics, logs — before touching the campaign.
FAQ
Q: Does Gmail or Outlook rewriting break my branded entry link?
A: No. The wrapper encodes the full destination URL — including your entry link and its query parameters — and the reader’s browser is redirected through your entry as normal after the check. What changes is the request’s metadata (referrer, sometimes user agent) and the extra requests from scanning, not the entry’s ability to resolve and redirect.
Q: Why are my entry click counts higher than my email platform’s click report?
A: Because the two numbers measure different events. The email platform counts clicks on the wrapper; your entry logs every request it receives, including scanner pre-fetches, background reputation checks, link-unfurl previews, and retries. Expect entry counts at or above email clicks, and dedupe by time window and request pattern before comparing.
Q: Can I stop my links from being rewritten?
A: Not from the sender side. Rewriting is controlled by the recipient’s mail provider and the recipient organization’s administrators (for example, Microsoft’s Safe Links “do not rewrite” lists). Even a recipient-side exemption is not something you can rely on, so the practical answer is to plan for rewriting, verify your entry survives it, and reconcile your numbers.
Q: Will my UTM or tracking parameters survive the rewrite?
A: Usually yes for Gmail and Safe Links, because the wrapper embeds the complete target URL, query string included. The risk is downstream: link sanitizers or security pipelines may strip or reorder known tracking parameters, and referrers are not preserved as direct clicks. Verify the embedded URL in a test message and don’t make campaigns depend on exact parameter fidelity.
Sources
- Microsoft Learn — Complete Safe Links overview for Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/safe-links
- MDN Web Docs — Redirections in HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- RFC 9110 — HTTP Semantics (redirect status codes and the Referer field): https://www.rfc-editor.org/rfc/rfc9110