Email bounce back: how to read the message that came back

Q: Where do I find the actual reason in a bounce-back?

Look for the Diagnostic-Code: line, or the quoted server response beginning with a three-digit number. The first digit sorts the failure (4 temporary, 5 permanent) and the wording after it names the cause: unknown user, full mailbox, policy block, authentication failure.

2026-10-03

The message that comes back has a subject like "Undeliverable" or "Mail delivery failed," a sender like Mail Delivery Subsystem, and a body written by a machine for a machine. Most people read the first line, conclude "it didn't go through," and stop, which is a shame, because a bounce-back is a structured document that almost always contains the exact reason for the failure and, by implication, the fix. This guide is about reading that document: where the diagnostic line hides, how to decode it, and what the most common bounce-back texts are actually asking you to do. If you want the causes of bouncing as a taxonomy rather than a message-reading skill, that companion guide is why do emails bounce.

The anatomy of a bounce-back

Formally the message is a delivery status notification (DSN), and RFC 3464 defines its structure. Three layers matter. The top is a human-readable summary, whose quality varies from Gmail's plain-English explanations to a bare "delivery failed." The middle is a machine-readable block of fields: Action: failed (or delayed), Status: with a three-number code like 5.1.1, and Diagnostic-Code: quoting the exact refusal the receiving server spoke during the SMTP conversation. The bottom is usually your original message or its headers, which tell you which send is being reported on.

The Diagnostic-Code line is the one worth finding. It carries the receiving server's reply, opening with a three-digit code from RFC 5321's grammar: 4xx for a temporary refusal, 5xx for a permanent one (the code families are catalogued in SMTP reply codes). The three-number "enhanced" status beside it, defined in RFC 3463, narrows the subject: codes in the X.1.Z range concern the address, X.2.Z the mailbox, X.7.Z policy and security. That first digit is the sorting decision: 5 means a hard bounce, 4 means a soft bounce if the retries eventually give up, and the operational playbook for each family is in hard bounce vs soft bounce.

"User unknown": the address bounce

Texts like Gmail's 550 5.1.1 The email account that you tried to reach does not exist are among the most common bounce-backs anyone receives. The mailbox was mistyped, deleted, or abandoned. There is nothing to troubleshoot on your side except your list: suppress the address permanently via your platform's suppression list and let double opt-in stop the typos at the door. A close sibling, 550 5.1.2 or "host not found," means the domain itself is wrong or has no MX record; check it with the MX lookup before assuming the address is dead, because a briefly broken DNS zone produces the same text.

"Mailbox full" and other temporary refusals

452 4.2.2 mailbox full, 421 service not available, "try again later": the address is fine and the moment is wrong. Your platform retries these automatically for hours or days before reporting failure, so a bounce-back in this family means the condition persisted through the whole retry window. One occurrence is noise. A pattern across campaigns marks an abandoned mailbox in all but name, which is a list hygiene matter. Gmail makes part of that call for you: its documented 4.2.2 text says the recipient's inbox is out of storage space, while a permanent 5.2.2 variant adds that the inbox is also inactive, which belongs with the address bounces above. A related text worth recognizing is the greylisting deferral, a deliberate first-attempt refusal that resolves on retry and normally never becomes a bounce-back at all.

"Message rejected due to policy": the reputation family

The texts that should stop your morning: 550 5.7.1 with wording like "access denied," "blocked using," "poor reputation," or a blocklist name and URL. Here the receiver is refusing you, not the recipient. Check the sending IP and domain against the major DNSBLs with the blacklist checker (delisting procedure in email blacklist removal), and read the bounce-back as one visible symptom of a sender reputation problem that is probably spam-foldering your mail elsewhere silently; the broader diagnosis lives in why emails go to spam.

"Unauthenticated email is not accepted": the DMARC bounce

A growing family since the mailbox providers' bulk-sender requirements made authentication mandatory: refusals citing SPF, DKIM, or a DMARC policy, such as Gmail's 550 5.7.26 refusals, documented with texts saying the sender is unauthenticated or that unauthenticated email from the domain is not accepted due to its DMARC policy. If your own legitimate mail triggers these, a sending service you use is not covered by your records; verify the triad end to end with the email authentication checker and read DMARC fail for the failure mechanics. If the bounced mail is not yours, your domain's policy just did its job against a spoofer.

Bounce-backs you should distrust

Two special cases. First, backscatter: a bounce-back for a message you never sent means a spammer forged your address somewhere, and the "bounce" is the forgery's echo; do not click anything in it, and let your DMARC policy handle the underlying spoofing. Second, fake NDRs are a phishing genre, imitating delivery failures to bait a click. A real DSN comes from a mailer-daemon address at the receiving side and quotes your actual message; anything asking you to log in to "recover" mail is theater. When in doubt, inspect the headers with the email header analyzer.

From one message to a metric

Read individual bounce-backs to fix individual failures; watch the aggregate to protect your sending. Receivers judge senders partly on what fraction of their mail fails, so a rising bounce rate is both a symptom and, past a threshold, a cause of further filtering. The practical loop: decode the text, act on its family (suppress, wait, or investigate reputation), and let a periodic deliverability score check confirm the sending side of the conversation is not the problem.

Related guides

Why do emails bounce — the causes behind the messages, as a taxonomy
Hard bounce vs soft bounce — the operational split every bounce sorts into
SMTP reply codes — the reference table for the numeric grammar
Email bounce rate — when individual failures become an aggregate problem
Email blacklist removal — the procedure when the text names a blocklist
MX lookup — verify a recipient domain that bounces as unroutable

About this guide

Written by InboxRatio Editorial. DSN structure follows RFC 3464; reply-code grammar follows RFC 5321; enhanced status codes follow RFC 3463. Provider-specific bounce texts quoted (such as Gmail's authentication refusals) come from the providers' published sender documentation. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on protocol and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

3 October 2026. RFC references and provider bounce texts reviewed quarterly.

Frequently asked questions

What does it mean when an email bounces back? The receiving server refused your message, and the refusal was packaged into a delivery status notification and mailed back to you. The notification quotes the server's reply code and text, which state whether the failure is permanent or temporary and why.

Where do I find the actual reason in a bounce-back? Look for the Diagnostic-Code: line, or the quoted server response beginning with a three-digit number. The first digit sorts the failure (4 temporary, 5 permanent) and the wording after it names the cause: unknown user, full mailbox, policy block, authentication failure.

What does "550 5.1.1 user unknown" mean? The recipient mailbox does not exist: a typo, a deleted account, or a departed employee. Suppress the address permanently; resending cannot succeed and repeated attempts damage your sender reputation.

Why did my email bounce back with "mailbox full"? The recipient's storage quota is exhausted, a temporary condition the sending server already retried through. Leave the address in place, but suppress it if the same failure repeats across campaigns, since a perpetually full mailbox is an abandoned one.

I got a bounce-back for an email I never sent. What is it? Backscatter: a spammer forged your address as the sender of their mail, and a misconfigured receiver bounced it to you. Your mail was not compromised by the event itself; a DMARC policy at enforcement reduces how often forgeries succeed.

Should I reply to or resend a bounced email? Never reply; the mailer-daemon is not a mailbox. Resend only after fixing what the text identified: a corrected address, a repaired authentication record, a completed delisting. Blind resends into a permanent refusal only add failure volume.

The bounce-back already told you what went wrong; the skill is looking past "Undeliverable" to the line where it says so. Decode the text, act on its family, and keep the blacklist checker handy for the mornings when the message names you instead of the recipient.