Why is Microsoft scanning links in my emails at a high rate?
Matthew Whittaker
Co-founder & CTO, Suped
Published 27 Apr 2025
Updated 25 May 2026
10 min read
Summarize with
Microsoft is scanning links in your emails at a high rate because its protection systems evaluate URLs before delivery, at click time, and sometimes after delivery. In Microsoft 365, that usually means Safe Links in Microsoft Defender for Office 365. In consumer mailboxes, Outlook.com security can also inspect links. The request count can exceed the human audience because scans fan out across recipients, tenants, security policies, cached and uncached URLs, redirect chains, and repeated checks of the same destination.
The clearest public description is Microsoft Safe Links. Microsoft says Safe Links provides URL scanning and rewriting during mail flow, plus time-of-click checks in email, Teams, and supported Office apps. That means a single email link is not a single event. It is an object that Microsoft can inspect at several points in the recipient journey.
- Short answer: high Microsoft link traffic is usually automated security scanning, not real subscriber clicks.
- Main cause: Safe Links and related checks inspect links before users reach the final page.
- Best response: measure the scan pattern, keep links stable, avoid hard blocking, and separate bot clicks from human engagement.
Why the scan rate gets so high
The surprising part is scale. I have seen senders assume that 100,000 delivered messages should create no more than 100,000 link checks. That assumption fails with Microsoft because the scanning system is not tied to a simple one-recipient, one-request model. It can scan at delivery, rescan at click, check different links in the same message, follow redirects, and repeat requests when reputation, cache, or policy decisions are unsettled.
Flowchart showing how one email link can trigger several Microsoft scans.
A high rate such as 50,000 requests per minute is still painful. It does not automatically mean your domain is on a Microsoft blocklist (blacklist), but it means Microsoft has enough reason to inspect your URLs aggressively. That reason can be a tenant setting, a suspicious redirect pattern, a reputation question, a large batch of recipients behind the same security stack, or simply Microsoft scanning more than once.
- Per-recipient wrapping: Safe Links can rewrite links per message recipient, so a shared destination still creates many protected URLs.
- Tenant policy: Corporate Microsoft 365 admins can apply stricter Safe Links settings for users, groups, or domains.
- Time-of-click checks: A link that looked acceptable at delivery can be checked again when someone opens it later.
- Redirect uncertainty: Dynamic redirects, tracking links, file downloads, and geotargeting can trigger deeper inspection.
- Reputation gaps: New domains, new paths, shared tracking domains, and noisy senders can increase automated scrutiny.
What to check in your logs
I start with logs, not assumptions. The goal is to separate four things: Microsoft infrastructure, recipient behavior, your own redirect behavior, and campaign-specific patterns. The most useful evidence is not a single request. It is the shape of the burst.
|
|
|
|---|---|---|
IP owner | Microsoft origin | Group separately |
Method | Bot pattern | Track HEAD and GET |
Timing | Delivery burst | Compare send time |
URL path | Repeated target | Check caching |
Status | Access result | Avoid hard denies |
Signals that help separate Microsoft scans from human clicks.
Do not rely only on user agent strings. Some scanning systems use generic clients, and user agents change. The stronger pattern is a combination of Microsoft-owned IP space, immediate bursts after delivery, repeated requests to the same destination, no normal browser asset trail, and no session behavior after the landing page.
Useful scan log fieldstext
timestamp=2026-05-25T10: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-0525 redirect_count=2 asset_requests=0
Why some campaigns trigger more scanning
When scanning spikes hit only a few customer domains or a few campaigns, I treat that as a segmentation problem. The cause is often buried in the message and URL pattern, not in the ESP infrastructure as a whole. A non-profit sender using donation links, tracking redirects, and personalized URLs can look very different to a security system than a sender linking to one stable public article.
Common triggers
- New domain: recently registered or newly delegated domains need reputation history.
- Shared tracker: one tracking host carries reputation risk for many unrelated customers.
- Dynamic redirect: destination changes by IP, geography, device, token, or time.
- File link: downloads and document URLs get deeper inspection than plain pages.
Weak assumptions
- All clicks: a burst of Microsoft traffic is not engagement by default.
- One cause: mailbox policy, sender reputation, and URL design can all contribute.
- Permanent state: scan volume can fall after reputation improves, then spike again.
- Simple block: blocking the scanner can create worse delivery and reputation signals.
This is also where click reporting gets messy. If campaign analytics count every request as a click, Microsoft security traffic inflates click rates and corrupts attribution. 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
I do not like hard blocking Microsoft scanners unless the traffic is threatening availability and there is no other short-term control. Blocking can make the URL look unreachable or evasive to the system that is deciding whether recipients should reach it. Rate limiting is safer when it preserves a clean response for security checks and protects your application separately.
Do not make the scanner see a broken site
If Microsoft receives repeated 403, 429, 500, or timeout responses, the result can be worse than the original scan load. Use a lightweight, cacheable landing response for scanner traffic, keep redirect chains short, and protect expensive downstream actions behind human interaction.
- Prefer 200: return the same safe content a user would see before any sensitive action.
- Avoid traps: do not require cookies, JavaScript, or one-time tokens just to inspect the page.
- Throttle cost: rate limit database writes, personalization, and analytics, not the basic page fetch.
- Log cleanly: store scanner hits separately so campaign reports keep human clicks distinct.
A practical architecture is to let the scanner reach a cheap, deterministic page, then require a human step for state-changing actions such as confirming a donation, updating preferences, or downloading private content. If your link path executes expensive personalization on every request, Microsoft scan bursts become an application scaling problem.
Response plan by scan pressure
Use request pressure to choose an operational response without damaging reputation signals.
Normal
Under 5x
Separate from human analytics and monitor.
High
5x-50x
Cache landing responses and reduce redirect work.
Severe
Over 50x
Protect expensive systems and prepare evidence for Microsoft.
Unknown
No baseline
Add logging before changing access rules.
How I reduce scan load without hurting delivery
The mitigation path is a combination of engineering, deliverability, and evidence. You cannot force Microsoft to stop scanning every URL, but you can reduce the triggers that make scanning expensive and prepare a clearer case when you need Microsoft to investigate abnormal volume.
- Baseline volume: measure Microsoft requests per delivered Microsoft recipient, per campaign, and per customer.
- Stabilize URLs: avoid changing destinations behind the same tracking link unless there is a clear product need.
- Shorten redirects: keep tracking and destination hops minimal, with HTTPS on every hop.
- Protect analytics: filter known scanner patterns before reporting opens, clicks, conversions, or lead scores.
- Segment customers: find whether a few senders, domains, templates, or destinations account for most scan load.
- Escalate with data: open a Microsoft sender support case with timestamps, source IPs, URLs, rates, and campaign scope.
I also check whether the same campaign creates similar behavior at other mailbox providers and security gateways. When only Microsoft domains create the burst, the evidence points to Microsoft policy or reputation evaluation. When several gateways behave the same way, the message or link design deserves closer review. This overlaps with the broader question of whether security filters click links, which is normal enough that analytics systems need explicit bot handling.
Where authentication and reputation fit
DMARC does not cause Safe Links scanning. A perfect DMARC setup will not stop Microsoft from checking URLs. It still matters because authentication and reputation tell Microsoft whether the message and domain deserve trust. If SPF, DKIM, and DMARC are inconsistent, or if a shared tracking domain has poor history, Microsoft has more reason to inspect the message closely.
For the authentication side, Suped's product is the strongest practical DMARC choice for most teams because it connects the dots across authentication, sender sources, alerts, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and blocklist monitoring. That matters here because link scanning spikes are easier to investigate when you can see whether the affected customer also has failing DKIM, SPF domain mismatch, unauthorized sources, or domain reputation issues.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The workflow I prefer is simple: use DMARC monitoring to confirm who is sending, use blocklist monitoring to watch domain and IP reputation, and use the domain health checker when you need 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. I want 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-owned IPs. 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 opens the report when the test is ready.
?/43tests passed
Preparing test address...
For Microsoft 365 business recipients, remember that Safe Links can rewrite URLs and check links at click time. For Microsoft 365 consumer subscribers, Outlook.com security has similar user-facing protection concepts. 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, and real-time file-link scanning than another tenant.
Microsoft Defender portal Safe Links policy settings screen.
That admin-side control explains why the sender's view often feels inconsistent. The same ESP, same sending IP, and same tracking host can receive low scan volume for one recipient domain and heavy scan volume for another. The receiving policy is part of the decision.
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 increases suspicion and repeat checks.
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 rule out wider sender reputation causes.
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 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 is scanning your links heavily because its email security systems are trying to evaluate URL safety for protected recipients. The high rate comes from repeated automated checks, recipient and tenant fan-out, time-of-click protection, redirect analysis, and reputation uncertainty. It is not proof of a blacklist or blocklist problem by itself, but it is a signal worth measuring.
The best response is not to block Microsoft outright. Keep the landing path stable, make scanner responses cheap, separate bot clicks from human analytics, investigate affected campaigns, and escalate to Microsoft with hard evidence when the scan rate is disproportionate. At the same time, keep DMARC, SPF, DKIM, hosted SPF, and blocklist monitoring clean in Suped so link scanning is not mixed with a wider sender reputation problem.
