"Why Microsoft 365 and Outlook are blocking your mail in 2026"

Your client's invoice bounced the day before the deadline. The rejection came back stuffed with RESOLVER, STOREDRV, a 550 5.7.something, and a wall of [BeginDiagnosticData] gibberish. You forwarded it to three people. Nobody could read it either.

Microsoft NDRs are the most intimidating bounces in email, and 2025 made them more common, not less. Two separate enforcement changes landed, they hit different mailboxes for different reasons, and the codes look almost identical. Read the wrong one and you'll spend a day fixing SPF when the actual problem was your sending IP's reputation.

Short version: there are two different Microsoft worlds, they block mail for different reasons, and the first job is working out which one rejected you. This post decodes the codes and points you at the right fix.

Which Microsoft actually blocked me?

This is the question that everything else hangs on, and almost nobody asks it first.

There are two:

Outlook.com / Hotmail / Live   →  consumer mailboxes
Microsoft 365 / Exchange Online →  business tenants

They run on related infrastructure but enforce different rules. A rejection from @outlook.com or @hotmail.com is the consumer side. A rejection landing at a company that runs Microsoft 365 comes through *.mail.protection.outlook.com and follows tenant rules.

The tell is in the NDR. Look at the recipient domain and the reporting host. A bounce from @outlook.com or @hotmail.com is a consumer-side block. A bounce that names the recipient's own domain plus a protection.outlook.com host is a tenant-side (Microsoft 365) block, and it runs on different rules.

Our take: the 2025 headline change (the 550 5.7.515 high-volume rule everyone quotes) is a consumer rule. If you're being blocked delivering to a business M365 tenant, that code is almost certainly not your problem, and chasing it wastes the afternoon.

What is 550 5.7.515, exactly?

It's the Outlook.com consumer enforcement, and it's narrower than the panic suggests.

Since 5 May 2025, Microsoft requires SPF, DKIM and DMARC from any sender pushing more than 5,000 messages a day to Outlook.com, Hotmail and Live mailboxes. DMARC has to be at least p=none and aligned with either SPF or DKIM. Fail that, and mail first routes to Junk, then gets rejected outright:

550 5.7.515 Access denied, sending domain [example.com]
does not meet the required authentication level.

This mirrors the Gmail and Yahoo bulk-sender rules from February 2024. Same idea, fifteen months later. As of mid-2026 the 5,000-a-day threshold hasn't moved, so if you send at any real volume to consumer Outlook addresses, this still applies to you.

Two things people get wrong about it:

• The 5,000/day threshold is per sender to consumer mailboxes. If you're a small business emailing a handful of Hotmail contacts, you're nowhere near it. A 5.7.515 on low volume usually means your DMARC is genuinely broken, not that you tripped the volume gate.
• It only applies to Outlook.com/Hotmail/Live. Delivery to a company's Microsoft 365 tenant is governed by that tenant's own filtering, not this rule.

What to do: publish SPF, enable DKIM signing, and publish a DMARC record aligned to one of them. Then confirm all three actually pass and align. A record that exists but doesn't align still fails the check. Run the domain through the M365 checker or a straight DMARC check to see the alignment verdict, not just "a record is present."

Then why is M365 blocking my mail to a business?

Because tenant filtering runs on reputation first, and reputation is not a DNS record.

Microsoft 365 rejects at the edge, in the layer called Exchange Online Protection (EOP), often before it even looks at your content. The most common business-side bounce is not an auth code at all:

550 5.4.1 Recipient address rejected: Access denied

Despite the wording, this frequently means Microsoft blocked your IP or domain on reputation, not that the recipient address is wrong. Exchange Online weighs the sending IP's history heavily, and a poor score gets you refused at the front door with every SPF, DKIM and DMARC tick still green. Most of the 5.4.1-with-clean-auth cases we see trace back to a freshly rented VPS IP that the previous tenant already burned.

That's the part that catches people. You run every checker, everything passes, and Microsoft still says access denied, because the checkers measure identity, and this rejection is about reputation. We wrote a whole piece on why passing every check still lands you in spam; the Microsoft version of that story is usually a poisoned IP.

The other business-tenant codes you'll actually see:

550 5.7.23   SPF validation failed (your IP isn't in the SPF record)
550 5.7.26   DMARC / unauthenticated: auth didn't pass or align
550 5.7.25   Reverse DNS (PTR) validation failed

Each points somewhere specific. 5.7.23 is an SPF problem. 5.7.26 is alignment. 5.7.25 means your sending IP has no valid PTR record, which self-hosters hit constantly.

What does Microsoft check that Gmail shrugs at?

Sending IP reputation, far more aggressively, and earlier in the conversation.

Gmail leans hard on domain reputation and recipient engagement: did people open it, did they mark it spam. Microsoft does that too, but it also gatekeeps on the IP at the SMTP edge. A cold VPS IP, a shared IP with a bad neighbour, or an IP with no PTR record gets a colder reception from Exchange Online than from Gmail, and it happens before content ever enters the picture.

Two practical consequences:

• PTR matters more to Microsoft. A missing or mismatched reverse-DNS record that Gmail tolerates can earn you a hard 5.7.25 from Microsoft. Check it before you send anything from a new IP with the reverse DNS tool, and confirm the MX picture while you're there.
• The delist path is separate. Microsoft runs its own portals. For consumer-side (Outlook.com) IP blocks, submit through the Smart Network Data Services delist form; for tenant reputation, the sender support portal is the route. Neither is a DNS fix. You delist, then you stop doing whatever got you listed.

Our take: if your mail passes auth and still bounces 5.4.1 from Microsoft, stop editing DNS. It's a reputation problem. Find out what your sending IP has been doing.

How do I read the NDR without guessing?

Start with the component name, then the code, then the diagnostic text.

Microsoft NDRs prefix the failure with an internal component:

RESOLVER   →  routing / addressing (recipient, forwarding, rules)
STOREDRV   →  the mailbox store (delivery, quota, disabled account)
QUEUE      →  transport / queueing

So a bounce like this:

Diagnostic-Code: smtp; 550 5.7.13
  STOREDRV.Deliver.Exception:AccountDisabledException...

is STOREDRV (the mailbox store) plus 5.7.13 (account disabled). The recipient's account is off. Nothing to do with your DNS at all. That one's on the receiving end.

Paste the whole bounce into the Microsoft bounce decoder and it maps the code, the component and the fix in one pass, instead of you pattern-matching hex against forum posts.

A Microsoft NDR looks like a stack trace on purpose. Ignore the [BeginDiagnosticData] block, find the 5.x.x code and the component name, and the whole thing collapses into one plain sentence.

Can I see what the receiver actually decided?

Yes. Read the headers of a message that got through, or one that bounced with a full report.

The Authentication-Results line shows exactly how the receiving Microsoft server graded SPF, DKIM and DMARC on that specific message, and Microsoft's X-Forefront-Antispam-Report and SCL (Spam Confidence Level) headers show how close to the block line you sat. An SCL of 5 or higher is being treated as spam; -1 means it was allow-listed.

Drop a raw message into the email header analyser. It reorders the Received chain into delivery order and surfaces those verdicts in plain English, so you're reading Microsoft's actual decision instead of guessing at it.

So what do I actually do about it?

Work the problem in the right order instead of editing DNS on reflex:

• Identify which Microsoft it is. Consumer (outlook.com) or tenant (protection.outlook.com). This decides everything below.
• Read the code, not the vibe. A 5.4.1 is reputation. A 5.7.23 is SPF. A 5.7.26 is alignment. A 5.7.515 is the consumer high-volume rule. They are not interchangeable.
• If it's 5.7.515, publish and align SPF + DKIM + DMARC, then verify alignment on the M365 checker, not just that records exist.
• If it's 5.4.1 with auth passing, it's your sending IP's reputation. Check the IP against blocklists with the blacklist checker, fix the underlying behaviour, then use the Microsoft delist portal.
• If it's 5.7.25, your sending IP has no valid PTR. Fix reverse DNS before anything else.
• Read a real header from an affected message to confirm what Microsoft graded and how close to the spam line you were.

Most Microsoft "blocking" turns out to be one of five specific things wearing the same scary costume. Name the code, and you've named the fix.

If you're still sitting at p=none and Microsoft's high-volume rule just started biting, the next move is our walkthrough on going from DMARC p=none to p=reject without breaking real mail. And when the rejection is a plain SMTP bounce rather than silent junking, the bounce decoder tells you whether it's you or them before you start guessing. A full guide to reading provider rejection codes is coming next in this series.

Run a free check on your domain.