8.3 Safe Links Policies

90 minutes · Module 8

Safe Links Policies

By the end of this subsection, you will understand URL rewriting and time-of-click scanning, know when Safe Links fails and why, configure a Safe Links policy, and track user clicks with KQL.

How Safe Links works

When a user receives an email containing a URL, Safe Links rewrites the URL to route through Microsoft’s scanning infrastructure. When the user clicks, the request goes to Microsoft first, which scans the destination in real-time, then either allows or blocks the user from reaching it.

Time-of-click protection is the key feature. A URL that was clean at email delivery may become malicious hours later (the attacker activates the phishing page after the email passes scanning). Safe Links catches this because it scans at the moment of click, not at the moment of delivery.

URL scanning modes

Mode	Behavior	When to use
On: URLs are rewritten and checked at time of click	Full protection — every click is scanned	Default for all policies
Do not track when users click URLs	Scanning still occurs but click data is not logged	Not recommended — you lose UrlClickEvents data
Do not rewrite URLs, check via Safe Links API only	URLs are not modified in the email body but are still checked	When URL rewriting breaks specific applications

Never disable click tracking

The UrlClickEvents table in Advanced Hunting tells you exactly which users clicked which URLs, whether Safe Links warned them, and whether they clicked through the warning. This data is critical for phishing investigation (Module 13.4 used it to identify which users clicked the AiTM phishing link). Disabling tracking removes this investigation capability.

When Safe Links fails

Safe Links is not infallible. Understanding its limitations prevents false confidence:

Limitation	How attackers exploit it	Mitigation
Anti-analysis CAPTCHAs	Cloudflare turnstile or reCAPTCHA blocks automated scanning — Safe Links sees the CAPTCHA page, not the phishing page behind it	First contact safety tips + user awareness training
Redirect chains	URL redirects through multiple legitimate services (Google redirect, Bing redirect) before reaching the phishing page	Defender URL detonation follows some redirects but has a depth limit
Delayed activation	Phishing page is activated after Safe Links’ initial scan	Time-of-click scanning catches most, but there is a brief window
Password-protected files	Shared links to password-protected documents bypass content scanning	Safe Attachments with Dynamic Delivery for known file-sharing services

Click tracking with KQL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
UrlClickEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ClickBlocked" or IsClickedThrough == true
| summarize
    TotalClicks = count(),
    Blocked = countif(ActionType == "ClickBlocked"),
    WarningShown = countif(ActionType == "ClickAllowed" and IsClickedThrough == false),
    ClickedThrough = countif(IsClickedThrough == true)
    by UrlDomain
| where TotalClicks > 3
| sort by ClickedThrough desc

Expected Output

UrlDomain	TotalClicks	Blocked	WarningShown	ClickedThrough
northgate-voicemail.com	7	0	2	5
suspicious-login.com	4	4	0	0

What to look for: The northgate-voicemail.com domain shows 5 users who clicked through the warning — exactly the Module 13 scenario. suspicious-login.com was fully blocked (4 clicks, 4 blocked). The ClickedThrough column identifies users who need targeted security awareness training.

URL rewriting explained

When Safe Links is active, the original URL in the email is replaced with a Microsoft URL:

Original: https://northgate-voicemail.com/auth/a3f8b2c1/login Rewritten: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnorthgate-voicemail.com%2Fauth%2Fa3f8b2c1%2Flogin&data=...

When the user clicks, the request goes to safelinks.protection.outlook.com first. Microsoft scans the target URL in real-time, then either:

Allows: redirects the user to the original URL
Warns: shows a warning page (user may click through if policy allows)
Blocks: shows a block page (user cannot proceed)

The entire process takes under 2 seconds for known-clean URLs. Unknown URLs may take 5-10 seconds while detonation runs.

Safe Links coverage scope

Location	Protected?	Notes
Email body URLs	Yes	All URLs rewritten and scanned
Email attachment URLs	Yes (if Safe Attachments enabled)	URLs in Word/Excel/PDF opened in sandbox
Teams messages	Yes	URLs in chats and channels scanned
Office documents	Yes	URLs clicked in Word/Excel/PowerPoint scanned
Browser navigation	No	Safe Links only covers M365 context — for general browsing, use Network Protection (Module 7.2)

Policy decision: should you allow click-through?

You are configuring Safe Links for a 500-seat organization. The security team wants maximum protection. The marketing team says they regularly receive emails with URLs that Safe Links incorrectly flags.

Should you enable "Let users click through to the original URL"?

Policy configuration

Navigate to security.microsoft.com -> Policies -> Threat policies -> Safe Links
Create a new policy (or edit the default)
Settings:
- URL and click protection settings: On (URLs rewritten and checked)
- Track user clicks: Yes (never disable)
- Let users click through: No (recommended) — users cannot override the block. If you set this to Yes, users can click through warnings (the Module 13 scenario).
- Scan URLs in email: On
- Scan URLs in Teams: On
- Scan URLs in Office apps: On
- Do not rewrite URLs: Off (keep rewriting)
Apply to all users (or specific groups)

The "Let users click through" decision

If set to "No", users cannot override Safe Links blocks — maximum protection but occasional false positive frustration. If set to "Yes", users can click through warnings — the Module 13 scenario where 5 of 7 users clicked through. For most organizations, "No" is correct. If legitimate business URLs are regularly blocked (rare with current ML), create specific allow list entries rather than enabling global click-through.

Try it yourself

Run the click tracking query above in your environment. How many domains have users clicking through warnings? Would setting "Let users click through" to No have changed the outcome?

In a developer tenant with sample data, you may see limited click activity. The key learning is the query pattern: UrlClickEvents combined with IsClickedThrough gives you a direct measurement of user behavior on warned URLs. If users regularly click through warnings, either (1) the warnings are not effective (training needed) or (2) the click-through option should be removed (policy change).

Check your understanding

1. A phishing URL is clean at email delivery but activated 2 hours later. Does Safe Links catch it?

Yes — Safe Links scans at time of click, not time of delivery. When the user clicks 2 hours later, Safe Links scans the now-active phishing page and blocks or warns. This is the primary value of time-of-click scanning over delivery-time-only scanning.

No — Safe Links only scans at delivery

Only if ZAP runs first

Time-of-click is Safe Links' defining capability. The URL is scanned every time a user clicks it, regardless of when the email was delivered. This catches delayed-activation attacks that delivery-time scanning misses.

2. 5 users clicked through the Safe Links warning. What does this tell you about your policy?

The "Let users click through" setting is enabled, and users are overriding security warnings. Either disable click-through (recommended) or deploy targeted security awareness training on what Safe Links warnings mean. The warning worked (it was shown), but the policy allowed users to ignore it.

Safe Links failed

The users are malicious insiders

Safe Links detected the threat and warned. The policy decision to allow click-through undermined the protection. This is a configuration issue, not a detection failure. Disable click-through for maximum protection.

← 8.2 Anti-Phishing Policies 8.4 Safe Attachments Policies →