Scammers turned a Microsoft notification address into a spam relay. The emails pass SPF, DKIM, and DMARC.

TechCrunch security editor Zack Whittaker reported on May 21 that scammers have been sending fraud links from msonlineservicesteam@microsoftonline.com, the address Microsoft itself uses to push two-factor codes and account notifications. The emails pass SPF, DKIM, and DMARC because Microsoft’s own servers are sending them.

The mechanism is a tenant-name injection in Entra ID, the rebranded Azure Active Directory. An attacker registers a Microsoft 365 tenant, sets its display name to a fraud message, then triggers an OTP verification email aimed at a victim’s address. Microsoft’s template inserts the tenant name into the subject line. The fraud text rides out of Redmond’s authenticated mail infrastructure with no spoofing detectable at the SMTP layer.

The attack mechanic, in one paragraph

Abnormal AI’s writeup catches the technical detail TechCrunch left out. Microsoft’s account-verification email is templated as {Tenant Name} + account email verification code. Whatever string sits in the tenant’s “Name” field is what ends up in the subject. In one observed campaign the attacker set the name to: “Your Bitcoin Purchased of USD 498.95 Completed through PayPal. Reach Support Desk at 802 538 3069 to CanceI or Renew.” The capital-i in “CanceI” is the giveaway, but only if the recipient is looking.

To deliver, the attacker registers the victim’s email as an additional sign-in method in the malicious tenant’s security-info portal. That action forces Microsoft to send a verification code to confirm the new sign-in method. The verification code is real. The subject line is the attacker’s. The from-line is msonlineservicesteam@microsoftonline.com. SPF, DKIM, and DMARC all sign cleanly because Microsoft sent it.

Abnormal says the campaign spans “2,000 unique messages across over 250 abused Microsoft 365 tenants” in a burn-and-churn pattern: register the tenant, fire a batch, abandon the tenant before takedowns land.

Spamhaus, Microsoft, and the months-long lag

The Spamhaus Project posted on May 19 that it had been tracking the abuse for “several months,” and that “automated notification systems should not allow this level of customization.” Whittaker corroborates a duration measured in months across multiple email accounts.

Microsoft’s statement to TechCrunch reads: “We are actively investigating and taking action against these phishing reports to help keep customers protected. This includes further strengthening our detection and blocking mechanisms, while removing accounts that violate our Terms of Use.”

Three things stand out about the response.

• No fix to the template. Microsoft didn’t say it would constrain the tenant-name field, sanitize it before template interpolation, or move the OTP subject line to a fixed string. “Removing accounts that violate our Terms of Use” is reactive whack-a-mole, which is exactly the burn-and-churn pattern the attackers are designed around.
• No commitment on the underlying email vector. The OTP flow is going to keep firing. Until the subject line stops sourcing user-controlled text, the next attacker batch will look identical.
• The Authenticator and SMS-end story make this worse, not better. Microsoft is in the middle of phasing out SMS sign-in and pushing users toward Authenticator-app codes and passkeys. The transition trains users to treat Microsoft-sourced emails about codes as routine. A passkey-onboarding email and a fraud email now look identical at the from-line.

A few things worth knowing

Abnormal’s data set, 2,000 messages across 250-plus abused tenants, gives a sense of the surface. The actual exposed audience is larger: any Microsoft 365 user whose admin trusts mail from microsoftonline.com, which is the enterprise default.

• Why filters miss it. Most secure email gateways scale trust by sender reputation. A message from microsoftonline.com clears reputation checks on autopilot. The fraud lives in the subject and body, both of which gateways inspect more loosely when the sender is a Tier-1 service.
• Why DMARC doesn’t save you. DMARC verifies that mail claiming to be from a domain was actually sent through authorized infrastructure. It does. The check the attacker is bypassing isn’t authentication. It’s the implicit one filters apply about whether a “real” Microsoft email could carry a payload the user shouldn’t trust.
• The OTP template isn’t the only one at risk. Entra ID emails carry tenant-name interpolation in several other templates (invitations to a tenant, role-change notifications, admin alerts). Any template that includes user-controlled fields is structurally vulnerable to the same trick until Microsoft sanitizes the interpolation.

What this means for you

If you administer Microsoft 365 for an organization: warn your users now and pin a note in your internal channels. The from-line msonlineservicesteam@microsoftonline.com is no longer a reliable trust signal. Train people to ignore the subject line on any Microsoft notification that wasn’t expected, and to verify OTP codes by going to portal.microsoft.com directly rather than clicking links from the email.

If you sit on the email-filtering side: look at your gateway’s per-sender allowlist. microsoftonline.com is on most enterprise allowlists by default, which is what lets these messages skip content scanning. Tightening the rule (requiring a body scan even on Tier-1 senders) is the immediate mitigation while Microsoft figures out whether to constrain the tenant-name field.

If you’re a Microsoft 365 user with no admin role: there is no setting you can flip. The fix is at Microsoft’s template layer, and Microsoft hasn’t said when or whether it will land. Until it does, treat any Microsoft-branded email that asks you to call a phone number or click a verification link with the same skepticism you’d apply to a Gmail message from a stranger.

The deeper problem here is structural. Microsoft has trained the entire enterprise ecosystem to trust mail from its notification domains, and is now operating an infrastructure where any one of 270,000-plus active 365 tenants can inject the subject line of a high-trust template. Spamhaus put it directly: this level of customization shouldn’t exist in an automated notification system. Microsoft’s response so far is to remove accounts faster, which leaves the door open.