AD2.2 Safe Links: URL Protection That Works at Click Time

Creating the Safe Links policy

Navigate to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Safe Links. Click "Create" to build a new policy.

Name: "Safe Links — All Users"

Users and domains: Click "Users" → Include → "All recipients." This applies the policy to every user in the tenant. You can exclude specific users later if needed (rarely necessary for Safe Links — the false positive rate is very low).

URL & click protection settings — configure each one:

On: Safe Links checks a list of known, malicious links when users click links in email. Enable this. This is the core Safe Links function — every URL click is checked against Microsoft's threat intelligence at click time.

On: Safe Links checks a list of known, malicious links when users click links in Microsoft Teams. Enable this. Teams messages contain URLs too, and attackers increasingly use Teams for phishing (especially via guest access or compromised accounts).

On: Safe Links checks a list of known, malicious links when users click links in Office apps. Enable this. Covers URLs in Word, Excel, PowerPoint documents opened from email or SharePoint.

Apply real-time URL scanning for suspicious links and links that point to files. Enable this. When the URL destination is unknown (no prior reputation), Safe Links detonates it in a sandbox before allowing the user through. This catches zero-day phishing pages.

Wait for URL scanning to complete before delivering the message. Enable this. Without this setting, the email is delivered immediately and Safe Links scans the URL asynchronously — which creates a window where the user could click before scanning completes. With this enabled, the URL must be scanned before the email reaches the inbox. The delay is typically under 10 seconds and users rarely notice.

Do not rewrite URLs, do checks via Safe Links API only. Leave this OFF (disabled). URL rewriting is what makes Safe Links work — if you disable rewriting, Safe Links can only check URLs in the Outlook client (not webmail, not mobile, not other email clients). Keep rewriting enabled for full coverage.

Do not rewrite the following URLs: Leave empty unless you have specific URLs that break when rewritten (internal SharePoint sites, specific vendor portals). Add exceptions only when users report that a specific URL doesn't work with Safe Links — and document each exception.

Notification: Use the default notification page. This is the warning page users see when Safe Links blocks a URL. The default page is clear and professional — it tells the user the link was blocked for safety and provides a "back to safety" button.

Click "Submit" to create the policy.

What users experience

For clean URLs, the experience is transparent. The user clicks a link, there's a brief redirect through safelinks.protection.outlook.com (typically under 1 second), and they arrive at the destination. Most users never notice Safe Links is active.

For malicious URLs, the user sees a full-page warning: "This website has been classified as malicious." The page explains that the link was blocked, provides a "Go back" button, and does not provide a way to proceed to the malicious site. The user cannot override the block — which is the correct behavior. If a user reports that a blocked URL is legitimate, you investigate and add it to the exception list if confirmed safe.

For unknown URLs undergoing real-time detonation, the user sees a brief scanning page: "This link is being scanned." This typically takes 5-15 seconds. If the URL is clean after detonation, the user proceeds normally. If malicious, the warning page appears.

The most common user complaint about Safe Links is that rewritten URLs look ugly in emails — instead of seeing https://example.com/document, the user sees a long safelinks.protection.outlook.com URL. This is cosmetic. If users complain, explain that the rewritten URL is what protects them from phishing — the original URL is still the destination, Safe Links just checks it first. In Outlook desktop and mobile, the original URL is shown in a tooltip when hovering — the rewritten URL is only visible if the user copies the link.

Testing Safe Links

After creating the policy, test it to confirm it's working.

Test 1 — Clean URL. Send yourself an email with a link to a known-safe URL (https://www.microsoft.com). Click the link. You should be redirected through safelinks.protection.outlook.com and arrive at Microsoft's homepage. Check the URL in your browser address bar during the redirect — you'll briefly see the safelinks URL before being redirected to the destination.

Test 2 — Verify rewriting. Send yourself an email and view the message source (in Outlook: open the email → File → Properties → Internet headers, or right-click → View source in Outlook Web). Search for "safelinks" in the source. All URLs in the email body should be rewritten to safelinks.protection.outlook.com URLs. If they're not rewritten, the policy isn't applying to your account — check the user scope in the policy configuration.

Test 3 — Check the URL trace. Navigate to security.microsoft.com → Email & collaboration → Explorer (or Reports → URL trace). After clicking the test URL, you should see an entry showing your click, the destination URL, and the verdict (allowed). This confirms that Safe Links is logging clicks — which is the data you'll use to investigate phishing clicks later.

Microsoft provides a specific test URL for Safe Links: https://smartscreentestratings2.net. This URL is maintained by Microsoft specifically for testing Safe Links and SmartScreen. Send yourself an email containing this URL, click it, and Safe Links should block it with the warning page. If the warning page appears, Safe Links is working correctly.

Monitoring Safe Links effectiveness

After deployment, check the Safe Links URL trace weekly as part of your Monday morning review. Navigate to security.microsoft.com → Email & collaboration → URL trace (or Reports → URL protection report).

The key metrics to track: total URL clicks per week (this is your baseline — how many URLs are your users clicking in email), blocked clicks (URLs that Safe Links prevented users from reaching), and allowed clicks that were later reclassified as malicious (URLs that were clean at click time but subsequently identified as phishing — these are the "time-of-click" catches that Safe Links provides).

If you see a specific user with 10+ blocked clicks in a week, they're either being heavily targeted or they're clicking everything they receive. Either way, a conversation with that user is warranted — targeted awareness training or a discussion about email habits.

The URL trace also shows you which URLs are being targeted at your organization. If you see the same phishing domain appearing in multiple blocked clicks, you can proactively block that domain in your tenant's block list (security.microsoft.com → Policies & rules → Threat policies → Tenant Allow/Block Lists → URLs).