Skip to content
12 min read Updated 8 Aug 2026Beginner

Understanding Email Bounce Messages

Applies to: Microsoft 365, Outlook (new Outlook, classic Outlook, Outlook on the web)
Article Type: Informational
Last Updated: 2026-08-08

Summary

A bounce message is a wall of technical text from a sender you have never heard of, and buried in it are three things that answer the only question you have: did my message go? This article shows you where those three things sit, what the codes mean in plain English, and which failures you can fix yourself. It also covers the two facts people get wrong most often — that a bounce is sometimes about your side rather than the recipient's, and that no bounce is not proof the message arrived.

Before You Start

  • None required. This is a reading guide, not a procedure — keep the bounce message open beside it.
  • The codes below come from Microsoft's own reference for Exchange Online, which is what Microsoft 365 mailboxes run on. Mail systems from other providers use the same numbering scheme with their own wording.

Instructions

1. What a Bounce Message Actually Is

Nobody wrote it, and the name in the From field is rarely the system that made the decision.

When a message cannot be delivered, a mail server generates an automatic notice and sends it back to you. Microsoft calls this a delivery status notification, and the most common kind is a non-delivery report — an NDR. Everyone else calls it a bounce.

It arrives from a name like Microsoft Outlook, Mail Delivery Subsystem, or postmaster@ some domain. None of those is a person, and none of them will read a reply.

Two servers are usually involved, and the bounce names both. The generating server wrote the notice. The remote server is the one that refused the message. Where a remote server is named and it is not your company's, the decision was made at the far end — which changes who can fix it. Microsoft is explicit that its own logo on a bounce does not mean Microsoft 365 caused the failure; it only means Microsoft 365 was in the path.

2. Find the Three Things That Matter Inside It

A bounce is long because it is written for two audiences at once, and the part written for you sits at the top.

Newer bounces from Microsoft 365 open with a plain-English summary: a Cause section, a How to fix it section written for the sender, and a small diagram of the three parties in the delivery — you, Microsoft 365, and the recipient — with the party who has to fix the problem marked. Older-format bounces split into User information at the top and Diagnostic information for administrators below it.

Whichever format you have, look for these three:

  • The recipient it failed for. Listed under a line like Delivery has failed to these recipients or groups:. Read it carefully when you sent to several people — a bounce names only the addresses that failed, and everyone not named received the message normally.
  • The reason, in words. It sits directly beneath the failed address. This is the sentence to read first, and for a good half of all bounces it is the whole answer.
  • The code. A number in the form 550 5.1.1 — three digits, then three more separated by dots. It lives in the Diagnostic information for administrators block, usually on the same line as the remote server's name. This is the part to quote if you end up raising a ticket.

3. Read the First Digit Before Anything Else

One digit separates "this will never work" from "this may still arrive", and it is the first digit of the second number.

The dotted code follows a standard numbering scheme, and Microsoft states the rule plainly: a code starting 5. is a permanent error, and a code starting 4. is a temporary one.

  • 5.x.x — a hard bounce. The receiving system made a final decision. Sending the same message to the same address produces the same result, so resending without changing something is wasted effort.
  • 4.x.x — a soft or deferred bounce. Something was busy, unreachable, or over a limit at that moment. Your mail server keeps retrying on its own for a while, and the message can still land without you doing anything. A 4.x.x notice is often a delay warning rather than a failure — read the wording before you act. The exception is 4.4.7 Message expired, which means the retries ran out.

4. Decode the Code

The table below covers the codes an office worker actually meets, with Microsoft's own meaning translated out of server language.

CodeWhat it meansDoes retrying help?What to do next
5.1.1Bad destination mailbox address — no mailbox with that address exists at the far endNoCheck the spelling against a message the person has sent you. If you picked the address from a dropdown suggestion, that suggestion is the likely culprit — How to Fix Outlook AutoComplete Not Working or Suggesting Wrong Emails shows how to remove it.
5.1.10Recipient not found — the address lookup returned nothingNoSame as 5.1.1. This one often means the mailbox existed once and has since been removed.
5.4.1Recipient address rejected: access denied — the receiving system does not accept mail for that addressNoConfirm the address and the spelling of the domain with the recipient through another channel.
5.7.1Delivery not authorized — you are not permitted to send to that recipientNoCommon when the address is a distribution group that accepts mail only from its members. Ask the group's owner to add you to its allowed senders.
5.7.133 / 5.7.134Sender not authenticated — the group or mailbox is set to reject mail from outside its organisationNoOnly that organisation's email admin or the group's owner can change it. Ask a colleague inside their organisation to forward the message on.
5.7.23 / 5.7.509The recipient's system rejected your domain's sender authentication (SPF or DMARC)NoThis is about how your domain is set up, not your message. See Understanding Email Security (SPF, DKIM, DMARC) in Plain English and send the bounce to whoever manages your domain.
5.7.703Blocked by your own organisation's allow/block listNoYour company blocks that address or domain deliberately. Ask IT whether it can be unblocked and why it is listed.
5.2.2Submission quota exceeded — you passed your own account's sending limitYes, laterWait, then send in smaller batches. If you were not sending in bulk, tell IT the same day using the wording in the 5.1.8 row — this code can also mean an account is being used to send spam.
5.1.90You reached your daily limit for message recipientsYes, tomorrowSplit large sends across days, or ask IT about the limit on your account.
5.1.8Access denied, bad outbound sender — your account is blocked from sendingNoReport this to IT the same day and change your password. Send them: "My account is returning 5.1.8 Access denied, bad outbound sender on outbound mail. Microsoft documents this as an outbound spam block. Please check whether my account has been flagged as compromised and what needs to happen to restore sending." Microsoft's own guidance is that this block usually follows an account being compromised through phishing or malware.
5.2.122The recipient's mailbox has taken more messages this hour than it is allowed toYes, laterNothing is wrong with your message. Send it again in an hour.
4.4.7Message expired — your server kept retrying and ran out of timeYesSend it again. The message goes back into the queue and the retries start over. If it expires twice, the far-end server has a real problem and the recipient's IT needs to know.
4.5.3Too many recipients — the message has more than 200 recipients at the same domainYesSplit the recipient list into smaller batches and send again.

5. Recognise the Bounces That Are About Your Side

Three common failures have nothing to do with the recipient, and treating them as a bad address wastes the afternoon.

The message is too large. Every mail system enforces a size limit, and the recipient's limit can be lower than yours — a message can leave your company cleanly and be refused at the far end. The reason line names a size limit rather than an address. The fix is to send a link instead of a file: How to Send Large Files Without Email Attachments covers it.

A policy blocked it. 5.7.703 means your own organisation's block list stopped the message before it left. A separate class of block comes from data-loss rules that inspect what is inside the message — a card number, a document marked confidential — and those produce their own explanation rather than a delivery code. Understanding DLP: Why Can't I Send This Email? explains that one.

You hit a sending limit. 5.2.2 and 5.1.90 are caps on your own account, and they exist to contain compromised accounts. Both clear on their own. What makes them worth reading closely is the other explanation: if you did not send anything in bulk and you are hitting a limit, something else is sending from your account, and that is a same-day conversation with IT.

6. Treat "No Bounce" as Silence, Not Delivery

A message can fail completely without producing any notice at all, so the absence of a bounce proves nothing.

Spam filtering does not bounce. A message classified as junk at the receiving end is dropped into a Junk Email folder or held in quarantine, and neither of those sends anything back to you. An inbox rule on the recipient's side can file your message into a folder they never open, which looks identical from where you sit. In both cases the delivery technically succeeded and you will hear nothing.

That is why "I didn't get a bounce" is not an answer to "did they get it?". When a message genuinely matters and no reply has come, confirm it through a different channel — a Teams message, a phone call — rather than resending the same email and waiting again.

7. Escalate with a Bounce IT Can Actually Use

One complete forward saves a day of back-and-forth, because your IT team has a diagnostic that reads the code directly.

Forward the entire bounce message rather than copying out the part you think matters. The technical block at the bottom is what carries the answer, and retyping a code drops a digit often enough to matter.

Include these five things in the ticket:

  • The full code, exactly as written — 550 5.7.1, not "a 5.7 error".
  • The Remote server line, which names the system that made the refusal.
  • The Generating server line.
  • The recipient address that failed.
  • The date and time you sent the original.

Send IT this: "A message to [recipient address] bounced on [date] with code [code]. The full bounce is attached, including the diagnostic block. Please tell me whether the block is on our side or theirs, and what needs to change for the message to go through."

That last sentence is the one that shortens the ticket. Microsoft 365 admins can paste a bounce code straight into a diagnostic in the Microsoft 365 admin center and get the cause back, so a ticket that carries the code is answerable in minutes.

Troubleshooting

INFO

A bounce for a message you never sent is not evidence that your account has been broken into. Spam is routinely sent with a forged From address, and when it fails the bounce goes to the address that was forged rather than to whoever actually sent it. Microsoft names this directly in its guidance on relay failures. Delete it. If these arrive in large numbers, or your Sent Items contains messages you did not write, that is a genuinely different problem — tell IT the same day.

Symptom / ErrorPotential CauseSolution
5.1.1 for an address you have used for yearsThe mailbox was renamed or removed, or your saved suggestion holds the old addressConfirm the address from a recent message they sent you, then clear the stale suggestion — see How to Fix Outlook AutoComplete Not Working or Suggesting Wrong Emails.
The bounce arrived hours or days after you sent itThe far-end server was unreachable and the retries ran out, producing 4.4.7 Message expiredSend the message again. It goes back into the queue and the retry cycle restarts.
Some recipients bounced and others did notFailures are recorded per addressThe recipients not named in the bounce received the message. Resend only to the failed addresses.
The bounce names a server you do not recogniseThe Remote server line names the system that rejected the message, which is usually the recipient's providerIf that server is not your company's, the fix sits with the recipient's IT. Forward them the reason line and the code.
5.7.703, or wording saying your organisation blocked the messageYour own company's allow/block listAsk IT: "Our block list is rejecting mail to [address or domain] with code 5.7.703. Please confirm whether that entry is intentional, and remove it if not."
5.1.8 Access denied, bad outbound senderYour account is blocked from sending, typically after being compromisedChange your password, then tell IT the same day: "My account is returning 5.1.8 Access denied, bad outbound sender on outbound mail. Microsoft documents this as an outbound spam block. Please check whether my account has been flagged as compromised and what needs to happen to restore sending." Sending will not resume on its own.