Govern every Safe Links exception as a monitored bypass

Bottom line: Safe Links can rewrite and scan URLs in email and evaluate clicks in supported Teams and Office experiences. A recipient exception or do-not-rewrite URL creates a different protection path. Treat every bypass as a scoped, owned, tested, and expiring security decision.

Source fact: what Microsoft documents

Microsoft’s Safe Links policy guide documents separate Safe Links policies and rules. The policy holds protection behavior; the rule holds priority, recipient conditions, exclusions, and state. Portal creation combines these objects, while PowerShell exposes them separately.

Microsoft documents protection settings for email, Teams, and supported Office apps, including URL scanning, rewriting, click tracking, warning-page behavior, and whether a user may continue to the original URL. The guide also documents do-not-rewrite URL entries and policy precedence. Standard and Strict preset security policies are evaluated ahead of custom policies, so a custom exclusion may not affect a recipient governed by a preset policy. Microsoft provides a propagation window and verification procedures.

What the source does not establish

Safe Links does not certify a destination as safe or prevent harm after a user reaches an allowed site. It does not cover every application, protocol, copied URL, redirect, QR code, or unsupported client. A rewrite exception does not prove that a business application needed broad bypass; the actual dependency may be narrower. Click tracking and investigation data also raise access and retention questions that the configuration page does not resolve for the organization.

Applicability questions

• Which recipients are effectively covered by Built-in, Standard, Strict, and custom policies?
• Which apps and clients do users actually use to open email, Teams messages, and Office documents?
• Why does each recipient exclusion or do-not-rewrite URL exist, and what exact function fails without it?
• Can the exception be restricted to a full URL or domain path instead of a broader pattern?
• Who may view click data, investigate warnings, and authorize bypass or release decisions?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Inventory effective policy membership, custom-rule priority, exclusions, and do-not-rewrite entries. Resolve policy overlap first.
2. For every requested bypass, reproduce the business failure, record the narrowest required pattern and recipients, and test a safer application fix.
3. Pilot policy changes with representative clients and links, including internal senders, redirected URLs, Office documents, and Teams where applicable.
4. Assign each exception an owner, rationale, approval, monitoring plan, and review or expiration date.
5. Review warnings, click events, phishing investigations, false positives, and exception use after rollout.

Verification and evidence

• Preserve policy and rule configuration, precedence, scope, and exception register.
• Capture message or click evidence showing the expected policy handled each test case.
• Test allowed, warned, blocked, bypassed, and user-click-through behavior without directing users to live malicious content.
• Retest exceptions after the dependent application or authentication flow changes.

Official references

• Set up Safe Links policies in Microsoft Defender for Office 365 — Microsoft