SMTP bounce codes explained: 4xx vs 5xx and enhanced status codes

Anatomy of an SMTP error

When a mail server refuses a message, it answers with a line like this, and the same line ends up in the bounce message you receive:

550 5.1.1 The email account that you tried to reach does not exist.

• 550 is the basic reply code, defined by the SMTP standard (RFC 5321). Every SMTP server sends one.
• 5.1.1 is the enhanced status code (RFC 3463), a more precise classification that almost every modern server includes.
• The rest is free text. It isn't standardized, but it is often the most useful part: large providers put the exact reason, and sometimes a help link, there.

The basic reply code

The first digit is what decides how the sending server reacts:

RFC 5321 tells the sending side to wait before retrying - the retry interval should generally be at least 30 minutes - and to keep trying for a while: the give-up time "generally needs to be at least 4-5 days". In practice, many senders retry sooner at first and give up earlier.

The reply codes you'll actually see in bounces:

Two quirks are worth knowing. 550 covers both "no such user" and "we don't want your mail", so on its own it tells you little. And RFC 5321 notes that an old standard wrongly used 552 for "too many recipients" - the correct code is 452, and clients should treat a 552 received for that reason as temporary.

Enhanced status codes

RFC 3463 defines a three-part code, class.subject.detail. The class repeats the first digit: 2 success, 4 persistent transient failure, 5 permanent failure. The subject is the most useful part, because it tells you where the problem lies:

The detail codes are registered with IANA. Some are part of RFC 3463, others came later - RFC 7372 added codes for failed email authentication, RFC 7505 the ones for null MX.

Common bounces and what to do

Providers don't always use the codes the same way. RFC 3463 says "mailbox full" should be a transient failure, yet some servers send it as 552 5.2.2; and 5.7.1 covers anything from a blocklist hit to a recipient's "only accept mail from colleagues" rule. The provider-specific guides for Gmail and Outlook decode their texts.

Soft bounce vs hard bounce

These terms come from the email marketing world, not from any RFC, but they map onto the codes like this:

• A soft bounce is a temporary failure - a 4xx reply, or a mailbox-full response. The address is valid; delivery may succeed later. Your server retries on its own.
• A hard bounce is a permanent failure about the address - 5.1.1, 5.1.2, 5.1.10, usually also a repeated 5.2.1. Retrying won't help.
• A block is a permanent failure about you, not the address - 5.7.x policy and reputation rejections. Don't delete the recipient; fix the authentication or reputation problem and the same address will accept mail again.

Remove hard-bouncing addresses after the first bounce. Repeatedly sending to addresses that don't exist is one of the clearest signals of a bought or stale list, and receivers lower your reputation for it. A soft bounce that repeats across many sends over weeks should be treated as a hard one.

Rejected or bounced: when the error reaches you

A failure can surface in two ways:

• During the SMTP conversation. The receiving server refuses with a 4xx or 5xx before accepting the message. Your own sending server then knows the reason first-hand and either retries or writes you a bounce report.
• After acceptance. The receiver answered 250 and later found it couldn't deliver - for example a forwarding address that failed. It must then send a bounce to the envelope sender. When the envelope sender was forged, these bounces hit innocent people: that's called backscatter, and it's why well-run servers try to reject during the SMTP conversation instead of accepting and bouncing later.

What a DSN (bounce report) contains

A bounce message is formally a Delivery Status Notification, defined by RFC 3464. It is a MIME message of type multipart/report (RFC 6522) with report-type=delivery-status and up to three parts: a human-readable explanation, a machine-readable message/delivery-status part, and the original message or its headers. The machine-readable part is what bounce-processing software reads:

Reporting-MTA: dns; mail.example.com
Arrival-Date: Mon, 26 Oct 2026 09:12:44 +0100

Final-Recipient: rfc822; jan@example.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.net
Diagnostic-Code: smtp; 550 5.1.1 User unknown
Last-Attempt-Date: Mon, 26 Oct 2026 09:12:46 +0100

• Action is failed (gave up), delayed (still retrying - a warning, not a bounce), delivered, relayed or expanded.
• Status is the enhanced status code; Diagnostic-Code is the receiving server's exact reply, and Remote-MTA the server that gave it.
• A DSN produced by your own server after a 4xx streak that ran out of time typically carries 4.4.7 or the last temporary error it got.

How AnyMail reports delivery failures

AnyMail sends external mail directly to the recipient's mail server and follows the same rules: a 4xx reply is retried with growing intervals for a little over two days (up to 10 attempts), while a 5xx reply fails the message at once and shows the receiving server's reason next to it. When a message fails for good, an RFC 3464 report lands in the sending inbox, and if delivery is still being retried hours later you get a single "delayed" notice too. Recipients who unsubscribed through the one-click link are treated as permanent failures instead of being mailed again. For incoming mail, AnyMail rejects during the SMTP conversation rather than accepting and bouncing later, so it never produces backscatter.