Email Security Scanners Are Clicking Your Campaign Links: What SafeLinks Adds to Your Entry Stats

Answer First

Definition: When a recipient clicks a link in a campaign email, the request rarely hits your entry first. Email security gateways — Microsoft Defender for Office 365 Safe Links, Mimecast, Barracuda, Proofpoint — rewrite the URLs in the messages they protect, wrapping each in a gateway-owned prefix such as safelinks.protection.outlook.com, and scan links at click time, detonating unknown URLs in the background. Most ESPs (Klaviyo, HubSpot, Mailchimp, Salesforce Marketing Cloud) add a click-tracking wrapper on top. Your branded link ends up at the tail of a redirect chain you don’t control, and your entry’s access statistics and logs record every request that chain produces — including traffic that was never a human click.

Why: Scanner traffic is indistinguishable from real clicks at the entry level: SafeLinks link clicks arrive as ordinary HTTP GET requests, with no special header or “this was a sandbox” flag. The result: email click counts that exceed opens, access logs full of referrer-less hits and request bursts minutes after send, extra hops in redirect-chain and “link not working” troubleshooting, and stale destinations fetched by scanners as if someone were clicking them.

Example: Your team sends a launch email with the branded link go.acme.com/summer-launch, a PushULink entry. A recipient in a Microsoft 365 tenant with Defender for Office 365 opens the message; in the source code, the link is now https://nam01.safelinks.protection.outlook.com/?url=..., your URL encoded in the query string. When they click, the browser requests the Safe Links URL first; Safe Links checks it, possibly detonates it, and only then redirects to go.acme.com/summer-launch, which 301s to the landing page. Your entry’s access log shows the request; your ESP dashboard counts the click.

Key Facts

• Safe Links scans and rewrites URLs in inbound email during mail flow, then re-verifies them at click time. URLs without a valid reputation are detonated asynchronously in the background — and that detonation is a real HTTP request against the destination.
• Rewritten URLs use the Microsoft standard prefix https://<DataCenterLocation>.safelinks.protection.outlook.com (for example, nam01.safelinks.protection.outlook.com), with the original URL encoded in the query string.
• Rewriting is applied per recipient and persists through forwards and replies. Microsoft also documents that wrapping links with another service before Defender can prevent Safe Links from processing them at all.
• Other gateways do the same: Proofpoint URL Defense wraps links in urldefense.com prefixes, Mimecast uses its protect-*.mimecast.com domains, and Barracuda rewrites with its own link-protection domain.
• Open tracking depends on image pixels, which privacy features and security filters often block, while clicks are counted by wrappers and scanners alike — which is why click counts can exceed opens.

Hop	Owned by	What happens to the request
1. ESP click wrapper	Klaviyo, HubSpot, Mailchimp, Salesforce MC	Encodes the branded link and redirects through the ESP’s tracking domain
2. Gateway rewrite	Safe Links, Proofpoint, Mimecast, Barracuda	Scans at click time; may detonate; redirects to the original URL
3. Your entry	PushULink Console / OpenAPI	Logs the request, records status and access statistics, redirects to the destination
4. Destination	Your landing page	Receives the visitor — or the scanner

Expert Explanation

What Safe Links actually does

Per Microsoft’s documentation, Safe Links provides “URL scanning and rewriting of inbound email messages during mail flow, and time-of-click verification of URLs.” Scanned URLs are rewritten using the Microsoft standard URL prefix, so a click on a rewritten link is “scanned for malicious content before directing the user to the page.” If a URL has no valid reputation, it is “detonated asynchronously in the background” — the gateway itself fetches the link. Two details matter for entry owners: URLs are scanned before delivery even when rewriting is off, and a suspicious URL shows the user a warning page (including a “scan in progress” notice) instead of your destination.

Why email click stats and entry stats never match 1:1

Counts differ for structural reasons, not bugs: opens are suppressed when pixels are blocked, while clicks are not; one recipient can click several times; gateway and ESP wrappers each count the click in their own system with their own deduplication (or none); a click that stops at a Safe Links warning page never reaches your entry; and scanner fetches add requests no human made.

Recognizing scanner traffic in your entry logs

You can’t identify every scanner hit with certainty, but the pattern is learnable:

• User-agent patterns. Scanner fetches often arrive with non-browser user agents — headless clients, security crawlers, or generic HTTP libraries. Treat this as a hint: Microsoft doesn’t document a stable, public user-agent for Safe Links fetches, so matching on a single string is unreliable.
• Request bursts. A cluster of hits to the same entry within seconds or minutes, especially shortly after send time or at hours humans don’t click, is a classic detonation signature.
• Referrer-less hits. The Referer header is optional in HTTP and automated fetches routinely omit it, so a burst of referrer-less hits is worth investigating.
• Counts that disagree. If the entry’s clicks dwarf your ESP’s clicks, or clicks exceed opens, scanners are likely inflating the number.

Practical limits

• You can’t filter scanner traffic at the entry without risking false positives on real users; treat recognition as an interpretation aid, not a filter.
• Whether Safe Links rewrites your links is the recipient organization’s policy decision, not yours. You can request, but you cannot configure, their security stack.
• Entry statistics are directional: reliable for trends, troubleshooting, and auditing; not a precise human click count.
• A “not rewritten” URL is not a “guaranteed direct access” URL. Microsoft notes that entries on the “Do not rewrite the following URLs” list aren’t scanned or wrapped during mail flow, but might still be blocked at the time of click.

Decision Framework

Checklist for when a campaign’s entry numbers look off:

• Did the hits arrive in a burst minutes after send, before humans plausibly read the email?
• Do the hits come with no referrer, or with a referrer from a gateway or wrapper domain?
• Do the user agents look like browsers, or like headless clients and security crawlers?
• Do email click counts exceed opens on a campaign whose image pixels were working?
• Does the redirect chain start at safelinks.protection.outlook.com, urldefense.com, a Mimecast protect link, or an ESP tracking domain?
• Does the entry still point at a live, intended destination — or is a stale destination receiving fetches that look like clicks?

If most answers point to scanner traffic, don’t rewrite the campaign or the landing page — the entry is fine. Compare the entry’s access statistics against the ESP report, confirm the destination is healthy, and check that the redirect type still fits the campaign’s intent. If a branded campaign subdomain is being wrapped and you want direct clicks for it, ask the recipient organization’s security team to exempt it via the “Do not rewrite the following URLs” list in Safe Links policies — but it is their call: unwrapped URLs lose the mail-flow scanning the wrapper provides. When entry stats and conversions disagree, suspect the tracking stack before the entry.

Key Takeaways

• Email security gateways rewrite your campaign links during mail flow and scan them again at click time; the request reaches your entry only after that chain completes.
• Scanner traffic — click-time checks and background detonation — lands in your entry’s access statistics as ordinary requests, which is why clicks can exceed opens and why your numbers will never exactly reconcile.
• Recognize scanner traffic by request bursts, referrer-less hits, non-browser user agents, and counts that disagree — all heuristics, none conclusive.
• The “Do not rewrite the following URLs” list in Safe Links policies is the documented mechanism for keeping a branded campaign subdomain out of the wrapper, but it is controlled by the recipient organization’s admins and carries a security trade-off.
• Use entry stats for trends, troubleshooting, and your audit evidence trail — not as a human click census.

FAQ

Why do my email click counts sometimes exceed my opens?

Opens and clicks are measured differently. Open tracking relies on image pixels that privacy features and security filters often block, while clicks are counted by ESP wrappers, gateway wrappers, and scanner fetches — including requests no human made. Clicks exceeding opens is normal, not a bug.

Can I stop Safe Links from rewriting my campaign links?

Not unilaterally. Rewriting is governed by the recipient organization’s Safe Links policies in the Microsoft Defender portal. You can ask the security admins to add your domain or entry URL to the “Do not rewrite the following URLs” list, which removes mail-flow scanning and wrapping for those URLs — though Microsoft notes they might still be checked at the time of click.

How do I tell a scanner click from a real click in my entry logs?

Look at the pattern, not any single field: bursts of hits shortly after send or at unusual hours, requests with no referrer, non-browser user agents, and click counts that disagree with your ESP’s data. No single signal is conclusive — Microsoft doesn’t publish a fixed user-agent for Safe Links fetches.

Why do users report the link is broken when my entry is working?

Because the chain before your entry is opaque to them. A click can stop at a Safe Links warning page, a “scan in progress” notice, or a wrapper error before reaching your entry, and the extra hops add latency that reads as a broken link. Check the redirect chain from the wrapper, confirm the destination is live, and remember that gateway and ESP layers always sit between the email and your logs.

Sources

1. Microsoft Learn — Safe Links in Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/defender-office-365/safe-links-about
2. Microsoft Learn — Set up Safe Links policies in Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/defender-office-365/safe-links-policies-configure
3. MDN Web Docs — Redirections in HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
4. RFC 9110 — HTTP Semantics (Referer field): https://www.rfc-editor.org/rfc/rfc9110