Microsoft is currently addressing a significant service issue where its anti-spam filtering technology within Defender for Office 365 is incorrectly blocking legitimate URLs in Exchange Online emails and Microsoft Teams chats1. This problem, which also involves the erroneous quarantining of non-malicious emails, stems from a malfunction in the multi-layered filtering stack that protects Microsoft 365 organizations by default2. The disruption highlights the potential operational impact when automated security services, designed to be intelligent and self-learning, experience configuration or processing errors.
The automated protection for all Microsoft 365 cloud mailboxes includes several filtering stages. Email processing begins with connection filtering to check sender reputation, followed by malware filtering, policy filtering against mail flow rules, and finally, core content filtering which encompasses both anti-spam and anti-phishing checks2. Messages that pass all these layers are delivered to the recipient’s mailbox. The service is backed by a 99.999% uptime SLA, making such widespread disruptions notable2.
Understanding Safe Links and URL Blocking
The specific feature implicated in this incident is most likely Safe Links, a component of Microsoft Defender for Office 365 that provides time-of-click verification for URLs3. In emails, Safe Links often rewrites URLs with a `safelinks.protection.outlook.com` prefix. In Microsoft Teams, URLs are checked at the time of click without being rewritten3. A critical aspect of this protection is that it is enabled by default for all licensed users through the ‘Built-in protection’ preset security policy, even if administrators have not configured any custom Safe Links policies3. This default enforcement means that any bug in the service can have an immediate and broad impact across a tenant.
When a URL is blocked by Safe Links, users typically encounter a warning message indicating “potentially harmful content.” The service uses global threat intelligence and feedback mechanisms to make its determinations, but a bug could cause its logic to falsely classify benign URLs as malicious. This kind of service degradation is not without precedent; recent incidents tracked in service health dashboards have included events where users experienced delayed location and verdict data for certain events in Microsoft Defender for Office 365 due to backend service configuration changes4.
Administrative Investigation and Remediation
For administrators responding to this issue, the standard investigative procedure involves first confirming that a URL is being blocked by the Safe Links service and not by another mechanism like the Tenant Allow/Block List (TABL)3. The recommended method for whitelisting a legitimate URL caught in such a filter is to submit it as a false positive via the Submissions portal and select the “Allow this URL” option. This action adds the URL to the Tenant Allow/Block List, which provides broader protection across all Defender for Office 365 features5.
The Tenant Allow/Block List for URLs has entry limits that vary by license subscription. For Defender for Office 365 Plan 2, administrators can have up to 5000 allow entries and 10000 block entries5. Allow entries created via the Submissions portal are powerful because they can override more severe verdicts, including malware and high confidence phishing. Entries made directly in the TABL can only override bulk, spam, and phishing classifications. Allow entries expire after 45 days by default, though this is configurable5.
Broader Implications for Email Security
This incident also involves the incorrect quarantining of emails, which points to an issue within the anti-spam filtering layer. Anti-spam policies classify messages with specific Spam Confidence Levels (SCL), such as ‘Spam’ (SCL 5-6), ‘High Confidence Spam’ (SCL 7-9), ‘Phishing’, and ‘High Confidence Phishing’6. The actions for each verdict, such as moving to junk, quarantining, or deleting the message, are configurable within these policies. A bug could cause a miscalculation in the SCL, leading to legitimate mail being subjected to the wrong action.
The order of policy application is also a factor. Preset security policies (Strict and Standard) are applied first, followed by custom policies in order of their priority, with 0 being the highest. The default policy always applies last with a priority of “Lowest”6. An error in any of these policy layers, especially the default ones that cannot be turned off, could result in widespread message mishandling. Furthermore, the Zero-Hour Auto Purge (ZAP) feature, which is enabled by default to detect and act on malicious messages *after* delivery, could potentially compound the problem if it is also affected by the same faulty logic6.
This disruption serves as a reminder of the complex interdependencies within cloud security services. While these automated systems provide robust protection, their default-on nature and deep integration into core communication platforms like Exchange Online and Teams mean that any service anomaly can directly impair business operations. Organizations are advised to monitor the Microsoft 365 Message Center and Service Health Dashboard for official updates and resolution timelines regarding this incident4.
