Email deliverability

Email bounce message explainer

Paste a bounce (an “undeliverable” or “delivery failed” message) and see what went wrong, who has to act and how to fix it. It’s read in your browser; an AI explanation is there if you want one.

By using these tools you accept the Terms and the Privacy page.

Read in your browser. Nothing is sent unless you ask for the AI explanation, which sends only the error part, with the name before every @ removed.

Try an example:

How the bounce message explainer works

The bounce explainer turns a non-delivery report into a plain answer: what failed, who has to act and what to do next. It is for anyone who got an “undeliverable” message back, whether you sent the mail or run the system that sent it.

How it decides what happened

First it cuts off the copy of the original message that many bounces carry, so its text can’t be mistaken for the error. If the bounce has delivery status fields (RFC 3464), the Status of the failed recipient decides. Otherwise the first 4xx or 5xx code in the text does.

Then it compares the error lines with known wording, from specific provider and blocklist messages down to generic phrases such as “user unknown”, and only searches the rest of the text when nothing matches. The match sets the cause, the steps and who needs to act; without one, the enhanced code’s category is used. The first digit and the delivery action decide how final it is.

The six verdicts

  • Hard bounce: the address can’t receive mail. Don’t send to it again.
  • Refused: the receiving server turned this message down, but the address may be fine. Fix the cause, then resend.
  • Soft bounce: a temporary problem; the sending server retries for a while.
  • Gave up: the sending server retried until it stopped. The last error it got is the real cause.
  • Delayed, not bounced: delivery is still being retried, and a new report follows if it fails.
  • Unclear: no clear delivery error was found.

Using the details

The codes table lists the 4xx and 5xx codes in the bounce (up to 60 different ones) with the standard that defines each. The details pull out the recipient, the receiving server, and any sending IP address or sending domain named in the error. An IP links to the blacklist check, a sending domain to the DMARC checker.

When another tool can check the cause, the steps link to it, prefilled with the domain, IP address or recipient the bounce names. Copy explanation gives you a text version for a support ticket.

Getting a better answer

Paste the whole bounce when you can: the delivery status fields name the failed recipient, the action and the server that refused. Pastes over 200,000 characters are refused, so leave out attachments.

The optional AI explanation reads at most 8,000 characters, putting the lines with codes first when a bounce is longer. It is given the verdict above and explains it rather than deciding a new one. It usually answers in 5 to 20 seconds and gives up after 50; the page counts the seconds while you wait. The same excerpt asked again within a day is usually answered from a cache instead of the AI, and there is a daily limit.

Updated · Maintained by Liviu Tanase

Questions

What can it explain?

Bounces from any mail server. It reads the delivery status fields (RFC 3464), the basic SMTP reply codes such as 550 (RFC 5321), every enhanced status code in the IANA registry such as 5.1.1 (RFC 3463 and later), and the known wording of Gmail, Microsoft 365 and Outlook.com, Yahoo and AOL, plus the Spamhaus, Barracuda, SpamCop and Proofpoint blocklists.

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

A hard bounce means the address can’t receive mail: the mailbox or its domain doesn’t exist, or the account is disabled. Stop sending to it. A soft bounce is temporary, such as a full mailbox, greylisting or rate limiting; the sending server retries for a while. A refusal is a third kind: the address may be fine, but the receiving server refused this message, for example because authentication failed or the sending IP is on a blocklist.

How do I read a code like 550 5.7.26?

550 is the basic reply code: 2 means delivered, 4 temporary, 5 permanent. 5.7.26 is the enhanced code: the same first digit, then the area (1 address, 2 mailbox, 3 mail system, 4 network, 5 protocol, 6 content, 7 security or policy), then the detail. Providers also use their own details, such as Microsoft’s 5.7.509; the explainer says when a code isn’t in the standard registry.

What does 550 5.1.1 mean?

The recipient’s mailbox doesn’t exist at that domain (“bad destination mailbox address”, RFC 3463), so the explainer calls it a hard bounce. Check the address for typos; if it’s right, remove it from your lists, because repeated bounces to dead addresses hurt your sending reputation. The email address checker tests a single address before you send again.

What do 550 5.7.1 and 5.7.26 mean?

Both refuse the message, not the address. 5.7.1 means a policy, spam filter or blocklist said no, and the text after it says which. 5.7.26 means several authentication checks failed: the sending domain needs SPF, DKIM and DMARC that pass. If the text names a blocklist, look up the sending IP address with the blacklist check.

Is my bounce sent anywhere?

Not unless you ask for the AI explanation. The explainer runs in your browser, and the bounce is never put in the page link or saved. Explain with AI sends only the error part to zerobounce.ai, which passes it to Anthropic’s API (Claude): the original message is cut off first and the name before every @ is replaced, and the page shows exactly what will be sent. zerobounce.ai doesn’t keep the text; the answer is cached for up to a day under a hash of it, so asking again usually doesn’t call the AI twice. Anthropic handles it under its API terms.

How reliable is the AI explanation?

The verdict, the codes, their meanings and the steps come from fixed rules, the standards and the providers’ own documentation. The AI is given that verdict with the codes and only explains it, staying with what it is sure of, but AI text can be wrong.

Why would a real address bounce?

Because the receiving server refused the message, not the address. Common causes: SPF, DKIM or DMARC failing for the sender’s domain, the sending IP address on a blocklist, a poor sending reputation, missing reverse DNS, content or attachments a filter blocks, or a message over the size limit. The explainer names the cause and the tool to check it with.

Should I remove addresses that bounce?

Remove hard bounces after the first one: mail providers watch how often a sender hits addresses that don’t exist. For soft bounces, many senders remove an address after several in a row over a few weeks. Validating a list before sending keeps bounces down in the first place.