Why is Microsoft scanning links in my emails at a high rate?
Published 27 Apr 2025
Updated 4 Oct 2026
12 min read
Summarize with
Updated on 4 Oct 2026: We clarified when Safe Links checks become site requests and how to handle scanner traffic, click reporting, and one-click unsubscribe safely.
Microsoft is scanning links in your emails at a high rate because its protection systems evaluate URLs before delivery and at click time. In Microsoft 365, that usually means Safe Links in Microsoft Defender for Office 365. In consumer mailboxes, Outlook.com security can also inspect links. Requests that reach your website can exceed the human audience when protected recipients, distinct message URLs, redirects, and repeated checks add up.
The clearest public description is Microsoft Safe Links. Microsoft says Safe Links scans URLs during mail flow and checks links at click time in email, Teams, and supported Office apps. A mail-flow check does not necessarily send an HTTP request to your website, so count actual site requests in your logs.
- High Microsoft link traffic is usually automated security activity, but confirm the request pattern before excluding clicks from reporting.
- Safe Links and related checks evaluate links before users reach the final page.
- Measure origin traffic, keep links stable, and separate likely scanner requests from human engagement.
Why the scan rate gets so high
The surprising part is scale. Senders often assume that 100,000 delivered messages should create no more than 100,000 link checks. That assumption fails when messages contain several URLs, recipients have different protection policies, and a URL is checked again at click time. Redirects can also create multiple requests along a single navigation path.
Flowchart showing how link checks can occur at several stages after email delivery.
A burst of tens of thousands of requests per minute is still painful. It does not automatically mean your domain is on a Microsoft blocklist (blacklist), and it does not prove Microsoft distrusts your URLs. Recipient volume, receiving-tenant policy, URL patterns, redirect behavior, and repeated checks can all contribute.
- Safe Links wraps URLs per protected message recipient when rewriting is enabled. This creates distinct protected links, although wrapping alone does not prove that Microsoft fetched each destination.
- Microsoft 365 admins can apply different Safe Links settings to users, groups, or accepted domains.
- A link checked before delivery can be checked again when a protected recipient clicks it.
- Dynamic redirects, tracking links, file downloads, and geotargeting can lead to additional inspection.
- New domains, new paths, and destinations without an established verdict can receive closer review.
What a Safe Links check proves
Safe Links can scan or classify a URL inside Microsoft without fetching the landing page. URL rewriting in a delivered message proves that protection was applied; it does not prove a visit to your site. The requests in your web or CDN logs are the evidence of visits to your infrastructure.
Compare those requests with the send and delivery timeline, the original and final URL, response codes, and redirect hops. If a recipient organization can help investigate, its administrator can review Safe Links click events in Microsoft Defender. Treat those records and your site logs as different measurements: one records protected click activity, while the other records HTTP traffic your systems received.
What to check in your logs
Start with logs, not assumptions. The goal is to separate Microsoft-associated infrastructure, recipient behavior, your own redirect behavior, and campaign-specific patterns. The most useful evidence is the shape of the burst.
|
|
|
|---|---|---|
Network owner | Microsoft-associated source | Combine with behavior |
Method | HEAD or GET pattern | Track both methods |
Timing | Burst near delivery | Compare with send time |
Request sequence | Several links in seconds | Review as likely automation |
Browser trail | No assets or session | Exclude only with other signals |
Status | Access result | Investigate failures |
Signals that help separate scanner requests from human clicks.
Do not rely only on user agent strings or IP ownership. User agents change, and a Microsoft-associated source alone does not prove that Safe Links made the request. Classify likely bot clicks using several signals, such as immediate bursts after delivery, repeated requests to message links within seconds, no normal browser asset trail, and no session behavior after the landing page.
Useful scan log fieldstext
timestamp=2026-10-05T10:14:22Z method=GET status=200 asn=Microsoft ip_family=IPv4 url_hash=8f4b2a message_id=msg-12345 recipient_domain=contoso.com campaign_id=donor-renewal-1005 redirect_count=2 asset_requests=0
Why some campaigns trigger more scanning
When scanning spikes hit only a few customer domains or campaigns, compare those segments first. The cause often sits in the message and URL pattern. A nonprofit sender using donation links, tracking redirects, and personalized URLs can present a different URL path than a sender linking to one stable public article.
Common triggers
- Recently registered or newly delegated domains have little history.
- A shared tracking host carries reputation effects across unrelated customers.
- A dynamic redirect changes destination by IP, geography, device, token, or time.
- Downloads and document URLs can receive real-time inspection.
Weak assumptions
- A burst of Microsoft traffic is not engagement by default.
- Mailbox policy, sender reputation, and URL design can all contribute.
- Scan volume can fall, then spike again as campaigns or policies change.
- Blocking scanners can make a page unreachable during URL evaluation.
This is also where click reporting gets messy. If campaign analytics count every request as a click, security traffic inflates click rates and corrupts attribution. Tracking-pixel requests can also inflate opens in some setups. A related pattern is covered in automatic opens and clicks, where the fix is to classify security activity before it reaches reporting.
Should you rate limit or block Microsoft?
Avoid hard blocking Microsoft-associated scanners unless traffic threatens availability and no other short-term control works. Blocking can make the URL appear unreachable during evaluation. Rate limiting is safer when it preserves a normal response for valid requests and protects expensive application work separately.
Keep valid links reachable
Repeated 403, 429, 500, or timeout responses can prevent successful inspection or access. Use a lightweight, cacheable landing response when appropriate, keep redirect chains short, and protect expensive downstream actions behind human interaction.
- Return the normal page for a valid URL; do not manufacture a 200 response for a genuinely missing or failed page.
- Do not require cookies, JavaScript, or a one-time token merely to inspect a public landing page.
- Limit costly database writes, personalization, and analytics work separately from the basic page fetch.
- Store likely scanner hits separately so campaign reports keep human clicks distinct.
A practical architecture lets the scanner reach a cheap, deterministic page, then requires a human step for state-changing actions. If your link path executes expensive personalization on every request, scan bursts become an application scaling problem.
Response plan by scan pressure
Set operational bands against your own request baseline. These are triage states, not Microsoft limits.
Normal
Near baseline
Separate from human analytics and monitor.
High
Above baseline
Cache landing responses and reduce redirect work.
Severe
Availability risk
Protect expensive systems and prepare evidence for Microsoft.
Unknown
No baseline
Add logging before changing access rules.
Protect one-click and magic links from scanners
Automated link scanners expose a design flaw when a GET request changes account or workflow state. An approval link, unsubscribe link in the message body, passwordless sign-in link, or single-use download can be consumed before the recipient acts. A long, unguessable token prevents guessing, but it does not stop a security system that received the real URL from requesting it.
A GET request should not complete a sensitive action
Use the emailed URL to open a confirmation page for approvals, sign-ins, and body-link preference changes. Complete the action only after deliberate user interaction, preferably through a POST request. Standards-based List-Unsubscribe one-click requests are a specific exception: the mailbox provider sends a POST that must unsubscribe without a login or confirmation step.
- Do not mark a sign-in or action token used when the landing page loads.
- Show the intended action and require confirmation for sensitive workflows.
- Keep state changes out of ordinary GET requests. For RFC 8058 one-click unsubscribe, process the authorized POST.
- Use idempotent processing so duplicate submissions do not repeat an action.
For passwordless sign-in, bind the final exchange to the browser session and apply a short expiry after the user confirms. For preference changes, show the current state before saving. These controls also protect the workflow when preview services or other automated systems request the URL.
How to reduce scan load without hurting delivery
The mitigation path combines engineering, deliverability, and evidence. You cannot force Microsoft to stop checking every URL, but you can reduce the work each site request creates and prepare a clearer case when Microsoft needs to investigate abnormal volume.
- Measure requests per delivered Microsoft recipient, per campaign, and per customer.
- Avoid changing destinations behind the same tracking link unless there is a clear product need.
- Keep tracking and destination hops minimal, with HTTPS on every hop.
- Filter likely scanner patterns before reporting opens, clicks, conversions, or lead scores.
- Find whether a few senders, domains, templates, or destinations account for most scan load.
- Open a Microsoft support case with timestamps, source IPs, URLs, rates, response codes, and campaign scope.
Also check whether the same campaign creates similar behavior at other mailbox providers and security gateways. When only Microsoft-hosted domains create the burst, receiving policy is one hypothesis to test. When several gateways behave the same way, review the message and link design more closely. This overlaps with the broader question of whether security filters click links, which is common enough that analytics systems need explicit bot handling.
Where authentication and reputation fit
DMARC does not cause Safe Links scanning. A correct DMARC setup will not stop Microsoft from checking URLs. Authentication still belongs in the investigation because SPF, DKIM, and DMARC failures can indicate a separate sender identity problem. Treat that evidence separately from link-scan volume rather than assuming one caused the other.
Suped is our DMARC and email authentication platform. It helps teams map authenticated sending sources and review SPF, DKIM, and DMARC failures alongside alerts and blocklist (blacklist) status. In this workflow, use Suped to check for separate authentication and sender reputation problems while investigating the Safe Links traffic spike.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
A practical Suped workflow uses DMARC monitoring to confirm who is sending and blocklist monitoring to watch domain and IP reputation. Use the domain health checker for a quick public validation of DMARC, SPF, and DKIM before deeper investigation.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Test the email path and the click path
A good investigation sends real test mail, then follows the same link path a protected recipient sees. Testing only the landing page misses what happens during mail flow. Testing only authentication misses the redirect chain. Review both views before changing infrastructure.
Use an email tester to send a representative message and inspect authentication, content, and link behavior. Then compare that result with server logs for Microsoft-associated sources. The gap between the test and production traffic often shows whether the issue is template-wide, customer-specific, or tied to a particular recipient domain.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For Microsoft 365 business recipients, Safe Links can rewrite URLs and check links at click time. For Outlook.com recipients with Microsoft 365 Personal or Family, Outlook.com security provides consumer-focused link protection. That difference matters when you compare corporate domains with Outlook.com or Hotmail recipients.
What Microsoft admins see
The sender usually cannot see the receiving tenant's Safe Links policy. That is why the same campaign can behave differently across two Microsoft-hosted companies. One tenant can have stricter URL scanning, click tracking, or real-time file-link scanning than another tenant.
Microsoft Defender portal showing a Safe Links policy and its URL protection settings.
Safe Links policy processing stops after the first policy that applies to a recipient. Preset security policies take priority over custom policies, while built-in protection is applied last. Admins can also disable URL rewriting while retaining pre-delivery scanning and supported time-of-click API checks, so an unwrapped link does not prove that scanning is off.
That admin-side control explains why the sender's view often feels inconsistent. The same sending IP and tracking host can receive low scan volume for one recipient domain and heavy scan volume for another. If a legitimate URL is falsely blocked, the recipient administrator can submit that URL to Microsoft for review; broad policy exceptions reduce protection.
Views from the trenches
Best practices
Track Microsoft scan bursts per customer, campaign, URL host, and recipient domain.
Keep scanner responses cheap, stable, cacheable, and close to the human landing page.
Open support cases with timestamps, source IPs, URLs, response codes, and rates.
Common pitfalls
Treating every Microsoft request as a human click damages campaign reporting accuracy.
Blocking scanner IPs can make links appear broken or evasive to receiving filters.
Changing destinations behind one tracking URL can trigger new checks and inconsistent results.
Expert tips
Compare affected and unaffected customer domains before changing shared systems.
Separate tracking analytics from landing page availability and reputation signals.
Use authentication and blocklist data to identify separate sender reputation problems.
Marketer view
Marketer from Email Geeks says Microsoft scan volume can decrease as sender reputation improves, but corporate tenant policies can keep checks high.
2024-01-22 - Email Geeks
Marketer view
Marketer from Email Geeks says a Microsoft sender support case should include a request for escalation when the first response misses the URL scanning issue.
2024-01-22 - Email Geeks
The practical answer
Microsoft checks email links to evaluate URL safety for protected recipients. High site traffic can come from repeated automated requests, recipient and tenant fan-out, or redirect paths. It is not proof of a blacklist or blocklist problem by itself. Confirm the volume in web logs before treating every Safe Links check as a visit.
Keep the landing path stable, make valid responses cheap, separate likely bot requests from human analytics, protect state-changing actions behind a confirmation step, and escalate to Microsoft with hard evidence when the request rate is disproportionate. Use Suped to monitor DMARC, SPF, DKIM, and blocklist (blacklist) status so separate authentication or reputation problems do not get mixed into the Safe Links diagnosis.
