In February we wrote about a real Microsoft email being used for a scam, a genuine message, from genuine Microsoft infrastructure, doing a fraudster’s work (“A Real Microsoft Email Is Being Used for a Scam – Here’s How It Works and Why It’s So Hard to Stop“, 5 February). At the time we said the hardest phish to stop is the one that isn’t fake.
Three months on, the problem hasn’t been fixed. It has escalated.
What’s happening
TechCrunch’s Zack Whittaker reported on 21 May that scammers are exploiting a loophole that lets them send spam from a legitimate internal Microsoft email address, one normally used to deliver genuine account alerts. These are not lookalike domains or spoofed headers. The mail originates from Microsoft, from an address recipients have been conditioned over years to trust, because trusting it is usually correct.
More telling is what happened after the story was first reported: nothing much. Whittaker noted that he continued receiving several similarly structured emails; spammy subject lines, links to dubious sites across different email accounts in the following week, suggesting Microsoft does not yet have the abuse contained. Microsoft provided a statement after publication, but the traffic kept flowing.
To be clear it isn’t just Microsoft. Users commenting on social media report other companies’ legitimate addresses being abused the same way, indicating a class of problem rather than a single incident. There is precedent, too: in 2023, attackers abused an email account operated by Namecheap to push credential-phishing mail from the registrar’s own sending system.
The mechanics of “legitimate” abuse
The exact loophole hasn’t been publicly detailed, but the pattern is one this industry knows well. Plenty of automated notification systems include content a third party can influence; a name field, a note, a shared-document title, a comment. Find a notification flow that echoes attacker-supplied text and includes a link or renders one, and you’ve turned a trusted transactional stream into a delivery mechanism. The industry refers to these attack vectors as “Inbound Input Reflection” or “Transactional Loophole Exploitation”.
The Google Forms and Google Tasks notification abuse we’ve covered previously worked on the same principle. So, in effect, did February’s Microsoft scam.
From a filtering perspective this is close to the worst case. The sending address is real, so it passes SPF and DKIM with full alignment and an enforced DMARC policy, Microsoft’s own! The sending IPs carry years of pristine reputation. And no mailbox provider is going to junk Microsoft’s account-security alerts wholesale; those messages are among the most operationally important mail on the internet. The attacker is hiding inside traffic that must be delivered.
The lesson for everyone who runs transactional mail
It’s tempting to file this under “Microsoft’s problem”. It isn’t. If your platform sends notifications, invites, receipts, alerts, shares, comments containing any text a user can type, you are running the same risk on a smaller stage. The abuse economy is methodical: as the SES credential-harvesting campaigns we covered this week show, attackers now systematically hunt for legitimate sending channels rather than building their own.
Three questions worth putting to your own product and deliverability teams this week. First, which of your transactional templates render user-supplied content, and is that content length-limited, link-stripped and sanitised? Second, do you rate-limit and anomaly-monitor your notification streams the way you monitor marketing sends, because attackers exploiting a notification loophole show up as a volume and pattern shift long before the complaints arrive? Third, who in your organisation would actually notice if your most trusted address started carrying someone else’s payload? At Microsoft, going by the past three weeks, the answer appears to be: journalists.
There’s a reputational dimension senders should sit with as well. Every incident like this erodes the heuristic that “mail from a known address is safe” the same heuristic that legitimate transactional mail depends on for its near-perfect inbox placement. The companies whose notification systems get hijacked aren’t just leaking spam; they’re spending down trust the entire ecosystem relies on.
The Kali365 device-code kits, the SES key harvesting, and now this: the through-line of 2026 so far is that attackers have stopped trying to look legitimate and started simply being legitimate — borrowing real addresses, real infrastructure, real authentication.
The industry’s trust signals were built to answer “is this really from who it says?” That question now comes back “yes” more often than is comfortable, on mail nobody should trust.
If you receive suspicious mail from a genuine vendor alert address, report it to the vendor directly and via your mailbox provider’s reporting tools, these incidents are typically only contained once the volume of reports forces the issue.
