The editorial argues that fifteen years of email authentication infrastructure was designed to answer 'did this come from the claimed domain' rather than 'did the domain owner intend to send this content.' The Microsoft abuse exposes this design gap at scale — when authentication mechanisms unanimously say messages are legitimate, they technically are, even when weaponized.
TechCrunch's reporting frames the incident as scammers riding legitimate Microsoft 365 administrative notification channels — the same plumbing used for Message Center updates and tenant alerts. Because the messages come from Microsoft's own infrastructure with valid authentication, they sail past Defender, Proofpoint, and Mimecast inspection alike.
By submitting the TechCrunch story and driving it to 137 points, spike021 amplified the framing that this is a Microsoft infrastructure failure rather than a generic phishing campaign. The discussion thread became a clearinghouse for admins confirming the messages bypass major enterprise filters.
Admins in the HN thread report that the malicious messages cleanly pass Defender, Proofpoint, and Mimecast — the three dominant enterprise email security platforms. Their lived experience suggests vendor allowlists for trusted Microsoft infrastructure create blind spots that no amount of content scanning can close when the sender is genuinely Microsoft.
TechCrunch reported on May 21 that scammers have been abusing an internal Microsoft account to send spam and phishing links to inboxes around the world. The messages don't come from a spoofed lookalike domain or a compromised tenant — they come from Microsoft's own infrastructure, with valid SPF, DKIM, and DMARC alignment, because Microsoft is in fact the sender.
The abuse vector appears to ride on legitimate Microsoft 365 administrative notification channels — the same plumbing that delivers Message Center updates, license assignments, and tenant-level alerts to admins. Researchers tracking the campaign told TechCrunch that the spam is being routed through a Microsoft-owned mailbox that has not been locked down, allowing attackers to inject arbitrary content into messages that arrive looking exactly like a routine ops email from Redmond. The Hacker News thread on the story (137 points at time of writing) is full of admins reporting that the messages cleanly pass Defender, Proofpoint, and Mimecast inspection.
The punchline: every single email authentication mechanism the industry has built over the last fifteen years says these messages are legitimate, because by the standards those mechanisms measure, they are.
Email authentication was designed to answer one question: did this message actually originate from the domain it claims to be from? SPF, DKIM, and DMARC answer that question well. They were never designed to answer the more interesting question, which is whether the *content* of a domain-authenticated message is something the domain owner actually intended to send. That gap has always existed. What's new is the scale at which a single large provider's internal sending infrastructure can be weaponized once someone finds the seam.
This isn't the first time Microsoft has been on the receiving end of this class of bug. In 2024, researchers demonstrated that the `onmicrosoft.com` tenant naming scheme could be used to send mail that DMARC-aligned to a Microsoft-controlled domain. Last year, a separate campaign abused Microsoft's `noreply@` notification pipeline for sextortion. The pattern is consistent: any mailbox or notification channel that a major provider operates and that downstream filters implicitly trust becomes a high-value target the moment its abuse-prevention layer slips.
The structural problem is that the security industry has spent a decade telling everyone — correctly — to trust DMARC-aligned mail from large providers, and now those same providers are the most valuable phishing infrastructure on the planet precisely because of that trust. Microsoft's own security team has consistently shipped excellent guidance on email auth. But Microsoft the email-auth-evangelist and Microsoft the operator-of-a-mailbox-that-just-sent-you-spam are the same company, and from a defender's seat the second one is suddenly a much bigger problem than the first.
Community reaction on the Hacker News thread split along predictable lines. Operators who run mail at scale pointed out that this is a content-filtering problem dressed up as an authentication problem — Defender and friends already do reputation-based content analysis, and a sustained campaign from a Microsoft-owned IP should eventually degrade that reputation enough to trigger filtering. Others noted, more darkly, that 'eventually' is doing a lot of work in that sentence when the source is on every major filter's permanent allowlist.
If you operate email infrastructure or maintain detection rules, three things to do this week. First, audit any 'trust by sender domain' rules you've accumulated — explicit allowlists for `microsoft.com`, `notifications.microsoft.com`, or `*.onmicrosoft.com` are now actively harmful, not merely sloppy. Move that trust to content-based heuristics: link domains, attachment shape, whether the message asks the user to do anything actionable, whether the recipient has an actual business relationship with the claimed sender.
Second, if you run a SOC, brief your tier-one analysts that 'it passed DMARC and came from Microsoft' is no longer a sufficient reason to close a phishing ticket as benign. The phishing reports your users send in this week are not false positives just because the headers look clean. Treat reported phish from Microsoft-owned senders as a separate triage queue until the upstream issue is resolved — which, given Microsoft's response cadence on previous incidents in this category, may be measured in months rather than days.
Third, if you've built any automated remediation that uses sender reputation as a gating signal — auto-quarantine, auto-release, user-reported-phish workflows — pull the rule that says 'if sender is a top-50 trusted domain, defer to user judgment.' That rule was always a load-bearing assumption rather than a control, and the load just got heavier.
The longer-term lesson is that email authentication tells you who sent a message, not whether that message is safe, and the industry has been quietly conflating those two questions for years. Expect a wave of vendor blog posts in the next few weeks reframing 'sender reputation' as 'sender-and-content reputation,' which is what it should have been all along. Expect Microsoft to patch this specific abuse vector and decline to discuss the underlying class of bug. And expect to see this exact incident, with a different provider's name attached, sometime in the next six months — because the seam isn't unique to Redmond, it's unique to the model of letting big providers operate trusted notification channels at internet scale.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.