Bounce Message Analyzer

A bounce is the most honest feedback email gives you: the receiving server tried to deliver your message, couldn’t, and wrote down exactly why. The trouble is that it writes it down in a terse mix of numeric codes and jargon that’s easy to skim past. This analyzer takes a whole bounce — the human sentence, the machine-readable delivery status notification (DSN), or both — and pulls out the codes that matter, tells you whether the failure is permanent or temporary, and gives you the one action that actually resolves it. It runs entirely in your browser; nothing you paste is sent anywhere.

How to read a bounce message

Most bounces carry two layers. First there’s a friendly human paragraph (“Your message wasn’t delivered to…”) that’s written by the sender’s mail server. Below or attached is the part that counts: a DSN block, defined by the mail standards, with structured fields. The ones worth finding:

• Action: — failed, delayed, or delivered. failed is a real bounce; delayed is just a warning that retries are still happening.
• Status: — the enhanced status code, an X.X.X triple like 5.1.1. This is the most precise signal in the whole bounce.
• Diagnostic-Code: — the raw SMTP response the remote server gave, usually starting with a 3-digit reply code like 550 and often repeating the enhanced code and a text reason.
• Final-Recipient: — the address that failed (not always the address you sent to, if forwarding is involved).
• Reporting-MTA: — which mail server generated the report.

The two code systems come from the SMTP standard, RFC 5321 (the 3-digit reply codes), and the enhanced status codes of RFC 3463. You don’t need to memorise them — paste the bounce above and the analyzer maps them for you.

Permanent vs. temporary — the distinction that decides what you do

Before anything else, look at the first digit. It changes the correct response completely:

• 4.x.x / 4xx — temporary (a “soft bounce”). The message couldn’t be delivered right now: greylisting, a full mailbox, a rate limit, a momentary server problem. Your mail server will keep retrying on its own, typically for a day or more. Do nothing, and above all do not remove the address — it’s almost certainly valid.
• 5.x.x / 5xx — permanent (a “hard bounce”). The receiver is telling you this will never succeed as-is: the mailbox doesn’t exist, delivery is refused by policy, or authentication failed. Retrying the identical message is pointless and, worse, repeated hard bounces damage your sending reputation. Fix the cause — remove a dead address, or fix your authentication — before you send again.

One nuance the analyzer handles for you: a few 5xx codes are “softer” than the class implies. A full mailbox (5.2.2) is technically permanent but often clears within days, so it’s worth a limited retry before you suppress the address. The tool flags those cases rather than treating every 5xx as instantly hopeless.

Common bounce codes and what they mean

A handful of codes account for the large majority of real-world bounces:

• 550 5.1.1 — no such user. The single most common hard bounce. Remove the address and verify before adding new ones.
• 550 5.1.10 — the address doesn’t exist at all (often a null MX). Same treatment: remove it.
• 552 / 5.2.2 — mailbox full. Permanent by class, but retry-worthy for a few days.
• 5.2.1 — mailbox disabled or not accepting mail. Suppress it.
• 421 4.7.0 / 4.7.x — temporary deferral or greylisting. Let it retry; don’t touch the address.
• 451 4.3.0 — a temporary local error on the receiver’s side. Retry.
• 550 5.7.1 — blocked by policy, or relaying denied. Check authentication and reputation.
• 550 5.7.26 — Gmail rejected the message for failing authentication. Fix SPF/DKIM alignment and publish DMARC.
• 550 5.7.509 / 5.7.515 — Outlook/Office 365 authentication or DMARC policy rejection. Same fix: aligned SPF and DKIM.
• 554 5.7.1 — rejected as spam or by a blocklist. Run an email blacklist check and review content.
• 5.4.x — routing/DNS trouble reaching the destination. Check the domain’s MX records.

If a code isn’t in the table, the analyzer still tells you its permanent/temporary class and shows the receiver’s raw diagnostic text, which usually spells out the reason in plain words.

What to do after you’ve diagnosed it

The action falls into one of a few buckets. For a hard bounce on a bad address, remove it and tighten your intake by verifying addresses at signup. For an authentication rejection, the fix is in your DNS — line up SPF and DKIM and enforce DMARC. For a reputation or blocklist block, check whether your IP or domain is listed. And when you just want to decode a single code without pasting a whole message, the SMTP Response Code Analyzer is the quicker path. If bounces are piling up across a whole campaign, the guide on why bulk emails fail walks through the systemic causes.

Frequently asked questions

What’s the difference between a soft bounce and a hard bounce?

A soft bounce is temporary (4xx / 4.x.x) — full mailbox, greylisting, rate limit — and retries automatically, so leave the address alone. A hard bounce is permanent (5xx / 5.x.x) — bad mailbox or policy block — so fix the cause and stop sending to it.

Where do I find the codes in a bounce message?

In the DSN block: the enhanced code (e.g. 5.1.1) is on the Status: line and the SMTP reply (e.g. 550) is on the Diagnostic-Code: line. View the full message source if your client hides them.

Should I delete an address after one bounce?

Only for a permanent failure that means the address is bad (e.g. 5.1.1). Keep it on any 4.x.x temporary failure, and give a full mailbox (5.2.2) a few days before suppressing.

My bounce says 5.7.x — is my mail server broken?

A 5.7.x code is a policy/authentication block, not a bad address. Align SPF and DKIM with your From domain, publish DMARC, and confirm you’re not blocklisted.