Scammers Have Been Sending Phishing From msonlineservicesteam@microsoftonline.com for Months—The Exact Microsoft Address That Sends Your Real Account Alerts, And Spamhaus Says Microsoft's Own Verification Systems Are Letting It Pass

Key Takeaways

• The phishing emails arrived from msonlineservicesteam@microsoftonline.com, the same address Microsoft uses to send genuine account alerts, MFA codes, and security notices.
• Spamhaus told TechCrunch the abuse pattern dates back several months and said "automated notification systems should not allow this level of customization."
• The scammers appear to have signed up new Microsoft accounts as ordinary customers and then exploited a notification mechanism that lets a tenant trigger account emails with attacker controlled content.
• The lures resemble legitimate Microsoft transactional emails: fake fraudulent transaction alerts and "you have a private message" prompts.
• The same vector has reportedly hit Betterment customers in 2026 and Namecheap customers in 2023, indicating a wider class of bug in how brand owned transactional senders verify the content they emit.

Why Is This Address Special?

msonlineservicesteam@microsoftonline.com is the canonical sender for Microsoft Online Services account notifications. If you have ever received an email titled "Microsoft account security info verification" or a code to confirm a sign in to outlook.com, that is who it came from. The address sits on a domain Microsoft owns and operates, signed with DKIM and aligned under DMARC, with an SPF record that authorizes Microsoft's transactional infrastructure to send on its behalf.

For users, the address is functionally indistinguishable from "official Microsoft." For mail clients, including Gmail, Outlook, Apple Mail, and almost every business email gateway, the address comfortably passes every authentication check. There is no signature mismatch to flag, no spoofed display name to catch, no header inconsistency to surface.

That is the entire problem. A phishing email coming from that address is delivered with the full reputation of Microsoft attached.

How Are the Scammers Using It?

Neither TechCrunch nor Spamhaus has nailed down the precise mechanism. Both organizations describe the abuse as "scammers setting up new Microsoft accounts as customers and using that access" to trigger outbound emails whose body is partly attacker controlled. The reasonable inference, given how Microsoft's transactional email pipelines are structured, is that one of the notification templates accepts user supplied content—an organization name, a transaction reference, a contact field—and that content is making it into the message body with enough freedom to embed a phishing payload.

This pattern has a name in the abuse literature: "transactional message smuggling." A legitimate notification system is induced to relay attacker content by hiding it inside a parameter that the sender's developers assumed could not damage the resulting message. The Betterment incident earlier this year worked the same way. So did the Namecheap incident in 2023, in which scammers used Namecheap's own notification address to send phishing for hours before staff manually shut down the channel.

Once the attacker has the legitimate sender in hand, no further infrastructure is needed. There is no need to register a lookalike domain, configure DKIM, season a sending IP, or wait for reputation to build. The reputation is borrowed from Microsoft in real time and on every message.

What Do the Phishing Emails Look Like?

The samples Whittaker received followed the standard Microsoft notification template, including the familiar header colors, the rounded corner button, the disclaimer footer, and the small Microsoft logo. The differences were in the body copy. Some claimed a fraudulent transaction had been flagged and prompted the recipient to click a button to dispute it. Others said a private message was waiting and offered a link to review it.

Spamhaus noted that the email quality was "crudely made"—the body text had small grammatical tells that careful readers would spot. That observation is correct and largely beside the point. A great phishing message is not what wins. A phishing message that arrives with a green checkmark from Outlook and a sender address that matches every other Microsoft email the user has ever received does not need to be especially polished. The brand verification has already done the convincing.

Why Did the Filters Not Catch It?

Gmail, Outlook, and the major secure email gateways score messages on a long list of signals. Sender authentication (SPF, DKIM, DMARC), domain reputation, IP reputation, content fingerprinting, link reputation, and behavioral signals all feed the verdict. For this campaign, every authentication signal is clean: the message is genuinely signed by microsoftonline.com and genuinely sent from a Microsoft IP. The domain reputation is, by definition, excellent.

The only signals left to catch the abuse are content based: did the body of the message look like phishing, did the links go anywhere unusual, did the call to action match the kind of transactional pattern this sender normally emits. Modern filters try, but their precision against a single sample is poor compared to the much louder signal of "this is the real Microsoft notification address." Filters generally weight authenticated reputation heavily because the alternative—aggressively scoring genuine Microsoft transactional mail as suspicious—causes too many false positives.

The campaign is an exploit of that asymmetry. The defender has been trained for years to trust the sender. The attacker is the sender.

What Should You Do About It?

A handful of practical defenses help, even when the sender address itself is not a useful signal:

• Treat a "private message waiting" or "fraudulent transaction" prompt from any Microsoft email as a trigger to open the relevant Microsoft service directly in your browser—do not click a link in the message itself.
• If a button asks you to sign in, type the destination URL by hand. The phishing URL will not match the legitimate one.
• Hover over the call to action link before clicking. The body text may match, but a phishing campaign points the link to a domain that is not microsoft.com or office.com.
• If you operate a corporate mail filter, add a custom rule that scores messages from msonlineservicesteam@microsoftonline.com against a stricter content fingerprint while Microsoft investigates.
• Report suspicious messages to Microsoft using the in product "Report phishing" action, not by replying. Microsoft's abuse team can act faster when reports include the full original headers.

The deeper lesson sits with mail filter operators and brand owned transactional senders. The same class of issue surfaced last summer with the Robinhood gmail dot trick that turned a legitimate Robinhood sender into a phishing vehicle, and earlier this month with the AppSheet abuse that hijacked 30,000 Facebook business accounts via noreply@appsheet.com. The common thread is a notification pipeline that accepts user supplied content, and a brand reputation that becomes the attacker's most valuable asset.

Until Microsoft closes the gap, the rational read on any unsolicited transactional alert—even one from microsoftonline.com—is to verify it inside the product, not through the link in the email. The sender address has stopped being a useful signal. Treat the inbox as a notification surface, not a trustworthy interaction surface, and the campaign loses most of its leverage.