Microsoft 365 NDR: why wasn't my message delivered, and how do I fix it?

"Your message wasn't delivered" is one of the most common tickets an email admin sees. Microsoft 365 explains every bounce in a structured report, and the code inside usually tells you exactly who must fix what. The trick is knowing which line to read.

This guide shows how to read a Microsoft 365 non-delivery report, what the common codes mean, and the order to troubleshoot them in. For bounces on mailing lists, see hard bounce vs soft bounce.

What is a Microsoft 365 NDR?

A non-delivery report (NDR), also called a bounce, is the message Microsoft 365 sends back when an email couldn't be delivered. Microsoft says NDRs include "an error code that indicates the reason that your message wasn't delivered, solutions to help you get your email delivered, a link to more help on the web, and technical details for administrators" (Microsoft Learn).

Newer NDRs have these parts:

Older-style NDRs split this into User information and Diagnostic information for administrators. The second part is where the answer is.

How do you read the diagnostic information?

Here is the example Microsoft uses, shortened:

Delivery has failed to these recipients or groups:
ronald@contoso.com
Your message wasn't delivered due to a permission or security issue. ...
The following organization rejected your message: mail.contoso.com.

Diagnostic information for administrators:
Generating server: alpineskihouse.com
ronald@contoso.com
mail.contoso.com #<exchange.contoso.com #5.7.1 smtp;530 5.7.1 Client was not authenticated> #SMTP#

Read three things:

1. Generating server. The server that wrote the NDR. If no remote server is listed, this server also rejected the message.
2. Remote server. The server that refused the message, here mail.contoso.com. Microsoft's conclusion for this example: "the administrators at contoso.com are responsible for understanding and fixing the problem."
3. Enhanced status code and SMTP response. Here 5.7.1 and 530 5.7.1 Client was not authenticated.

The enhanced status code follows RFC 3463, in the form class.subject.detail. Microsoft summarizes it: "a 5.x.x code indicates a permanent error, and a 4.x.x code indicates a temporary error." The middle digit narrows the area: 1 for addressing, 4 for network and routing, 7 for security or policy. Paste the whole bounce into our SMTP Error Code Lookup for a plain-English reading.

The Original message headers at the bottom help too. Microsoft points to To for typos, Received for the path, and Received-SPF for authentication.

What do the common Microsoft 365 NDR codes mean?

These are the codes admins meet most in everyday business mail, with Microsoft's text, quoted as examples, from its NDR reference at the time of writing (October 2026):

A few notes on the rows that need more than a lookup:

• 5.1.1 is usually a typo. If the address is right and the recipient is in your own organization, Microsoft says to remove the address from the sender's Outlook recipient cache and write a new message, because "resending the original message causes the same failure."
• 5.1.8, 5.1.90 and 5.2.2 can mean the account was compromised. Microsoft says 5.1.90 and 5.2.2 "could indicate that the account was compromised and is being used to send spam." Follow unblocking a user restricted from sending before you unblock anyone.
• 5.7.509 and 5.7.23 are authentication problems with your domain, not the recipient's. Start with why DMARC fails.
• 5.7.703 surprises people because it's self-inflicted. Microsoft notes "the entire message is blocked for all internal and external recipients of the message, even if only one recipient email address or domain is defined in a block entry" (Microsoft Learn). Review the entry in the Tenant Allow/Block List.

How do you troubleshoot a Microsoft 365 NDR step by step?

1. Get the full NDR. Ask the user to forward the bounce as an attachment, or open it in Outlook and copy everything, including the diagnostic section. A screenshot of the first line isn't enough.
2. Find who rejected it. Read the remote server and the generating server. If the remote server belongs to the recipient's organization, the fix is probably on their side or in your authentication.
3. Look up the code. Use the table above or the SMTP Error Code Lookup. A 4.x.x code means wait or watch; a 5.x.x code means something must change.
4. Confirm in message trace. In the Exchange admin center, go to Mail flow > Message trace, or run Get-MessageTraceV2 -SenderAddress user@yourdomain.example -Status Failed -StartDate 10/20/2026 -EndDate 10/22/2026. Message trace keeps 90 days of data, queried 10 days at a time (Microsoft Learn). Our message trace guide explains the results.
5. Check authentication if the code is 5.7.x. Send a test message to an outside mailbox and read the Authentication-Results header in the Email Header Analyzer. Check your records with the SPF Checker and DMARC Checker.
6. Run Microsoft's diagnostic. Microsoft 365 admins can paste the NDR code into the automated NDR diagnostic linked from Microsoft's NDR article, which opens in the Microsoft 365 admin center. It isn't available in Government, 21Vianet or Germany clouds.
7. Fix, then send a new message. Don't just resend the old one, especially for 5.1.1.

What causes Microsoft 365 NDRs, from the simplest fix up?

Work through causes in this order, because the early ones are quick to rule out:

• A wrong or retired address. Codes 5.1.1 and 5.1.10. Check spelling, ask whether the person left, and clear the Outlook autocomplete entry.
• A restriction on the recipient. Codes 5.7.1, 5.7.124 and 5.7.133 to 5.7.136. Groups and some mailboxes accept only listed or internal senders. Only the group owner or their admin can change that; see restricting who can email distribution lists for how it's set.
• Your domain fails authentication. Codes 5.7.23 and 5.7.509. Common after adding a new sending service that isn't in SPF or doesn't sign with DKIM.
• Your own tenant's settings. Codes 5.7.520 (forwarding blocked) and 5.7.703 (Tenant Allow/Block List).
• Sending limits or a restricted account. Codes 5.1.8, 5.1.90, 5.2.2 and 5.7.233. The Exchange Online recipient rate limit is 10,000 recipients per day per mailbox (Microsoft Learn). When an ordinary user hits these limits, check for a compromised account before anything else.
• Server and routing problems. Codes 4.4.7, 5.4.14 and 5.7.57. These come from connectors, devices, MX records or loops, often after a migration.

Got an NDR for a message you never sent?

That's usually backscatter: a spammer forged your address, and the receiving server bounced the message to you. Check the original headers in the NDR. If the message never left your tenant, it won't appear in message trace. Our guide to backscatter bounce messages explains what to do, and DMARC at p=reject makes your domain less attractive to forge.

Next steps

• Save the table above, or bookmark the SMTP Error Code Lookup, for the next bounce ticket.
• Make sure the User restricted from sending email alert reaches whoever handles incidents, so 5.1.8 never surprises you.
• Review Tenant Allow/Block List entries that could cause 5.7.703.
• Check your SPF, DKIM and DMARC before they cause 5.7.23 or 5.7.509 at someone else's server.
• If inbound mail problems are the bigger worry, see how iBlockSpam holds mail for up to 5 days during outages and filters it before it reaches Microsoft 365.

Browse more guides on running email day to day.