Your message could not be delivered: Microsoft's bounce notice

Your message could not be delivered is the headline on a Microsoft nondelivery report, printed as couldn't in the mail itself. The reason sentence under it gives the cause, and the admin block further down carries the SMTP reply the refusing server sent. Read the reply, because it says which server refused and what to change. 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.

Does Send Again fix it? No. A copy sent to the same address with the same setup draws the same rejection.

Where the reason is

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 and Remote server

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.

In the last block, Microsoft points to the header fields worth reading. Check To for a mistyped address. 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

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.

Who fixes each code

Your own help desk cannot empty a mailbox at another company, and the recipient cannot edit your DNS. The table below gives Microsoft's own description of each code and who clears it.

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, recipient not found

The full reply reads 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup. Microsoft says the sender acts first here, and the same goes for 5.1.1. 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 admin has to fix 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. For a run of these, Microsoft says to read Sent Items first. Our Mail Delivery Subsystem page shows how to trace where the run came from.

5.7.x, security and policy rules

A 5.7.x code means a server refused the message on a security or policy rule. Microsoft's 5.7.1 guidance covers 5.7.0 through 5.7.999. Whichever side set that rule has to fix it.

The recipient's side sets 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.

In one case, the reason sentence in this family tells you to ask 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.

Authentication is yours to fix. 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 these 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 receivers do with a reject policy, read DMARC fail with p=reject.

5.2.2, full mailbox or sending quota

Microsoft's own tables use 5.2.2 for two problems. Read the words beside the code.

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 after 24 hours of retries

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 these 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

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

When the reply mentions 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 DMARC checks that domain. Our combined SPF, DKIM and DMARC checker checks all three at once, with no signup. If the reply mentions SPF, 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, so they can't show which of your senders passed. For that you need the aggregate reports that receivers send about your domain. Microsoft's own first step for a DMARC failure is to ask whatever service reads your reports what is going on. Cloudflare and Postmark both offer one for free. 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. 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 works from the other report. This report gave you the server that refused you. The aggregate reports list every source that sent under your own domain, and they show which of those sources aligned. The Starter plan costs $19 a month for 3 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. On the Business plan, one weekly email covers every domain that shares a digest address. You can have us skip the digest on a clean week and record it on the dashboard instead. We keep each source's history for at least 12 months, on the free plan as well as the paid ones. Adding a rua= tag gets you reports from receivers, 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.