How to Read a Bounce-Back Email and Find the Real Error

Learning how to read a bounce back email saves you from the worst habit in email troubleshooting: pasting the whole wall of text into a search box and hoping. A bounce looks like noise, but it is a structured report, and only one small part of it names the exact reason your message failed.

That structure has a name. A bounce-back is formally a Delivery Status Notification, or DSN, and its format is defined by RFC 3464. Once you know where the code lives and how to read it, you can jump straight to the fix for your specific error instead of guessing. This guide walks the anatomy, the codes, and the three steps to pull out the real error.

What a bounce-back email actually is#

A bounce-back is an automated message from a mail server telling you it could not deliver what you sent. No person wrote it. By convention it arrives from an address like MAILER-DAEMON or postmaster, which is why people call it a mailer daemon message — the daemon is just the background process that generates the report.

Microsoft and Exchange call the same thing a non-delivery report, or NDR, and put 'Undeliverable:' in the subject line. Gmail, Outlook, Apple Mail, and every other provider send the same kind of report, because they follow the same standard. What differs is how much of it each app shows you by default.

Under the surface, a DSN is usually built from three parts: a plain-English explanation for humans, a machine-readable status block for software, and a copy of your original message's headers. The middle part carries the code you need. Most apps show you the first part and hide the second.

The parts of a bounce that carry the error#

RFC 3464 defines a set of named fields inside the machine-readable block. You do not need all of them. Four fields tell you almost everything: which server reported the problem, what it decided to do, the standardized status code, and the server's own raw reply.

The Status field is the value worth extracting — the enhanced status code. The Diagnostic-Code is the raw line the receiving server sent back, so it often repeats the same numbers plus a sentence. When the two disagree in wording, trust the numeric Status field to classify the failure and read the Diagnostic-Code for the specific detail.

What the enhanced status code means#

The enhanced status code is three numbers separated by dots, in the form class.subject.detail. RFC 3463 defines it so the meaning holds no matter which server sent it. Read it left to right.

• Class — the first digit — is the outcome. 2 is success, 4 is a temporary failure, 5 is a permanent one.
• Subject — the middle number — is the category: 1 is addressing, 2 is the mailbox, 4 is network or routing, 7 is security or policy.
• Detail — the last number — pins the specific reason within that category.

The first digit decides your next move. RFC 3463 defines class 4 as a persistent transient failure, where 'sending in the future may be successful', and class 5 as a permanent failure that is 'not likely to be resolved by resending the message in the current form'. In plain terms: a 4 may clear on its own; a 5 will not until you change something.

From code to fix, at a glance#

Put the pieces together and reading a bounce becomes a short routing exercise: find the block, read the class digit to know whether resending can ever work, then take the full code and jump to its specific fix. The diagram traces that path.

Step 1: Find the delivery-status block#

Most apps hide the machine-readable block by default. Here is how to reveal it so you can read the fields above rather than the provider's paraphrase.

1. 1

   Open the bounce, not the original

   Open the message from MAILER-DAEMON, or the one with 'Undeliverable:' in the subject. That is the report; your sent message is a copy tucked inside it.

2. 2

   In Gmail, show the original

   Open the bounce, click the three-dot menu, and choose 'Show original'. The delivery-status section appears with the Reporting-MTA, Status, and Diagnostic-Code fields.

3. 3

   In Outlook, expand the details

   An Outlook NDR shows a summary first. Look for 'Diagnostic information for administrators', or open the message headers, to see the raw status and diagnostic code.

4. 4

   Look for a value in class.subject.detail form

   Scan for a number like 5.1.1 or 4.2.2. That is the Status field, and it is what you actually search for.

Step 2: Read the code from left to right#

With the Status value in front of you, decode it in the order it is written. Each position narrows the diagnosis.

1. 1

   Read the class digit first

   A leading 5 is permanent: do not resend the same message. A leading 4 is temporary: it may deliver on a retry, so wait before you change anything.

2. 2

   Read the subject digit

   A 1 points at the address, a 2 at the mailbox, a 4 at the network or routing, a 7 at security or policy. This tells you which system failed.

3. 3

   Read the detail digit

   This pins the exact reason. 5.1.1 and 5.2.2 share the same class but describe a missing address versus a full mailbox.

4. 4

   Cross-check the diagnostic code

   The Diagnostic-Code line usually repeats the number with a sentence. Use it to confirm you read the right value, especially when a message had more than one recipient.

Step 3: Search the exact code, not the whole message#

Now you have a precise, standardized string. Search that, and the results will be about your actual failure instead of a hundred unrelated bounces.

1. 1

   Search the full enhanced code

   Search the complete value, like '550 5.7.1' or '5.1.1', plus the provider name. The three-number code is standardized; the surrounding sentence is not.

2. 2

   Include the provider that bounced you

   The Reporting-MTA tells you who rejected the message — Google, Microsoft, or the recipient's own server. Their published wording for the same code differs, so name them in the search.

3. 3

   Work out which end to fix

   A permanent 5.1.1 is usually the recipient's address; a 5.7.1 is usually a policy on their side or your own sending reputation. The code tells you where the problem lives.

4. 4

   Match it to the specific guide

   Once you have the code, go to the page for that exact error. Our guides for 550 5.1.1 and 550 5.7.1 cover each cause and fix in depth.

How to tell a hard bounce from a soft bounce#

You will see the terms hard bounce and soft bounce everywhere, especially in email-marketing tools. They are not in the RFCs — they are plain-language shorthand for the class digit you just read.

• A hard bounce is a permanent failure: a class 5 code. The address is wrong, the domain cannot receive mail, or a policy refused you. Resending the same message will not work.
• A soft bounce is a temporary failure: a class 4 code. The mailbox was full, the server was busy, or the message was greylisted. It often clears on a later retry.
• The same problem can be either. A full mailbox is 4.2.2 while the server keeps trying, and 5.2.2 once it gives up — the class digit is the whole difference.

Preventing the bounces you can control#

You cannot prevent every bounce — a recipient closing their account is out of your hands. But most avoidable bounces come from a short list of habits.

• Keep your contact list clean: a 5.1.1 on an address you email often means it is dead, so remove it.
• Type addresses carefully, or pick them from autocomplete; a single wrong character produces a 5.1.1 or 5.1.2.
• For any bulk sending, authenticate your domain with SPF, DKIM, and DMARC — missing authentication drives 5.7.x policy rejections.
• Watch for repeat soft bounces: a 4.x.x that never clears is usually a deliverability or reputation problem worth investigating.
• Save the bounce. The Status code and the Diagnostic-Code line are the evidence you will want if you have to ask the recipient's admin to allowlist you.

The code tells you which end to fix, and the authorization codes — the 5.7.x family — usually trace back to the account a message was sent from and whether its domain is authenticated. AI Emaily is a mail client that sends through your existing, authenticated Gmail, Outlook, or IMAP account, so day-to-day mail inherits that account's SPF, DKIM, and DMARC instead of adding an unauthenticated hop that earns a 5.7.x bounce. It will not repair a broken DNS record or a reputation problem — it is a client, not a deliverability service, so the steps above stay the real fix. We build AI Emaily, and there is a 7-day free trial if you want to see how it handles a working inbox.