How to Read an Email Bounce Message and Find the Real Cause

Learning how to read an email bounce message turns a wall of technical text into a single, fixable cause. A bounce is really a Delivery Status Notification, or DSN: an automated report from a mail server telling you a message did not reach someone. Buried in it is the exact reason, written by the server that refused delivery.

The skill is knowing which two or three lines matter and which are noise. This guide walks the anatomy of a bounce, decodes the status codes against the standards that define them, and shows how to tell a dead mailbox from a policy block, so you know whether to fix the address, wait, or stop sending.

The short answer#

To read a bounce, find three things: the recipient address that failed, the enhanced status code, and the Diagnostic-Code line. The status code's first digit tells you if the failure is permanent (5) or temporary (4). The Diagnostic-Code quotes the receiving server word for word, and that is your real cause.

A permanent 5.1.1 on a nonexistent mailbox means fix the address or drop it. A temporary 4.x.x code usually means the server will retry on its own. A 5.7.x code is a policy or security block, not a mailbox problem, and needs a completely different fix.

What a bounce message actually is#

A bounce is not written by your email app. A mail server generates it, sometimes your own outbound server and sometimes the recipient's, and formats it as a DSN under RFC 3464. That shared format is why bounces from Gmail, Outlook and a self-hosted server all carry the same core fields.

A full DSN has three parts: a human-readable note that says the message could not be delivered, a machine-readable message/delivery-status block, and often a copy of the original message's headers. The machine-readable block is the one worth reading. These are the fields inside it that matter.

• Reporting-MTA: the server that generated the report. Outlook labels this the Generating server.
• Final-Recipient: the address that failed, as the reporting server saw it.
• Action: what happened, which RFC 3464 limits to failed, delayed, delivered, relayed or expanded.
• Status: the enhanced status code, written in class.subject.detail form.
• Remote-MTA: the next server that reported the problem, present only if a different one was involved.
• Diagnostic-Code: the actual response text from the transport, usually the SMTP line that names the cause.

A worked example: reading one bounce#

Here is the message/delivery-status block from a typical hard bounce. Read Action first, then Status, then Diagnostic-Code.

Action: failed and a 5.x.x Status both say permanent. The Remote-MTA line tells you the recipient's server (mx.acme.example), not yours, is the one that rejected the message. The Diagnostic-Code is decisive: the address does not exist. The fix is the address, not your setup.

How to read a bounce, step by step#

1. 1

   Skip the friendly summary

   The first line usually says something like message not delivered and tells you nothing new. Scroll to the technical block, labelled message/delivery-status, Diagnostic information for administrators, or the quoted server response.

2. 2

   Find the failed recipient

   Read the Final-Recipient field, or the address after a phrase like the response was. A single bounce covers one recipient, so if you emailed several people, match the address before you diagnose.

3. 3

   Read the first digit of the Status code

   5 means permanent: resending the same message will not help. 4 means temporary: the server is probably retrying already. 2 means success. This one digit decides whether to act or wait.

4. 4

   Decode the middle and last digits

   The middle digit names the subsystem: .1 addressing, .2 mailbox, .4 network or routing, .7 security or policy. The last digit is the specific condition. So 5.1.1 is a permanent addressing failure, meaning no such mailbox.

5. 5

   Read the Diagnostic-Code text

   This is the receiving server's own sentence, and it beats any lookup table because it is what actually happened. Mailbox full, user unknown, or message rejected due to policy: the words name the cause.

6. 6

   Check who reported it

   If a Remote-MTA is present, the recipient's server refused the message. If it is absent, your own sending server generated the report, which points at a connection or configuration problem on your side.

What each part of a status code means#

The enhanced status code is three numbers separated by dots, defined by RFC 3463 as class.subject.detail. Reading it left to right narrows the failure from broad to specific.

Common bounce codes and what to do#

These are the codes you meet most often, mapped to the standard and to a next step. Always read them beside the Diagnostic-Code text, which can add detail the number alone cannot carry.

Mailbox problem or policy block? Read the middle digit#

The most useful judgment a bounce lets you make is mailbox problem versus policy block, and the middle digit of the status code decides it. A .1 or .2 code is about the address or the mailbox, so the problem sits with the recipient. A .7 code is about policy or security, so the problem sits with your message or your sending reputation.

That split changes the fix completely. A 5.1.1 means the person's address is wrong or gone, and no amount of authentication setup helps. A 5.7.1 means a server chose to refuse you, so fixing SPF, DKIM, DMARC or your reputation is the path, and correcting the address does nothing.

How Gmail, Outlook and other servers show the same bounce#

The DSN format is shared, but each platform dresses it differently. Here is where the machine-readable cause hides in each, so you know exactly what to scroll to.

What to do when the bounce doesn't tell you enough#

Some bounces are genuinely unhelpful: a bare 550 with no text, or a code that seems to contradict the wording. When the report runs thin, these moves recover the real cause.

• Only a three-digit reply code, no enhanced code? A 5.x.x is still permanent and a 4.x.x still temporary. Read the plain-language text after it, because the server usually explains itself.
• Code and text disagree? Trust the Diagnostic-Code text and the Remote-MTA. The number can be a generic default the software fell back to.
• A vague 5.7.1 policy block? The cause is on the sending side. Check your SPF, DKIM and DMARC alignment, and whether your sending IP or domain sits on a blocklist.
• Bounces for mail you never sent? That is backscatter: a spammer forged your address as the sender. Do not act on the contents.
• A relayed or expanded Action? Another system took over delivery, so the final rejection may arrive later as a second, separate report.

A faster way to read, and filter, your bounces#

Reading one bounce by hand is quick once you know the fields. The cost is repeating it for every failed send, across every account, and telling the real failures apart from the forged ones. AI Emaily is the mail client where these reports arrive, and its triage pulls the failed recipient and the Diagnostic-Code line to the top of the thread, so you read no such mailbox or policy block without expanding the raw DSN.

The same layer helps with backscatter: its spam protection catches forged failure notices for mail you never sent, so they stop crowding the genuine ones. It is a mail client, not a deliverability service. It will not diagnose your SPF, DKIM or DMARC or tell you why a domain is blocklisted; for that, use your provider's postmaster tools. We build AI Emaily.