Bounce and error codes

Your message could not be delivered: what Microsoft's NDR says

Last updated 2026-08-27

A text message app or Discord shows nearly the same words. This page covers email, and Discord's help site covers a message its community filters blocked.

Read the reason sentence, then the SMTP reply

Microsoft ships this report in two layouts. The enhanced status code sits in both.

The current layout opens on a Cause heading. Below it, a diagram draws the sender, Microsoft 365 and the recipient. It marks in red the party that usually has to act. The fix-it steps come next, then a More info for email admins block, then a list of message hops with times and server names. The older layout splits into a user section and an admin section instead. Email bounced back gives the click path to that admin section in each mail app.

The reason sentence does not come from the far server. Exchange picks it from the enhanced status code. Microsoft puts it this way: the code "determines the text that's displayed in the user information section (the code value isn't altered by Exchange)". On Exchange Server, the New-SystemMessage cmdlet replaces that text for a given code, in one language or several. Microsoft suggests the help desk's own contact details. If your own company runs Exchange Server on-premises, your IT department may have written the sentence you are reading.

Nobody edited the SMTP response under it. Microsoft says that response and the header fields stay in English and are not customizable. The server that refused the message wrote them.

Generating server wrote the report, Remote server refused it

Microsoft documents the admin section in this shape:

Generating server wrote the report. Remote server refused the message. Read both lines before you open a ticket. The company that runs the generating server cannot fix a rejection that came from the remote server. When no remote server appears under the address, one server did both jobs, which is normal inside one company. The remote server line also stays empty when the far server took the message and rejected it later, on a content restriction. Microsoft says the far server writes the report in that case.

Microsoft points at three header fields in the last block. To catches an address that was mistyped. The Received fields show the path and the last hop. They help when the generating server name means nothing to you. If Received-SPF reads anything other than pass, Microsoft tells you to check the SPF record for your domain.

Delivery Status Notification (Failure) covers the RFC 3464 fields that every provider's bounce shares, whichever server generated it.

Send Again resends, and it does not retry

Outlook puts a control on the report itself. Microsoft's steps are to open the bounce and choose Send Again on the Report tab. Outlook on the web offers a link in the reading pane instead, reading "To send this message again, click here". Both build a fresh copy of your message for you to edit and send. If the original attachment ran over 10 MB, Microsoft says Send Again might be missing or might not work. Resend from Sent Items in that case.

Exchange Online retries inside the service, and it sends no notice until it gives up. The report arrives once it stops. A copy of a message that drew a 5.x.x reply draws that reply again, so change something before you send it.

Each reason has one owner, and it is often not you

Your own help desk cannot empty a mailbox at another company, and the recipient cannot edit your DNS. Each row below pairs Microsoft's own description of a code with the side that owns the fix.

What Microsoft's table calls it	Code	Who clears it	First move
Recipient not found	5.1.10	You, then their admin	Drop the cached entry, retype the address
Bad destination mailbox address	5.1.1	You, then their admin	Check the spelling before anything else
Sender was not authenticated for mailbox	5.7.134	The recipient's admin	Ask them to accept mail from outside
Access denied ... does not pass DMARC verification	5.7.509	Your DNS owner	Align a real sender before you resend
Mailbox full	5.2.2	The recipient	Call them, then send later
Submission quota exceeded	5.2.2	You	Wait a day, then check for a compromise
QUEUE.Expired; message expired	4.4.7	Both sides	Check whether every failure went to one domain

5.1.10 means the address lookup failed

The full reply reads 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup. Microsoft gives the sender the first move here, and 5.1.1 gets the same one. Delete that address from your Auto-Complete list, which Microsoft also calls the nickname cache, then type the whole address again and send. A recipient who moved between on-premises Exchange and Exchange Online keeps the same address, but other internal identifiers change with the move. Your cached entry still points at the old ones. The address on your screen looks correct, and the cached identifier behind it no longer resolves.

When a retyped address bounces the same way, the recipient's side owns the rest. Their admin checks that the mailbox exists and still holds a mail license. Microsoft's hybrid example is a user created in the cloud with no matching object on the local Exchange server. Every query for that SMTP address then fails. The repair happens on-premises, where their admin creates a remote mailbox with New-RemoteMailbox, sets its ExchangeGuid to the value the cloud mailbox carries, then runs a directory sync.

If Sent Items holds no such message, Microsoft calls the report backscatter. It says plainly that backscatter alone does not mean your account is compromised. Its instruction for a run of these is to read Sent Items first. Mail Delivery Subsystem traces where the run came from.

5.7.x splits into two owners

A 5.7.x code means a security or policy call. Microsoft's 5.7.1 guidance covers 5.7.0 through 5.7.999. The side that made the call owns the fix.

The recipient's side owns the mailbox and group rules. 5.7.134 is a mailbox set up to reject messages from outside its organization, and only an email administrator there can change that. 5.7.133 is the group version, and Microsoft says the group owner can change that setting as well.

One reason sentence in this family sends you to the wrong person. Microsoft prints "Your message couldn't be delivered to the recipient because you don't have permission to send to it. Ask the recipient's email admin to add you to the accept list for the recipient." when an on-premises Active Directory account was disabled rather than deleted. No accept list clears that. Microsoft's fix is to delete the on-premises account rather than disable it. Removing the license instead leaves the mailbox receiving for about 30 days, unless a mail flow rule stops it.

Your side owns authentication. Every receiver that applies your DMARC policy treats the rest of the mail from that source the same way. The copy you resend to a different address fails too. Microsoft lists three causes for a DMARC failure: a record that is missing or wrong, mail that carries no DKIM signature, and forwarding that breaks SPF or DKIM. 550 5.7.509 is your own p=reject policy applied to your mail. 550 5.7.515 is a bulk sender that misses Microsoft's requirements, and 550 5.7.23 is SPF failing for the connecting IP. For what a reject policy asks receivers to do, read DMARC fail with p=reject.

5.2.2 arrives from either end

The same three digits cover two problems in Microsoft's own tables. Read the words beside them.

A full mailbox belongs to the recipient. Exchange Server lists 5.2.2 as Mailbox full, a mailbox over its storage quota that can no longer accept new messages. Microsoft prints one report in full for this code, for a mail-enabled public folder over its post quota. The reason sentence there reads "The recipient's mailbox is full and can't accept messages now. Please try resending this message later or contact the recipient directly." The admin section reads 554 5.2.2 mailbox full; STOREDRV.Deliver.Exception:QuotaExceededException.MapiExceptionQuotaExceeded.

A submission quota belongs to you. The Exchange Online table lists 5.2.2 as Submission quota exceeded. Microsoft's report reads "The message can't be submitted because the sender's submission quota was exceeded", and the recipient rate limit behind it is 10,000 recipients per day. Microsoft tells you to wait one day. If nobody at your desk sent 10,000 of anything, treat the mailbox as compromised and reset the password first.

4.4.7 means the queue ran out

A 4 marks a temporary problem, but this report ends the delivery anyway. Exchange Online tries over and over for 24 hours, and only then does it write to the sender. The reason sentence reads "The server tries to deliver this message but can't. It stops trying. Try sending this message again. If the problem continues, contact your help desk." The admin section carries #550 4.4.7 QUEUE.Expired; message expired ##.

Microsoft's first question is whether every failure went to one domain. If it did, the problem sits at that domain. Microsoft lists three causes there: a server that sits offline, anti-spam settings that turn away legitimate senders, and an MX record that is missing or wrong. The advice is to reach the recipient another way. Hand them the rejecting server's name and the error, and their admins take it from there.

If the failures span several domains, look at your own side. Microsoft's list there starts with an SPF record that misses some of your sources. A domain that lapsed at the registrar comes next, and a hybrid connector that needs the Hybrid Configuration Wizard run again comes after it.

Message trace finds the reply without the report

When the sender deleted the bounce, message trace answers the same question. It sits in the Exchange admin center under Mail flow. Microsoft says it tells you whether the service received, rejected, deferred or delivered a message.

The default range covers 2 days, and you can ask for up to 90 days. A range of 10 days or less returns a Summary report almost at once. Go past 10 days by any amount, and the result becomes a downloadable CSV built from archived data. Microsoft warns that the file can take several hours to appear. Set the delivery status filter to Failed to list every message the service did not deliver for one mailbox.

Free checks after a DMARC bounce

When the reply named DMARC or SPF, the fix sits in your DNS or in the platform that sent the message. It never sits in the message itself. Check the domain in the From address of the rejected message, since that is the domain DMARC judges. Our combined SPF, DKIM and DMARC checker answers for all three at once, with no signup. If SPF is the one named, our SPF checker follows each include and totals your lookups, because an eleventh one turns the record into a permerror.

Those checkers read your DNS, and they cannot tell you which of your senders passed. Only the aggregate reports that receivers write about your domain answer that. Microsoft's own first step for a DMARC failure says as much: ask whatever service reads your reports what is going on. Two of those services cost nothing. Cloudflare's DMARC Management charts which of your sources pass. Cloudflare puts it on every plan, as long as the domain resolves through Cloudflare DNS. Try that one before you try ours. Postmark's DMARC Digests sends one summary a week by email. When I last checked, the free tier was that email and nothing else, with no web dashboard behind it.

DomainCanary is our product, so discount this paragraph accordingly. This report named the server that refused you. The aggregate reports name every source that sent under your own domain, and they show which of those sources aligned. Pro costs $19 a month for 5 domains. On a paid plan, we mail you the day a report first shows a failing source that has never appeared in your history, and the day a source that had been passing starts failing. We do not hold either for the weekly digest. One weekly email covers all 5 domains that share a digest address. You can have us skip the digest on a clean week and record it on the dashboard instead. Our retention floor holds each source's history for at least 12 months, on the free plan as well as the paid ones. A rua= tag asks receivers for reports, and it leaves your policy exactly as it is. Microsoft mailed this report to you, and not to us. An aggregate report counts messages per sending IP, and it carries no copy of any bounce. Start with one domain free.