Microsoft Left the Side Door Open

If phishing, spam, or scam email seems to be sneaking through more often and you’re on Microsoft 365, it may be worth asking a slightly awkward question: is there a mail path in your tenant that everybody assumed somebody else had already sanity checked? That is more or less the Direct Send story.

If you set up Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) in Microsoft 365, you would be forgiven for thinking failed authentication would reliably turn into rejection or quarantine everywhere it mattered. For years, that was not consistently true. Microsoft kept a Direct Send path in place where messages that failed those checks could still be accepted and delivered, which is not exactly what most people think they are buying when they hear “modern email security.”

The Copiers Got a VIP Entrance

Direct Send was built for printers, scanners, and older applications that needed an easy way to send mail through the tenant. Fine. Legacy workflows are real, and every environment has a few weird corners. The problem is that Microsoft left that convenience feature sitting right next to modern email authentication controls without making the tradeoff obvious enough. SPF could fail. DKIM could be missing or fail. DMARC could fail. The message could still be delivered anyway because enforcement on that path did not behave the way most admins assumed it did.

The Standards Were Not the Problem

That is why this deserves more than the usual “well, technically…” hand wave. The standards were not broken. The warnings were right there in the headers doing their job. Microsoft left a mail path in place where those warnings did not reliably turn into blocked mail. That is not attackers performing magic tricks. It is a major vendor deciding the copier needed a VIP entrance, and leaving customers to figure out the downside later.

Microsoft Took Years to Add the Off Switch

And it stayed that way for years. Security researchers were documenting the issue publicly by 2023, and reporting at the time described the same practical problem: tenants could not disable it. The feature had already been around for years before that. Microsoft did not add a tenant-level off switch until 2025 with RejectDirectSend. When the fix for a long-standing abuse path is “good news, now you can finally turn it off,” that is not a great look.

Vendor Defaults Still Need a Sanity Check

The bigger lesson is not just about Microsoft. It is that “configured” and “protected” are not the same thing, and vendor defaults deserve a sanity check now and then. If you use Microsoft 365, review the actual mail paths, the enforcement behavior, and the legacy exceptions still hanging around in your tenant. And if you want the baseline right first, our email authentication guide is a good place to start.

Sources: Microsoft Learn and Microsoft Exchange Team guidance on Direct Send and RejectDirectSend; research and reporting from JUMPSEC (2023), Black Hills Information Security, and Cisco Talos.