Email bounced back: find the reason line, then fix it

A mail server between your outbox and the recipient refused your message and wrote back to you. That report is a bounce, and one line inside it carries a three-digit code and a sentence giving the reason. A code that starts with 5 is permanent, and one that starts with 4 means the sending server is still retrying.

Find the reason line

Scroll to the bottom of the notice. You are looking for a line that starts with 3 digits, followed by a dotted number and a sentence:

That sentence is the reason, and the first digit says how final the refusal is. A 5 means the server stopped for good. A 4 means it is still trying. Those classes come from RFC 3463. It defines a permanent failure as one that "is not likely to be resolved by resending the message in the current form".

The same verdict appears again lower down, in labeled fields:

Diagnostic-Code carries the other server's own reply, so it usually repeats the reason line word for word. Read that field first. Action: failed and Action: delayed are the machine-readable form of the same verdict. Those field names come from RFC 3464, so they read the same whichever system sent the notice. The Mail Delivery Subsystem page reads the fields one by one, and Delivery Status Notification (Failure) covers the subject line itself.

Gmail hides the reason line behind Show original

Every mail app puts that line somewhere different.

• Gmail sends the notice from Mail Delivery Subsystem. Google tells you to open it and read the error message inside. For the raw version, click More next to Reply, then Show original.
• Outlook and Microsoft 365 put a plain summary under a Cause heading, with the detail under More info for email admins. Older reports split in two: User information, then Diagnostic information for administrators. That second block names the server that refused you and quotes its reply. To read the headers in new Outlook or on the web, choose More actions, then View, then View message details. Classic Outlook for Windows keeps them under File, then Properties.
• Apple Mail on a Mac shows the notice as an ordinary message. Apple's Mail User Guide gives the path to the full detail: choose View, then Message, then All Headers.

I copy that line into a note before I close the bounce, along with the address on the Final-Recipient line.

Match your reason line to the person who fixes it

Your code matches one row of this table, and that row says who can clear it.

Reason line	Who fixes it	What they do
5.1.1 no such mailbox	The sender	Correct the address, send again
4.2.2 or 5.2.2 out of storage	The recipient	Clear space, or read mail elsewhere
4.x.x other temporary failure	The sending server	It retries, then gives up
5.7.1 spam or a mail rule	The recipient's admin	Allow the sender, or edit the rule
5.7.26 or 5.7.515	The sending domain's admin	Repair the DNS records
Reports for mail you did not send	Nobody stops them arriving	Check Sent, then leave them

Address errors: compare it against Final-Recipient

Gmail returns 550 5.1.1 with the text "The email account that you tried to reach does not exist", and Microsoft's code table lists 5.1.1 as Bad destination mailbox address. Microsoft also returns 5.4.1 with "Recipient address rejected: Access denied", which the same table explains as an address that does not exist.

Compare the address in the Final-Recipient line against the one you meant to type. Check the domain as carefully as the name, because a wrong domain still resolves and still bounces. If the address used to work, the person may have left, or an admin deleted the mailbox. Microsoft names one more cause inside a single company: a mailbox that moved while Outlook's recipient cache kept the old address. Its instruction there is to remove that address from the sender's Outlook cache and start a new message. Resending the original one fails the same way.

The sender corrects this one. No admin on either side can fix it.

Mailbox full: wait or call

Gmail returns 452 4.2.2 with "The recipient's inbox is out of storage space", which is temporary, and 552 5.2.2 with "The recipient's inbox is out of storage space and inactive", which is not. Google tells the sender to ask the person to clear space in their account storage before they can receive new mail.

Only the recipient can clear it. Reach them another way and tell them, because a phone call beats another send.

An out-of-office reply looks like a bounce in a busy inbox. RFC 3834 keeps the two apart. Delivery status notices report on a delivery. An "out of office" or "vacation" notice tells the sender that the message is unlikely to be read for some amount of time. It carries no status code.

4xx delays: the server is still trying

A code starting with 4 means the receiving server said "not now". RFC 3463 puts that class beside the permanent one quoted above: the message as sent is valid, and a temporary condition delayed it. The sending server keeps the message queued and tries again on a schedule its operator sets.

Exchange Online "repeatedly tries to deliver the message over 24 hours", and only after those 24 hours does the sender get a 550 4.4.7 QUEUE.Expired; message expired report. A delay notice before then leaves the message in the queue.

So a delay notice asks you to wait. Resending puts a second copy in the same queue, and the recipient gets both copies once the receiving server accepts them. If a delay turns into a failure a day later, treat the failure as the real event and start again at the reason line. Gmail's rate-limit version is 421-4.7.28, which the sending server retries.

5xx blocks: content, reputation or authentication

When a 5xx bounce says nothing about the address, the receiver made a policy call. The sentence beside the code says which policy. If your notice says the message was blocked, the line underneath it names the cause, and message blocked covers that family.

• Spam scoring. Gmail returns 550 5.7.1 with "This message is likely unsolicited email". The content, the links or the sending IP triggered a filter.
• A blocked sending IP. Microsoft has 2 forms of this, and each one has its own fix. 550 5.7.606-649 Access denied, banned sending IP goes through the Office 365 Anti-Spam IP Delist Portal at https://sender.office.com. Microsoft's delist portal documentation rules that portal out for 550 5.7.511 Access denied, banned sender. Forward that report to delist@microsoft.com with the full code and IP. Microsoft says it contacts you within 48 hours with the next steps.
• A rule on the receiving side. Microsoft's 5.7.1 also covers "Delivery not authorized". A distribution list or a transport rule returns that when it turns you away, and only the recipient's admin can change it.
• Authentication. Gmail prints 550-5.7.26 in two versions: one says the sender is unauthenticated, and the other says the mail "is not accepted due to domain's DMARC policy". Microsoft returns 550 5.7.515 when a bulk sender misses its requirements. These are the ones you can fix from your own DNS.

A block aimed at your domain or your sending IP applies to every message you send to that receiver. You are also the only person who hears about it: the notice goes to the sender, and nobody tells the recipients that their copy was refused. You find out when one of them asks why you never replied.

Authentication rejections name the check that failed, or they call the sender unauthenticated. Start with 550-5.7.26, which tells Gmail's two versions apart, and 550 5.7.515 for the Microsoft form. When the error quotes your own policy back at you, DMARC fail with p=reject explains what your record asked receivers to do.

Our SPF, DKIM and DMARC checker reads all three records live with no signup, and it counts the SPF lookups against the limit of 10. Add a selector if you want the DKIM leg. It reads your DNS, so it shows you the rules that receivers apply to your mail.

Bounces for mail you never sent

Check your Sent folder for the original message before you treat the report as a break-in.

Delivery reports go to the envelope sender, which is a separate address from the one your reader sees. Section 6.1 of RFC 5321 is explicit about it. The notice goes to "the address from the envelope return path (or the Return-Path: line)". A spammer who forges your address in that field points every resulting report at you. Spamhaus calls the result backscatter: "incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam".

When Sent holds no matching message and you do not recognize the attached original, somebody forged your address in the envelope, and your account is not the source. The Mail Delivery Subsystem page has the longer version of this check, including what a p=reject policy does and does not stop.

Hard bounce vs soft bounce

Sending platforms sort bounces into two buckets, and those words belong to the platforms, not to SMTP. Amazon SES defines a hard bounce as "a persistent email delivery failure. For example, the mailbox does not exist", and a soft bounce as "a temporary email delivery failure. For example, the mailbox is full". SES retries soft bounces and does not retry hard bounces.

The first digit of the status code usually decides which label a platform applies: a 4 is a soft bounce, and a 5 is normally a hard one. Gmail's storage pair breaks that rule, because 552 5.2.2 is a 5 for a full mailbox that most platforms treat as soft. Mailchimp says the same thing in its own words: providers bounce messages "based on their own rating systems and definitions". Mailchimp allows 7 soft bounces for an address with no subscriber activity, and up to 15 for a contact with past activity. After that, the soft bounce becomes a hard one.

A platform stops mailing an address once it passes those counts. For a single message from your own mailbox, read the code and act on it.

Free checks worth running

Google's Admin Toolbox Check MX reads MX and SPF records for a domain. Microsoft's Remote Connectivity Analyzer runs an Outbound SMTP Email test, and Microsoft's own bounce pages point admins at it.

For reputation problems at Gmail, Google Postmaster Tools is free and covers the mail you send to personal Gmail accounts. Google hides a day's numbers when the message count for that day is too low, to protect the privacy of individual users. Add the domain before you need the data.

One bounce tells you about one message on one day. Receivers already write your domain a report naming every server that sent as your domain, usually one file a day each, in XML. Those DMARC aggregate reports are how you see every sender at once. Cloudflare's DMARC Management lists each sending source and whether it passed. Cloudflare offers it on every plan to a domain that uses Cloudflare DNS. Postmark's DMARC Digests mail one summary a week. When I last checked, the free tier listed the top 10 mail sources with 5 IPs each and kept 7 days.

This is what we built DomainCanary for. Your reason line pointed at one sender, and the platform that breaks next will do it on its own schedule. On a paid plan we mail you as that failing report arrives, so you hear about a new failing source on the day we see it rather than in the following Monday's digest. You can tell us to hold the digest on a week with nothing wrong; we record it on the dashboard instead, and after 8 held weeks we send the next clean digest anyway. Your first domain is free, and the realtime alerts come with Starter at $19 a month for 3 domains. An aggregate report counts messages by sending IP and never carries a bounce notice, so the message you have open is one we cannot read.