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. They are also the ones most often decoded from a forum post rather than from Microsoft. That is how an afternoon disappears into fixing SPF when the problem was the sending IP.

There are two different Microsoft worlds. They block mail for different reasons, and the first job is working out which one rejected you.

Which Microsoft actually blocked me?

There are two, and almost nobody checks which one they are dealing with:

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

They run on related infrastructure. They enforce different rules.

The tell is in the NDR. A bounce from @outlook.com or @hotmail.com is the consumer side. A bounce naming the recipient's own domain plus a mail.protection.outlook.com host is the tenant side, because that is the MX target Microsoft publishes for a tenant domain1.

Our take: the 550 5.7.515 rule everyone quotes is a consumer rule. Microsoft says so in the announcement's first line2. If a business M365 tenant is blocking you, that code is not your problem.

What is 550 5.7.515, exactly?

It is the Outlook.com consumer enforcement, and Microsoft has tightened it since announcing it.

The announcement went up on 2 April 2025 and was updated on 29 April. It set the bar at domains sending more than 5,000 messages a day to Outlook.com, Hotmail and Live: SPF must pass, DKIM must pass, and DMARC must be at least p=none and aligned with either SPF or DKIM3. That page also carries two enforcement statements that contradict each other, and both are still on it. One says non-compliant mail is rejected from 5 May 2025 with this code. The next says it goes to Junk from 5 May, with rejection at a date to be announced4.

Microsoft's sender-facing page for the code settles it, and asks for more than the blog did. Messages are rejected. The trigger is 5,000 or more messages using the same domain in the From address. The domain must publish SPF and DKIM records that both pass, publish a DMARC record, and the message must pass DMARC validation5. That is how the page read on 5 September 2026.

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

"Aligned with either SPF or DKIM" and "SPF and DKIM must both pass" are two different requirements. Build to the second one.

Google drew the same line first. Its bulk-sender rules took effect on 1 February 2024, at the same 5,000 a day6. Microsoft followed fifteen months later.

Two things people get wrong:

• The threshold counts the domain in the From address7, not your IP and not your ESP account. Splitting one domain's mail across two IPs splits nothing. A 5.7.515 at low volume usually means your authentication is broken.
• It covers Outlook.com, Hotmail and Live only8. A company's Microsoft 365 tenant runs on its own filtering.

What to do: publish SPF and DKIM and confirm both pass. Then publish DMARC and confirm the message passes it. A record that exists but does not align still fails. Run a DMARC check and read the alignment verdict, not the presence of a record.

Then why is M365 blocking my mail to a business?

Because the rejection happens before the mailbox is involved, and often before anything in your message is read.

Microsoft 365 rejects at the service perimeter, in the layer called Exchange Online Protection. Microsoft's own description of an invalid recipient is explicit about the ordering: "the service blocks the message before filtering even occurs"9. So the most common business-side bounce is not an auth code at all:

550 5.4.1 Recipient address rejected: Access denied

Microsoft's master NDR list carries 5.4.1 twice, with two different meanings10:

5.4.1  Relay Access Denied                    server or DNS misconfiguration
5.4.1  Recipient address rejected: Access…    the recipient's address doesn't exist

The second is the one you meet. The NDR is generated when directory-based edge blocking rejects a message because the recipient's address is invalid, and every fix listed is recipient-side: check the spelling, resync the accepted domain, reset the proxy address11. Edge blocking is on by default. If every recipient for a domain sits in Exchange Online, it is already running and nobody switched it on12.

Neither documented meaning is about reputation, and we found no Microsoft page that gives 5.4.1 a reputation path. Our own experience does not fit either row. The 5.4.1-with-clean-auth cases that reach us trace back to a freshly rented VPS IP the previous tenant had already burned. No spelling fix helps. Delisting does. We cannot observe Microsoft's side to prove the mechanism, so treat that as a working hypothesis, not a third documented meaning.

One test separates the recipient case from the rest, and it takes a minute. Send to a second address you know is valid at the same tenant. If every recipient there bounces, the problem is your sending IP or domain. If only one bounces, the address is the problem, and edge blocking is doing exactly what Microsoft documents. Microsoft's own troubleshooting page opens with the same test13. Run it before you touch anything.

The gap between the documented cause and the reported one is what catches people. You run every checker, everything passes, and Microsoft still says access denied. The checkers measure identity. This rejection may not be about identity. 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.

Why is most of what you'll read about the 5.7.2x codes wrong?

Because it quotes the IANA registry and calls it Microsoft, and because it hands Microsoft a code Microsoft does not list.

550 5.7.23 is not a code Microsoft sends you. It is the NDR you get when Exchange Online relayed your message outbound and the destination server rejected it on SPF. Every fix on Microsoft's page sits inside your own tenant: check your SPF record, provision your domains, add your on-premises IPs, and check whether the message went through the High Risk Delivery Pool, which will not pass SPF anywhere14.

The .7.25 and .7.26 codes Microsoft documents are IPv6 only. They apply to anonymous inbound mail over IPv6, which an organisation has to opt into. Miss the PTR record and you get 450 4.7.25 Service unavailable, sending IPv6 address [...] must have reverse DNS record. Fail both SPF and DKIM and you get 450 4.7.26 Service unavailable, message sent over IPv6 [...] must pass either SPF or DKIM validation.15

The 4.7.25 deferral has a permanent twin. Microsoft's master NDR list carries 5.7.25 Access denied, the sending IPv6 address [...] must have a reverse DNS record16. So a missing PTR over IPv6 can defer you or bounce you. It is still IPv6 that is being talked about, either way.

5.7.26 is not on that list at all17. The 550-5.7.26 This mail is unauthenticated string that circulates as a Microsoft bounce is Gmail's, and Microsoft's own outbound-deliverability post quotes it as such, alongside a Yahoo deferral18. Google documents three separate texts under 5.7.26: unauthenticated sender, an SPF -all that failed, and a DMARC policy rejection19.

The meanings you will find everywhere, "SPF validation failed", "Reverse DNS validation failed", "Multiple authentication checks failed", are the IANA registry's, standardised in RFC 737220. They are the correct general meaning of each code. They do not describe when Exchange Online emits it. The gap has sent people to fix reverse DNS on an IPv4 host Microsoft never asked about.

One registry line is load-bearing. X.7.26 means more than one authentication check failed, and in the RFC's own words, "the particular mechanisms that failed are not specified"21. Read the sentence beside the code before deciding it means DMARC.

What does Microsoft check that Gmail shrugs at?

Less than the folklore says. The honest difference is in what each of them publishes.

Google names a number you can be measured against: keep the spam rate reported in Postmaster Tools below 0.30%22. Microsoft publishes no equivalent figure for Exchange Online. It publishes two hard gates instead, and neither is about your content.

Our own pattern-matching says Microsoft is harsher than Gmail on a cold or recycled sending IP. Neither filter is observable from outside, so that is an assumption, not a rule.

The two gates:

• The PTR requirement is real, and narrower than it is usually stated. Microsoft's documented rejection for a missing reverse-DNS record covers anonymous inbound mail over IPv6, as a 450 deferral or a permanent 5.7.2523. Over IPv4, Microsoft publishes no rule saying a missing PTR rejects you. Set one anyway before sending from a new IP. Check it with the reverse DNS tool and confirm the MX picture while you are there. Just do not spend a day on IPv4 reverse DNS because of a code that was about IPv6.
• The delist paths are separate, and easy to mix up. A tenant block reads 550 5.7.606-649 Access denied, banned sending IP, and goes to the Office 365 Anti-Spam IP Delist Portal at sender.office.com. A 5.7.511 cannot use that portal; Microsoft asks you to forward the NDR to [email protected] and says it will come back within 48 hours. Consumer-side Outlook.com blocks use a separate Microsoft support request form, linked from the bottom of the same page24. Microsoft's delisting page never routes you through SNDS for any of the three, so do not start there. None of them 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, stop editing DNS. Run the second-recipient test. If the whole tenant bounces, go and find out what your sending IP has been doing.

How do I read the NDR without guessing?

Start with the component name, then the exception, then the code. The code is the least informative of the three.

Microsoft NDRs prefix the failure with an internal component. Three of them turn up constantly, each shown here in Microsoft's own wording:

RESOLVER   recipient resolution   550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found
STOREDRV   the mailbox store      554 5.2.0 STOREDRV.Deliver.Exception:...
QUEUE      transport / queueing   550 4.4.7 QUEUE.Expired; message expired

The first comes from Microsoft's page for 550 5.1.125, the third from its page for 550 4.4.726.

Take a bounce like this:

Diagnostic-Code: smtp; 554 5.2.0
  STOREDRV.Deliver.Exception:ObjectNotFoundException.MapiExceptionNotFound;
  Failed to process message due to a permanent exception with
  message Cannot get ID from name

STOREDRV puts it in the mailbox store. 5.2.0 is registered as "Other or undefined mailbox status", glossed as "the mailbox exists, but something about the destination mailbox has caused the sending of this DSN"27. That narrows nothing. The exception name is the whole diagnosis: Microsoft's page for that exact string says the cause is a mailbox with Clutter enabled but no Clutter folder, and the fix is to turn Clutter off for that user28. No amount of staring at 5.2.0 gets you there.

5.7.13 is the code most often quoted with a borrowed meaning. Microsoft documents 550 5.7.13 in Exchange Online as a public folder set to reject external or unauthenticated senders29. The IANA registry defines X.7.13 as a sender's account disabled after a successful authentication, and pairs it with basic code 525, not 55030. Two different failures sharing three digits. Either way it is the receiving end, and nothing to do with your DNS.

Paste the whole bounce into the Microsoft bounce decoder and it maps the code, the component and the fix in one pass.

A Microsoft NDR looks like a stack trace on purpose. Ignore the [BeginDiagnosticData] block, find the component name and the exception after it, 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 how the receiving Microsoft server graded SPF, DKIM and DMARC on that message. That part still works the way the old guides say.

The SCL part of those guides is out of date, including on pages still being published. Microsoft's current page says that in cloud organisations the SCL value no longer determines whether filtering called a message spam or high confidence spam, and does not determine the action taken. The same value can appear on messages with different verdicts31. Even a mail flow rule asking for a filtering bypass may not stamp -132. On on-premises Exchange, including hybrid delivery to on-premises mailboxes, SCL still means what you remember33. In the cloud, read CAT for which filter caught it and DIR for direction, both inside X-Forefront-Antispam-Report34.

Drop a raw message into the email header analyser. It reorders the Received chain into delivery order and puts those verdicts in plain English.

So what do I actually do about it?

Work the problem in order, rather than editing DNS on reflex:

• Identify which Microsoft it is. Consumer (outlook.com) or tenant (protection.outlook.com). That decides everything below.
• Read the code, not the vibe. 5.7.515 is the consumer high-volume rule. 5.7.23 is your own tenant's outbound SPF. 4.7.25 and 5.7.25 are IPv6 reverse DNS, deferred or permanent. 5.4.1 decides nothing on its own. They are not interchangeable.
• If it is 5.7.515, publish SPF and DKIM so both pass, publish DMARC, then check that the message passes DMARC, not merely that the records exist.
• If it is 5.4.1 with auth passing, test a second address at the same tenant. A whole tenant bouncing points at your sending IP: check it against the blocklists that actually matter with the blacklist checker, fix the behaviour, then take the delist route that matches your code. One address bouncing means the address.
• If it is 4.7.25 or 5.7.25, you are sending over IPv6 from an address with no PTR record. Fix reverse DNS on the IPv6 address, or send over IPv4.
• Read a real header from an affected message. CAT tells you which filter caught it; SCL no longer does.

Most Microsoft blocking comes down to a handful of specific things. Name the component and the exception, and you have named the fix.

If you are still sitting at p=none and Microsoft's high-volume rule has just started biting, the next move is our walkthrough on going from DMARC p=none to p=reject without breaking real mail. When the rejection is a plain SMTP bounce rather than silent junking, the bounce decoder tells you whether it is you or them, and what a bounce code actually tells you is the full guide to reading provider rejection codes.

Run a free check on your domain.

What this article was checked against

1. The MX target Microsoft publishes for a tenant domain: <MX token>.mail.protection.outlook.com. Page dated 26 June 2026. — External DNS records for Microsoft 365 ↩
2. The rule applies to Outlook.com, the consumer service, "which is supporting hotmail.com live.com and outlook.com consumer domain addresses" — the announcement's opening line. — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders ↩
3. Posted 2 April 2025, updated 29 April. More than 5,000 emails per day; SPF "Must Pass", DKIM "Must Pass", DMARC "At least p=none and align with either SPF or DKIM (preferably both)". — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders ↩
4. The two contradictory paragraphs, both still on the page as read on 5 September 2026: "we have made a decision to reject messages that don't pass the required authentication requirements... This change will state taking effect on May 5th as originally stated", followed by "After May 5th, 2025, Outlook will begin routing messages from high volume non-compliant domains to the Junk folder... NOTE: that in the future (date to be announced), non-compliant messages will be rejected". — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders ↩
5. Microsoft's sender-facing page for the code: messages are rejected; both SPF and DKIM checks must pass, a DMARC record must be published, and messages must pass DMARC validation. Read 5 September 2026. — Fix NDR error "550 5.7.515" in Outlook.com ↩
6. Gmail's bulk-sender tier: more than 5,000 messages a day to Gmail accounts, SPF and DKIM plus DMARC, from 1 February 2024. — Email sender guidelines (Google) ↩
7. The threshold is counted per domain in the From address: senders reaching "5,000 or more email messages to Microsoft consumer email services" using "the same domain" in the From address. — Fix NDR error "550 5.7.515" in Outlook.com ↩
8. Scope is the consumer service only — Outlook.com, Hotmail and Live — not Microsoft 365 tenants. — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders ↩
9. The ordering, verbatim: "If the address doesn't exist, the service blocks the message before filtering even occurs, and a non-delivery report... is returned to the sender." — Use Directory-Based Edge Blocking in Exchange Online ↩
10. The master list carries two 5.4.1 rows: Relay Access Denied ("Mail server or DNS misconfiguration causes this error") and Recipient address rejected: Access denied ("The recipient's address doesn't exist"). Neither mentions reputation. Page dated 24 August 2026. — Email nondelivery reports and SMTP errors in Exchange Online ↩
11. "The NDR is generated when directory-based edge blocking in Microsoft Exchange Online blocks an incoming email message because the recipient's email address is invalid." Every listed fix is recipient-side; the page mentions IP reputation nowhere. The learn.microsoft.com URL previously cited here now 301s twice; this is where it lands. — NDR error 550 5.4.1 "Recipient address rejected: Access denied" ↩
12. "If all recipients for your domain are in Exchange Online, DBEB is already in effect, and you don't need to do anything", and the NDR it returns is 550 5.4.1 Recipient address rejected: Access denied. — Use Directory-Based Edge Blocking in Exchange Online ↩
13. The one-address-or-everyone test is Microsoft's own second troubleshooting step: "Determine if the issue affects one recipient or everyone in the domain". — NDR error 550 5.4.1 "Recipient address rejected: Access denied" ↩
14. 5.7.23 is what a sender in a Microsoft 365 tenant receives when the destination rejected the outbound message on SPF: "The Diagnostic information for administrators section in the bounce message will contain the original error message when Office 365 tried to send the message to the external email server or service." Includes the High Risk Delivery Pool fix. Page dated 10 August 2026. — Fix NDR error 5.7.23 in Exchange Online ↩
15. Both error strings verbatim, both 450, both scoped to anonymous inbound email over IPv6 after an organisation opts in: "450 4.7.25 Service unavailable, sending IPv6 address [2a01:111:f200:2004::240] must have reverse DNS record." and "450 4.7.26 Service unavailable, message sent over IPv6 [2a01:111:f200:2004::240] must pass either SPF or DKIM validation." — Mail flow in Microsoft 365 — Support for anonymous inbound email over IPv6 ↩
16. The permanent form, verbatim from the same table: 5.7.25 | Access denied, the sending IPv6 address [2a01:111:f200:2004::240] must have a reverse DNS record, described as "The sending IPv6 address must have a reverse DNS record to send email over IPv6." — Email nondelivery reports and SMTP errors in Exchange Online ↩
17. Searched the full code table on 5 September 2026: 5.7.23, 5.7.25 and 5.7.13 each appear; 5.7.26 does not appear anywhere on the page. A negative, so it is stated as what we searched and where. — Email nondelivery reports and SMTP errors in Exchange Online ↩
18. Microsoft quoting the string as a receiver's, not its own: "These issues usually manifest in the form of Non-Delivery Reports (NDR) such as: Authentication: 550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users and has been blocked." — Authenticate outbound email to improve deliverability (Exchange Team Blog) ↩
19. Google's three documented 5.7.26 texts (unauthenticated sender; an SPF -all policy that failed; "Unauthenticated email from domain-name is not accepted due to domain's DMARC policy"), and its 5.7.25 text: "This message was blocked because the sending IP address doesn't have a PTR record, or the forwarding DNS entry doesn't reference the sending IP address." — Gmail SMTP errors and codes (Google) ↩
20. The registered sample texts for X.7.23, X.7.25 and X.7.26, and that all three are RFC 7372 registrations rather than vendor inventions. — IANA SMTP Enhanced Status Codes registry · RFC 7372 ↩
21. X.7.26 registration: "This status code is returned when a message failed more than one message authentication check, contrary to local policy requirements. The particular mechanisms that failed are not specified." — RFC 7372 §3.4 ↩
22. Google's published spam-rate ceiling for bulk senders: keep the rate reported in Postmaster Tools "below 0.30%". Microsoft publishes no equivalent figure for Exchange Online, which is why this article gives none. — Email sender guidelines (Google) ↩
23. The PTR requirement and its 450 deferral are documented only for anonymous inbound mail over IPv6. Microsoft publishes no equivalent IPv4 rejection rule; the absence is the finding, and it is why this article no longer claims one. — Mail flow in Microsoft 365 — Support for anonymous inbound email over IPv6 ↩
24. The portal's proper name and scope: "we provide the Office 365 Anti-Spam IP Delist Portal page at https://sender.office.com" for 550 5.7.606-649; "If you receive the error 5.7.511... You can't use the delist portal", forward the NDR to [email protected] and Microsoft responds within 48 hours; and "The delisting form for Outlook.com, the consumer service can be found here", a separate Microsoft support request form. — Remove yourself from the blocked senders list and address 5.7.511 errors ↩
25. The RESOLVER string verbatim, in an Exchange Online NDR: #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##. — NDR error 550 5.1.1 RESOLVER.ADR.ExRecipNotFound ↩
26. The QUEUE string verbatim, listed under "Diagnostic information for administrators": #550 4.4.7 QUEUE.Expired; message expired ##, after 24 hours of failed delivery attempts. Page dated 10 August 2026. — Fix NDR error 550 4.4.7 in Exchange Online ↩
27. X.2.0 "Other or undefined mailbox status": "The mailbox exists, but something about the destination mailbox has caused the sending of this DSN." Registered by RFC 3463. — IANA SMTP Enhanced Status Codes registry ↩
28. The full 554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException.MapiExceptionNotFound; ... Cannot get ID from name string, and the cause: "This issue occurs if the Clutter feature is enabled for the user but the Clutter folder is missing in the user's mailbox." — NDR error 554 5.2.0 STOREDRV.Deliver.Exception ↩
29. "You'll see this automated notification when the recipient is a public folder that's configured to reject messages from external senders (senders from outside the organization)." Page dated 10 August 2026. — Fix NDR error 5.7.13 or 5.7.135 in Exchange Online ↩
30. X.7.13 "User Account Disabled", associated basic status code 525: "This error code occurs after a successful authentication to a disabled account." — IANA SMTP Enhanced Status Codes registry ↩
31. "The value doesn't determine whether spam filtering identifies a message as Spam or High confidence spam, and it doesn't determine the action taken on the message... the same SCL value can appear on messages with different verdicts." Page dated 3 August 2026. — Spam confidence level (SCL) in Microsoft 365 ↩
32. "But even when a rule requests a bypass, the actual SCL value stamped on the message might not be -1 (for example, 0 or 1 to indicate it was evaluated and found not to be spam)." — Spam confidence level (SCL) in Microsoft 365 ↩
33. "The main purpose of the SCL value is to support on-premises Exchange servers, including hybrid environments where cloud-filtered messages are delivered to on-premises mailboxes." — Spam confidence level (SCL) in Microsoft 365 ↩
34. "CAT (category) identifies what filtered the message, and DIR (directionality) indicates whether the message was internal", both stamped in the X-Forefront-Antispam-Report header. — Spam confidence level (SCL) in Microsoft 365 ↩