Answer First
Definition: Email link protection rewrites campaign links on the way to the recipient’s inbox. When a mail security product such as Microsoft Safe Links, Proofpoint URL Defense, or Mimecast URL Protect protects a recipient’s mailbox, it replaces the links in your email with wrapped URLs on a vendor-controlled domain before delivery. When the recipient clicks, the click goes to the wrapper first, which checks the link and redirects the browser to the original URL — in your case, your branded subdomain entry.
Why: The rewrite is performed by the recipient’s mail system, not your sending platform, so it is outside your entry’s control — you can’t “fix” it by editing the entry, changing the link, or switching tools. The right response is operational: (1) recognize rewritten links in logs and stats, (2) verify the underlying entry still preserves UTM parameters and redirects correctly, and (3) decide which link to keep stable — treating the managed entry as the durable source of truth that survives vendor changes.
Example: You send https://go.yourbrand.com/summer-launch?utm_source=newsletter&utm_medium=email. A Microsoft 365 recipient with Safe Links enabled receives something like https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.yourbrand.com%2F... — Microsoft’s documented wrapper prefix. The recipient never clicks your domain directly: the wrapper scans the click, then redirects to your entry, which redirects to the landing page. Your entry did nothing wrong, yet the click in your stats did not come from your branded URL.
Key Facts
- The rewrite happens on the recipient’s side at delivery time; the entry and the URL you sent are unchanged.
- Wrapping is per recipient and per policy: different recipients can see different wrappers — or none at all.
- The click path becomes wrapper → entry → landing page: one more hop, usually with a short scan delay, and the referrer you see in analytics is the wrapper domain, not your email program.
- Wrappers normally redirect to the full original URL, UTM parameters included — but verify rather than assume.
- Scanner and prefetch systems can fetch your URL with no human behind it, inflating raw click counts.
- Some tenants check links without rewriting, but you can’t rely on that.
| Vendor | What it does to your email link | What you’ll see in logs and stats |
|---|---|---|
| Microsoft Safe Links | Wraps links behind the documented https://<datacenter>.safelinks.protection.outlook.com prefix | Referrer or clicked URL containing safelinks.protection.outlook.com |
| Proofpoint URL Defense | Routes clicks through a Proofpoint-controlled wrapper before releasing the browser | Referrer or clicked URL on a Proofpoint-controlled host; URL sandboxing in the product |
| Mimecast URL Protect | Scans and rewrites URLs in email; checks clicks before redirecting | Referrer or clicked URL on a Mimecast-controlled host; on-click protection in the pattern |
Exact wrapper hosts vary by region, plan, and tenant policy.
Expert Explanation
What the wrapper actually does
A link rewrite is an HTTP redirect staged in front of your link. The wrapper holds an encoded copy of your full original URL — query string included — and redirects the recipient’s browser to it; your entry then redirects to the landing page, so the click travels two or three hops instead of one. Redirects are routine: RFC 9110 defines the 3xx responses and the Location header that tell the browser where to go next, and MDN’s HTTP redirections guide explains how chains are handled. Each extra hop adds latency and is another place where parameters or timing can differ.
How rewritten links show up in your logs and stats
The first sign is a referrer you don’t recognize. A click that “should” come from your email arrives in your entry’s access statistics and logs with a safelinks.protection.outlook.com-style referrer — the wrapper’s URL, not your newsletter’s domain. That is the fingerprint of a rewritten link.
Two more signatures: timing and bots. Wrapper clicks can arrive in bursts or after a scan delay, and scanners may request your URL with no human behind it, inflating raw click counts. With per-entry access statistics and logs — the evidence trail that also matters for compliance audits — you can segment wrapper and scanner traffic instead of counting it as human clicks. As with any analytics question, check the entry and its data before rewriting the campaign or the ad.
Verify the underlying entry, not the wrapper
The wrapper is out of your control, so spend your effort on the part you do control: the entry. With a test mailbox behind each vendor you care about:
- Send the campaign to a protected test address and click the rewritten link.
- Confirm the landing page loads and the full UTM string arrives.
- Confirm the redirect code matches your intent — see choosing between 301 and 302 for campaign entries.
- Check the entry’s status and logs in your Console to see the click arrive from the wrapper’s referrer.
If UTM parameters are missing or the redirect is wrong, the problem is the entry, not the rewrite.
Why “fixing” is the wrong frame
You can’t make the email show your clean branded link: the wrapper is inserted by the recipient’s security stack and changes with vendor updates, tenant policy, and region. What you can control is the entry — which is exactly why the managed entry is the durable source of truth. It is the one stable object in the chain, as long as you don’t churn it. Repointing entries mid-campaign breaks cached wrappers and produces the dead-link symptoms teams then blame on security software.
Practical limits
- You cannot prevent the rewrite or make a recipient’s vendor honor your preferred wrapper.
- Wrapper behavior is not uniform: per-recipient, per-tenant, and per-region differences mean one send produces several click paths.
- You cannot guarantee UTM preservation across every vendor — only verify the vendors your audience actually uses.
- You cannot shorten the wrapper hop, so keep the rest of the redirect chain minimal.
- Scanner traffic will pollute raw click counts; filtering it is analysis, not a fix for the link.
Decision Framework
Run this checklist when you first notice rewritten links, and again whenever a vendor changes or a campaign reaches a new mail platform:
- Identify wrapper domains in your referrer data and entry logs (start with
safelinks.protection.outlook.comand vendor equivalents). - Test-click from a mailbox behind each vendor and confirm the full UTM string arrives.
- Confirm the entry returns the intended status code and target — the 301 vs 302 question matters here.
- Decide the stable surface: your entry, not the wrapper. Keep the entry’s URL and destination stable for the campaign’s lifetime.
- Record the decision and known wrapper hosts where the team can find them, so the next analyst recognizes the pattern.
- When the landing page has to change, change the entry deliberately and document it — the same discipline as any destination change after the ad is approved.
- Filter known scanner and wrapper traffic when reading click statistics.
The decision is simple once you stop treating the wrapper as the problem: the wrapper is whatever the recipient’s security stack says today; the entry is what you own. Keep the entry stable and verified, let the wrapper change around it, and your links survive vendor overhauls because the source of truth never moved.
Key Takeaways
- A rewritten link is a recipient-side event, not an entry defect — recognize it, don’t chase it.
- Learn the fingerprints: wrapper referrers, encoded URLs, scan delays, and scanner bot traffic in your entry’s access statistics and logs.
- Verify what you can: UTM passthrough, redirect code, and redirect target, tested from mailboxes behind the vendors your audience uses.
- Make the decision explicit: the wrapper is transient; the managed entry is the stable surface and the durable source of truth.
- Because wrapper domains and policies change, an entry you control and can trace — via a Console and OpenAPI, with status and logs — is the only link you can rely on long-term.
FAQ
Q: Why do my branded links show up as safelinks/urldefense-style URLs in recipients’ inboxes, and is my link broken?
A: The recipient’s mail security rewrote the link at delivery time. Your entry and the URL you sent are intact; the recipient simply never clicks your domain directly — the wrapper scans the click and redirects to your original URL. Different recipients may see different wrappers, or none, depending on vendor and policy.
Q: Do rewritten links still carry UTM parameters to my landing page?
A: Usually yes. The wrapper encodes the full original URL, query string included, and redirects to it, so UTM parameters survive the wrapper hop. But behavior varies by vendor and configuration, so don’t assume: test-click from a mailbox behind each vendor and confirm the parameters arrive. Also note that URL fragments (#...) aren’t sent to the server by browsers and can be lost through extra hops.
Q: My click stats show hits from strange hosts and more clicks than expected. Is the rewrite inflating my numbers?
A: Possibly. Link-protection systems may fetch URLs during scanning or prefetching, adding hits no human made, and the referrer on real clicks is the wrapper domain rather than your email program. Segment wrapper and scanner traffic in your entry’s logs, and base decisions on the filtered, human-click view.
Q: Should I change my branded subdomain or repoint the entry to “avoid” the rewrite?
A: No. The rewrite happens on the recipient’s side, so repointing the entry won’t stop it — and changing entries mid-campaign can break cached wrappers and redirect chains, creating the dead links you’re trying to avoid. Treat the entry as the durable source of truth: keep it stable, update it deliberately, and document every change.
Sources
- Microsoft Learn — Complete Safe Links overview for Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/defender-office-365/safe-links-about
- RFC 9110 — HTTP Semantics (3xx responses, Location header): https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs — HTTP Redirections: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- Mimecast — Advanced Email Security: https://www.mimecast.com/products/email-security/
- Proofpoint — Core Email Protection: https://www.proofpoint.com/us/products/email-protection