Outlook has told you a message could not be delivered, and the notice it sent back is longer than it is useful. The wording is still the fastest route to a cause, which is why this guide is organized around the exact strings Outlook puts on screen rather than around status codes. Find your message in the lookup table, and it will tell you what actually failed and which section answers it.
Most published advice on this fails for a reason that is easy to miss. Microsoft's own support article on delivery failures is marked as applying to Outlook.com, its free consumer service, and most of its entries say the problem will resolve itself. That advice does not transfer to Microsoft 365 or Exchange Online, which return different messages, different codes and different fixes. Two of the strings people search most often are not delivery failures at all, and a meaningful share of the real ones have nothing to do with the recipient you were writing to.
This guide works through the messages Outlook shows, what each one means, and how to read the diagnostic detail Outlook collapses by default so you can identify who actually rejected your mail. It then covers the Microsoft status codes worth recognizing, including three that are commonly published wrong, the two Outlook-specific causes that produce failures for addresses that are perfectly valid, and what changes when you are sending at volume rather than troubleshooting one message.
Key takeaways
- The fastest route to a cause is matching the exact wording of the message you received. This page is organized that way, with a lookup table first.
- The reporting server name inside the diagnostic block tells you who rejected your mail. A host ending in mail.protection.outlook.com means Microsoft's layer made the decision, not the recipient's mailbox, which rules out retyping the address.
- Some Outlook undeliverables have nothing to do with the recipient. A stale autocomplete entry and a forwarding inbox rule both generate failures while every address involved looks correct.
- These notices frequently land in Junk rather than the Inbox, which is why people assume a message sent and find out days later.
- Outlook.com and Microsoft 365 behave differently and their fixes are not interchangeable. Microsoft's own consumer article does not apply to business mailboxes, and the two even use separate processes for unblocking a sending IP.
- Two of the most-searched messages here are not failures. "Delivery to these recipients or groups is complete, but no delivery notification was sent" means your mail arrived.
Find the message Outlook showed you
Before matching anything, check your Junk folder. Outlook frequently files these notices there, which is why people conclude a message was sent when it was not, and only find out days later.
Then match the wording on your screen against the table below. One distinction decides how much of this page applies to you: Outlook.com, the free consumer service, and Microsoft 365 or Exchange Online, the business service, return different messages and take different fixes. Microsoft's own support article on delivery failures is marked as applying to Outlook.com only, which is why so much published advice does not work for business mailboxes.
What each Outlook message means and how to fix it
Every fix below is something you can do in the Outlook interface or the Microsoft 365 admin center. Where the answer is genuinely "wait," this page tells you how long and what happens at the end of it.
"Delivery has failed to these recipients or groups"
This is the Microsoft 365 wrapper, and Microsoft reuses it for several unrelated failures. The friendly paragraph underneath is generic. It is not a diagnosis, and reading it more carefully will not tell you more than it already has.
What it does contain, in the version Microsoft documents for a moved mailbox, is a fix most people scroll past: "It is possible that your contact's e-mail address has changed and Outlook's AutoComplete has the old address stored. If this is the case, start typing their name in the To line, press the down arrow to select the outdated entry, and then press Delete."
That sentence solves a surprising share of these, and it is sitting inside the message people forward to their IT team without reading.
The real diagnosis is lower down, in the block labeled for administrators. That is where the reporting server name and the status code live, and it is the section that tells you whether this is your problem or the recipient's. Reading it is covered below.
"Your message couldn't be delivered" and recipient not found
This cluster is the recipient side: an address that no longer exists, a mailbox that moved, or a domain that changed after an acquisition or rebrand. Microsoft's code for it is 5.1.1, Bad destination mailbox address, and the documented causes include one people rarely consider: "The recipient's mailbox was moved, and the sender's Outlook recipient cache didn't update."
That last cause is why "but it worked last month" is not evidence the address is fine. The related code 5.1.10, Recipient not found, covers an address that never existed on that domain.
The Microsoft-specific check is where the rejection came from, and it changes what you should do. If the recipient's own mail server rejected it, checking the address is reasonable. If a Microsoft host rejected it on their behalf, the address is usually not the issue and re-checking it wastes your time.
One case belongs to its own guide rather than this page. A rejection reading 5.4.1 Recipient address rejected: Access denied is a directory-level rejection at the perimeter, which we cover in full in our guide to 550 5.4.1 recipient address rejected.
Mailbox unavailable and temporary failures
Microsoft's Outlook.com article groups most of this family under advice to wait and try again. That is correct and incomplete, because it never says how long the waiting lasts or what happens when it ends.
For Microsoft 365 and Exchange Online, Microsoft documents the window: "Exchange Online repeatedly tries to deliver the message over 24 hours. Only after 24 hours of unsuccessful delivery attempts does a recipient receive this NDR." The final message carries 4.4.7 QUEUE.Expired. Until you see that code, the message is still queued and resending only adds a second copy to the queue.
Worth knowing because it circulates everywhere: the familiar figures of a retry every 15 minutes across two days are on-premises Exchange Server defaults. They are not Exchange Online's behavior, and Microsoft does not publish a retry interval for Exchange Online at all.
"Mailbox unavailable" returned by a host ending in mail.protection.outlook.com is a different case, because that rejection came from Microsoft's layer rather than the mailbox itself. Sometimes it carries an internal reference in brackets. Treat the hostname as the clue and read the next section rather than retyping the address.
Postmaster messages and undeliverable notices for mail you never sent
If you are receiving undeliverable notices for messages you did not send, this is usually backscatter, and Microsoft documents it plainly. A spammer forged your address in the From field, sent to an address that does not exist, and the receiving server returned the failure to you instead of to them.
Microsoft's guidance is unusually direct on the question everyone actually has. On its 5.1.10 page it states: "if this NDR is backscatter, your account hasn't been compromised." It adds that the messages are safe to ignore or delete, but that "if you're getting much of it, it's possible that your computer or device is infected with spam-sending malware."
The check that separates backscatter from a genuine compromise takes a minute. Open the returned message and look at the original message it quotes back to you. If you do not recognize the recipient and the message is spam you never wrote, it is backscatter and your mailbox was never involved. If the returned message is real mail that left your account, the account itself is sending, and that is a security problem rather than a mail problem.
The second check is your Sent Items folder. Backscatter leaves no trace there, because nothing was sent from your mailbox. A compromised account usually does, unless the attacker cleared it, which is itself a signal. Where the account is sending, the cause is often an inbox rule rather than anything you did, and that is covered further down.
Reading the detail Outlook hides
Everything useful sits in the block Outlook collapses by default, labeled for administrators. This is the part that makes the difference between guessing and knowing, and it is the reason the next undelivered message you get will take two minutes instead of an afternoon.
What the rejecting server name tells you
Open the undeliverable message and expand the diagnostic section. Inside it you will find a reporting server name, a status code, and usually the raw response the other side sent back. The reporting server is the first thing to read, because it tells you who made the decision.
A hostname ending in mail.protection.outlook.com is the one worth recognizing. Microsoft documents this as the MX record format for domains that route inbound mail through its service, in the form <domainKey>-com.mail.protection.outlook.com, so that contoso.com becomes contoso-com.mail.protection.outlook.com. Reading it back the other way, a rejection from a host in that form means the recipient's inbound mail terminates at Microsoft, and Microsoft made the decision rather than the recipient's mailbox.
In practice the hostname often looks like machine output, along the lines of DU2PEPF00028D0B.mail.protection.outlook.com. The prefix is just an identifier for the specific Microsoft node. The part after the first dot is the signal.
The practical consequence is that your next move changes. If Microsoft's layer rejected the message, checking the recipient's address again is the wrong instinct, because the address was probably never evaluated. Rejections at that layer come from policy, from reputation, or from the recipient's directory, and all three are addressed elsewhere on this page rather than by retyping the To field.
Microsoft's own status codes
The code sits in the same diagnostic block, usually alongside the reporting server. These are the ones a real sender hits, with the meanings Microsoft publishes in its Exchange Online reference rather than the generic definitions.
Three of those are worth flagging because the wrong version is widely published. In Exchange Online, 5.2.2 is a sending-side rate limit rather than a full recipient mailbox, which is what it means in the generic scheme. Microsoft's DMARC rejection code is 5.7.509, not 5.7.26, which belongs to Google and shows up in Outlook NDRs only when you are sending to Gmail. And the banned-IP range runs to 5.7.649, not 5.7.614.
If your code is not here, the same reference page carries the full list. Match the exact code, including both decimal parts, because 5.7.1 and 5.7.509 have nothing in common beyond the first two digits.
The Outlook problems that have nothing to do with the recipient
Two of the most persistent undeliverable messages have nothing to do with the address you typed, which is why checking it repeatedly never helps. One lives in your own mail client. The other is usually a security incident wearing a mail problem as a disguise.
The autocomplete cache is sending to an address that no longer exists
Outlook remembers who you have emailed, and for internal recipients it remembers more than the address. It stores an internal routing value, and Microsoft documents what happens when that value changes: "The auto-complete cache in Microsoft Outlook and in Microsoft Outlook Web App (OWA) uses the value of the LegacyExchangeDN attribute to route email messages internally. If the value changes, the delivery of email messages may fail with a 5.1.1 NDR."
This is what happens when a colleague's mailbox is deleted and recreated, or migrated between systems. The address in your To field looks correct because it is correct. The routing value behind it points at a mailbox that no longer exists.
You can recognize it from the failed address in the bounce, which will not look like an email address at all. It begins IMCEAEX- and continues into a long string of _O= and _CN= fragments with +20 where the spaces should be. If you see that, stop checking the address.
The fix is to delete the one cached entry rather than clearing the whole cache. In Outlook on the web, start a new message, type the recipient until they appear in the drop-down, select them with the arrow keys and press Delete. In the Outlook desktop app, type the first few characters, hover over the suggestion without selecting it, then click the X that appears or press Delete. Then pick the recipient from the address book rather than letting autocomplete fill it again.
Two things worth knowing about that fix. Microsoft notes that removing an entry "doesn't remove it from your account," so it can still surface elsewhere, and that emailing the contact again restores it. And if you find advice telling you to delete an .nk2 file, Microsoft scopes that to Outlook 2007 and earlier. Later versions store the list inside the mailbox.
This one explains a symptom that otherwise makes no sense: the message fails from Outlook and goes through from Gmail, to the same person, at the same moment. Nothing is wrong with the recipient. The stale entry exists only in your client, which is also why it is invisible to any list cleaning you run.
Inbox rules generating undeliverable loops
If undeliverable notices are arriving steadily rather than after you send something, check your inbox rules. A rule that forwards or redirects mail to an address that no longer works will generate a failure for every message it touches, and you did not send any of them.
The uncomfortable part is how these rules usually get there. Microsoft lists them among the symptoms of a compromised account, specifically "Rules that automatically forward email to unknown addresses" and rules "that move messages to the Notes, Junk Email, or RSS Subscriptions folders." Those three folders are a recognizable pattern, because they are places nobody looks. People sometimes find rules written in a language they do not speak.
Checking the rules list in the interface is the obvious first step, and in new Outlook for Windows that is Settings, then Mail, then Rules, where each rule has a delete control beside it. But the interface is not sufficient on its own, which is the detail almost nobody publishes. Microsoft's own instruction to administrators is to review all inbox rules "including hidden ones," using Get-InboxRule with the -IncludeHidden switch, because rules created this way are frequently not visible in the client at all.
Deleting the rule stops the undeliverable messages, and it is the easy half. Mail that was being forwarded has already gone somewhere. Treat it as a security event: change the password, review recent sign-in activity, and check whether anything else on Microsoft's symptom list applies, including forwarding configured on the mailbox itself rather than through a rule.
Microsoft 365 undeliverable messages when you send at volume
Everything above applies to one of a few broken messages. This section is for teams watching rejections accumulate across a sending program, where the cause is usually tenant configuration or reputation rather than any individual address.
Why most B2B undeliverable messages come from Microsoft
Microsoft owns the receiving side of the B2B market, which matters more than most senders expect.
Our census of the Fortune 500 found Microsoft 365 running the mailbox layer for 412 of 500 companies (82%), and 276 of 500 (55%) sitting behind a secure email gateway, measured across validations run April to June 2026. If you sell into large companies, most of your rejections come from Microsoft infrastructure whatever your own stack looks like.
Two figures from that dataset have not been published before. We classify a domain as catch-all on behavior, meaning it either accepts mail to every address or accepts it and bounces later.
On that basis, Proofpoint fronts 222 of the 276 gateways, and 145 of those 222 (65.3%) behave as catch-all.
Narrowing to the hardest combination, Proofpoint in front of Microsoft 365, 135 domains behave as catch-all against 69 that cleanly reject. That is 66.2% of the 204 that returned a resolvable answer: two in three of the Fortune 500 domains on that setup accept your mail before deciding what to do with it.
Which is where verification fits, and it is narrower than it is usually sold. On those domains a standard pre-send check does not return a settled answer, because the server accepts the address regardless of whether the mailbox exists. Allegrow resolves them to a conclusive valid or invalid before the send rather than passing the ambiguity along.
The tenant-level causes an individual user cannot see
Three causes account for most volume rejections, and none of them are visible from a single mailbox.
- Directory-level rejection. Microsoft's perimeter refuses addresses that do not exist in the recipient's directory. This is the 5.4.1 case covered earlier.
- Connector and transport rule misconfiguration. Produces the 5.7.1 family, where your own organization's rules are refusing the send.
- Outbound sending limits. Microsoft enforces these per mailbox and per tenant, documented in its Exchange Online service limits. They surface as 5.2.2 or 5.1.90 rather than as anything mentioning a limit.
One pattern tells you which of those you are in before you investigate anything.
Rejections concentrated on a single recipient domain point at that recipient, usually their directory or their gateway policy. Rejections spread across many unrelated domains point at your side, where the cause is almost always authentication, reputation, or a limit you have crossed.
When Microsoft has blocked your sending IP
There are two different routes here, and mixing them up costs you days.
For Microsoft 365 and Exchange Online, codes in the 5.7.606 to 5.7.649 range go through Microsoft's self-service delist portal at sender.office.com. You submit the blocked IP and the address that received the rejection.
A 5.7.511 rejection works differently. It directs you to forward the message to the address named in the NDR itself.
Outlook.com blocks are not handled by that portal at all, and go through Microsoft's separate sender support process for the consumer service. This is the clearest example of why the two products need separating: same company, same symptom, different door.
For the general prevention and bounce-handling story behind all of this, our guide to undeliverable email covers it properly and this page does not repeat it.
Conclusion
The method matters more than any individual message, because it works on the next one too. Match the exact wording against the table rather than guessing from the tone of it. Expand the diagnostic block Outlook collapses. Read the reporting server name before you read anything else, since it tells you who made the decision. Only then decide whether you are looking at a problem with the recipient, with your own mailbox, or with your tenant. Those three have almost nothing in common, and assuming the wrong one is what costs you the afternoon.
The Outlook-specific thing worth remembering is that a meaningful share of these failures have nothing to do with the person you were writing to. A cached routing address that stopped working when their mailbox was recreated, or an inbox rule forwarding mail somewhere that no longer exists, will both produce a steady stream of undeliverable notices while every address involved looks perfectly correct.
If you send at volume rather than troubleshooting a single message, the useful move is upstream of the bounce. You can verify up to 1,000 of your own contacts on a 14-day free trial, including the gateway-fronted Microsoft domains where an ordinary check accepts the address without confirming the mailbox exists. Knowing which addresses are real before you send is a shorter conversation than reading the NDRs afterward.
Frequently asked questions
How do I find the non-delivery report in Outlook?
Check your Junk folder first, because Outlook frequently files them there. The report arrives as an email reporting the failure, usually from a postmaster address. Open it and expand the section labeled for administrators, which is where the reporting server name and the status code sit.
Why am I getting postmaster emails from Outlook?
Usually because someone forged your address as the sender on mail you never sent, so the failure notice came back to you instead of to them. Microsoft calls this backscatter, and states plainly that receiving it does not mean your account was compromised.
Why does an email work from Gmail but fail from Outlook?
Almost always a stale autocomplete entry. Outlook stores an internal routing value for people you have emailed, and it breaks when their mailbox is deleted and recreated. Gmail keeps no such cache, so it sends fine. Delete the cached entry and pick the address from your address book.
How long does Outlook keep trying before a message fails?
For Microsoft 365 and Exchange Online, Microsoft documents 24 hours. The final notice carries the code 4.4.7 QUEUE.Expired, and until you see it the message is still queued. The widely repeated figure of 15 minutes across two days is on-premises Exchange Server, not Exchange Online.
What does a rejection from mail.protection.outlook.com mean?
It means Microsoft rejected your message before it reached the recipient's mailbox, because that hostname is the inbound route Microsoft uses for domains on its service. Re-checking the recipient's address will not help. The cause is usually policy, reputation, or the recipient's directory.
Do Outlook.com and Microsoft 365 need the same fixes?
No. Microsoft's own support article on delivery failures applies to Outlook.com only, and its advice does not transfer. The two return different messages and different codes, and they even use separate processes for unblocking a blocked sending IP.
