Skip to content
notspoofed.comSPF · DKIM · DMARC

Email Bounce Decoder

Paste a bounce message and find out what actually went wrong — whether it is permanent, whose problem it is, and the specific fix for the provider that rejected it.

Forwarded, quoted and multipart bounces all work. Nothing you paste is stored.

Why the code alone is not enough

Every bounce decoder can tell you that 5.7.1 means “delivery not authorized”. That is true and almost useless, because 5.7.1 is the most overloaded code in email: it covers authentication failures, relaying denials, blocklists, content rules and DMARC rejections. Four of those need completely different responses and one of them is not your problem at all.

What identifies the cause is the text around the code. A gsmtp suffix means Gmail. An S3150 means Outlook.com has blocklisted your network, and its advice to contact your ISP is misleading — it is the sender who has to request delisting. A code in the 5.7.606 to 5.7.649 range means Microsoft has banned your sending IP and there is a specific portal for it. This tool reads those strings and shows the provider’s own remedy.

It also tells you plainly when it cannot identify something. A decoder that guesses sends people to rewrite DNS records that were never the problem, so an unrecognised bounce says so and lists what it looked for.

Common questions

What is the difference between a hard and a soft bounce?
A hard bounce is permanent — the address does not exist, or the receiver will never accept it. Remove it from your list. A soft bounce is temporary: a full mailbox, a server that is down, or rate limiting. Leave it alone and let your mail server retry. Getting this backwards is expensive in both directions, because suppressing on a soft bounce loses a real subscriber and retrying a hard bounce damages your sending reputation.
Is a 5.x.x code always permanent?
Not in practice. A full mailbox is 5.2.2 on some systems and 4.2.2 on others, for exactly the same condition. The sensible policy is to treat a full mailbox as temporary until it repeats over several days, and this decoder classifies by what you should actually do rather than by the first digit.
Why does the same code mean different things?
Because 5.7.1 in particular is the most overloaded code in email — it covers authentication failures, relaying denials, blocklists, content rules and DMARC rejections. The number narrows it down to "refused on policy grounds" and no further. That is why this tool reads the provider-specific error text alongside the code, which is the part that identifies which of those you actually have.
Do I need the whole bounce message?
No, but more is better. A bare code gives you the generic meaning. The full bounce lets the decoder identify which provider rejected it and show that provider’s own remediation path, which is usually the difference between knowing what the code means and knowing what to do.
The bounce says to contact my ISP. Should I?
Usually not. That wording appears in Outlook.com blocks and misleads almost everyone who reads it — the block is on the sending network, so it is the sender who has to act, through Microsoft’s delist portal. If you are on shared hosting, though, it is genuinely your host who has to request removal.
Do you store the bounce I paste?
No. It is parsed in memory to produce the result and never written to disk or to a database. The structured result — the code, the classification and the fix — is stored for 90 days so a permalink can be shared, and nothing else is kept.

Guides by error code

If the question is what to suppress rather than what one code means, hard bounce or soft bounce covers the decision every bounce forces — and why the 4xx/5xx shorthand gets it wrong often enough to cost you.

If the cause turns out to be authentication, the unsubscribe checker and the SPF, DKIM and DMARC checker are where to fix it.