Email bounce back: read the code, not the guesswork
A bounced email already contains the answer. Buried under the apologetic wording is an error code that states precisely why delivery failed, and whether the problem is yours or the recipient's. Almost every guide to bounced email tells you to check the address for typos and try again, which solves one cause out of dozens. This one shows you how to read the code instead, because two minutes spent on it will usually tell you exactly what happened.
Last updated 14 August 2026. We review this guide every six months, and after any significant change to Microsoft's published error codes.
Where the useful part is
A bounce message has two halves. The top half is written for people: "Delivery has failed to these recipients or groups", followed by a general suggestion. The bottom half is written for administrators, and it is where the facts are.
Look for a section headed Diagnostic information for administrators. In Outlook you may have to expand the message or open the details to see it. It contains four things worth reading:
- Generating server, the mail server that produced the report.
- The rejected recipient, the address that failed.
- A remote server, if another organisation's server was involved.
- An enhanced status code, such as
5.1.1or5.7.509, followed by the raw response from the server that said no.
The first digit decides whether you act at all
Before looking anything up, read the first number:
- 4.x.x is temporary. The sending server will keep retrying for a period. Mail delayed by a receiving server that is busy or briefly unreachable usually arrives on its own. Doing nothing is often correct.
- 5.x.x is permanent. The message is dead and the server will not try again. Resending the identical message will fail identically, so something has to change first.
This distinction alone resolves a good share of panicked forwards, because a 4.x.x delay report is frequently mistaken for a failure.
Work out whose server said no
This is the most useful and least known part of a bounce. If a remote server is named beneath the recipient's address, that organisation's server rejected your message, and their administrators control the fix. If no remote server is listed, the rejection happened at your end.
It matters because it stops you troubleshooting a system you have no control over. When a customer's mail server rejects your invoice because of a rule on their side, no amount of work on your mailbox will change the outcome, and the productive move is to ring your contact and ask them to raise it with their IT people. Equally, if the rejection is yours, you can stop asking the recipient to check their junk folder.
The codes you will actually see
These are the common ones in Microsoft 365, in plain English:
| Code | What it means | What to do |
|---|---|---|
5.1.1 and 5.1.10 | The recipient address does not exist. | Check the spelling. If it used to work, the address may have been changed or removed. In Outlook, delete the cached entry rather than resending, because the cache will keep supplying the old address. |
5.2.2 | The recipient's mailbox is full. | Nothing you can do from your side. Tell them by another means if it matters. |
5.7.1 | Blocked by a permission or security restriction. Often a moderated group, a restricted sender list, or an authentication failure. | Ask the recipient whether the address only accepts mail from approved senders. If sending from a device or application, check it is authenticating. |
4.4.7 | The message expired in the queue after repeated attempts. | Usually a problem at the receiving end. Confirm the address is valid, then try again later. |
4.3.2 | The recipient mailbox is being throttled for receiving too much too quickly. | Temporary and by design. Wait. |
5.7.509 | Your domain failed DMARC checks and your own published policy told the recipient to reject it. | A fault in your SPF, DKIM or DMARC records. Fix it promptly, because legitimate mail is being rejected. |
5.7.367 | Not permitted to relay, caused by authentication failures on forwarded or relayed mail. | Common where mail passes through a non Microsoft gateway or an automatic forward. Review the forwarding path. |
5.7.507 and 5.7.511 | The recipient's organisation blocked the sending address, or the address was banned. | Contact the recipient. For a banned sending address, delisting is requested from Microsoft directly. |
5.1.8 | Access denied, bad outbound sender. The account was blocked for sending too much spam. | Treat as a compromise until proven otherwise. See below. |
5.1.90 | The daily limit for message recipients was reached. | Legitimate if someone ran a large send. If not, treat as a compromise. |
Two codes that are not really email problems
If you see access denied, bad outbound sender, or a message about reaching the daily recipient limit when nobody has been sending in bulk, stop treating this as a delivery fault. Both mean large volumes of mail have gone out of that account. Microsoft's own guidance notes that a blocked outbound sender typically indicates the account was compromised through phishing or malware. Someone else is very likely sending from it.
The right response is the same as for any compromised mailbox: reset the password without emailing it to the affected account, revoke the account's active sessions so an existing sign-in is cut off, check multi factor authentication, review which applications have been granted access, and look through Sent Items and Deleted Items to see what went out and to whom. Then check for forwarding rules, which is how these accounts are usually monetised. There is more on that pattern in the fake invoice and payment redirection scam.
Once the account is secure, it may still be blocked from sending and need to be released from the restricted list before mail flows again. That order matters: securing first, unblocking second.
When everything bounces at once
A single bounce is a message problem. Every message bouncing is an infrastructure problem, and the causes are different. If all outbound mail is suddenly failing, look at whether the domain has expired, whether DNS records were changed recently, whether the mailbox or the whole tenant has hit a limit, and whether your domain has ended up on a blocklist because of something sent earlier.
The pattern is the quickest diagnostic you have. Bounces to one recipient point at that recipient. Bounces to one domain point at that organisation's filtering. Bounces to everyone point at your domain, your DNS, or your account.
Bounces and junk are the same problem wearing different clothes
Mail being rejected and mail being filed into junk are two outcomes of the same underlying question: can the receiving server prove this message is genuinely from you? SPF, DKIM and DMARC are the records that answer it. When they are wrong, the strict receivers reject you outright, producing bounces, and the lenient ones file you in junk, producing silence. That is why a business with authentication problems often sees both at once and treats them as unrelated. The fix for both is in why your business email lands in spam.
If the bounces are coming to you rather than from you, and senders say their mail is not arriving, work through why Outlook is not receiving emails instead.
FAQ
What does it mean when an email bounces back?
It means a mail server refused to deliver the message and sent you a report explaining why. That report is called a non delivery report, and it contains an error code stating the actual reason. The reason can be as simple as a mistyped address, or as significant as the recipient's server refusing all mail from your domain. The important point is that you do not have to guess, because the code in the bounce already says which it is.
Where do I find the error code in a bounce message?
Below the plain English explanation there is a section headed Diagnostic information for administrators. It lists the server that generated the report, the address that was rejected, any remote server involved, and an enhanced status code such as 5.1.1 or 5.7.509. That code is the useful part. In Outlook you may need to expand the message or view the details to see it.
What is the difference between a 4.x.x and a 5.x.x bounce?
The first digit tells you whether the failure is temporary or permanent. A code beginning with 4 is a temporary failure and the sending server will keep trying for a period, so the message may still arrive without you doing anything. A code beginning with 5 is a permanent failure, meaning the message will never be delivered and resending exactly the same message will produce exactly the same result. Knowing which one you have decides whether to act or wait.
My emails bounce with a DMARC error. What does that mean?
An error stating that the sending domain does not pass DMARC verification, and that the domain publishes a policy of reject, means the recipient's server checked whether your mail was genuinely authorised to come from your domain, decided it was not, and did what your own published policy instructed it to do. This is a configuration problem with your domain's SPF, DKIM and DMARC records, not a problem with the message. It is worth fixing quickly, because while it persists a proportion of your legitimate mail is being rejected outright.
Can a bounce message mean my account has been hacked?
Yes, and a couple of codes point at it directly. An error saying access denied, bad outbound sender means the account was blocked for sending too much spam, which Microsoft notes typically happens because the account was compromised. An error saying you have reached your daily limit for message recipients can indicate the same thing. If either appears and nobody has been running a legitimate bulk send, treat it as a security incident, because something is sending mail from that account that you did not send.
Whose job is it to fix a bounced email?
It depends on which server rejected the message, and the bounce tells you. If a remote server is named under the recipient's address, then that organisation's mail server refused your message and their administrators control the fix, which sometimes means asking your contact there to raise it internally. If no remote server appears, the rejection happened at your end and it is yours to solve. This is the single most useful thing in the technical section, because it stops you troubleshooting a system you do not control.
The bottom line
Scroll to the diagnostic information, read the first digit to see whether the failure is temporary or permanent, check whether a remote server is named to see whose problem it is, then look up the code. That sequence answers most bounces in a couple of minutes without changing a single setting. Watch for the two codes that mean an account is sending mail you did not send, and treat a pattern of bounces to everyone as a domain problem rather than a message problem.
Bounces you cannot make sense of, or mail failing for everyone? Send us the bounce message with the technical part included and we will tell you what it says. Get in touch and we will read it properly.