A bounce is the receiving server telling you, in a defined format, precisely why it would not take your message. Most senders treat the whole bounce as noise and retry blindly, which is how a temporary block becomes a permanent reputation problem. The information you need to respond correctly is in two numbers, and once you can read them the right action is usually obvious.
The Basic Reply Code
Every SMTP response starts with a three-digit code. The first digit is the one that tells you whether to give up or try again.
| First digit | Class | Meaning |
|---|---|---|
2xx |
Success | Accepted (e.g. 250 OK) |
4xx |
Transient | Temporary failure. Retry later. |
5xx |
Permanent | Hard failure. Do not retry; fix or suppress. |
This first split decides everything. A 4xx is the server saying "not now," and your MTA should queue and retry with backoff. A 5xx is the server saying "not ever, as things stand," and retrying a 5xx is worse than pointless: hammering a server that already hard-refused you looks like abuse and can escalate a soft reputation issue into a block.
451 4.7.1 Greylisted, please try again in 300 seconds ← retry, this is normal
550 5.1.1 User unknown ← suppress this address forever
554 5.7.1 Message rejected due to content ← fix the message, do not resend as-is
The Enhanced Status Code
Behind the basic code sits a more precise one defined by RFC 3463: three numbers separated by dots, class.subject.detail. This is where the reason lives, and it is far more useful than the basic code for deciding what to do.
5 . 1 . 1
│ │ └── detail: bad destination mailbox address
│ └────── subject: addressing status
└────────── class: permanent failure
The middle digit, the subject, is the fastest way to categorize a bounce:
| Subject | Category | Typical cause |
|---|---|---|
.1.x |
Addressing | Mailbox does not exist, address rejected |
.2.x |
Mailbox | Full, disabled, or over quota |
.4.x |
Network/routing | Loops, no route, DNS problems |
.5.x |
Protocol | Command out of sequence, unsupported |
.7.x |
Security/policy | Auth failed, blocked, spam, TLS required |
The .7.x family is the one deliverability people live in. A 5.7.1 is a policy rejection: the server decided your mail is unwelcome, which covers everything from a blocklist hit to a DMARC failure to "we do not accept mail from you."
Block Bounces and Address Bounces Need Opposite Handling
The single most important distinction to draw is between a bounce about the recipient and a bounce about you. They call for opposite responses.
# recipient problem: suppress the address, keep sending to everyone else
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown
# sender problem: STOP the stream, this is about your IP or content
554 5.7.1 Service unavailable; Client host 203.0.113.25 blocked
using Spamhaus; see https://check.spamhaus.org/...
Treating the second one like the first is a classic mistake. You suppress the recipient, shrug, and keep sending, while the actual message ("your IP is blocked") goes unread and the rest of your mail to that provider keeps failing. A block bounce naming a blocklist is a signal to check your reputation immediately.
Build Your Bounce Handling Around the Split
Automated bounce processing only needs to route on the pattern:
if code starts with 4 -> transient: let the MTA retry, do nothing
if code is 5.1.x / 5.2.x -> recipient: suppress this address
if code is 5.7.x -> policy/block: alert a human, check reputation
else 5.x.x -> log and review
The 5.7.x branch is the one that should page someone. When a receiver starts returning policy rejections that name a blocklist, every minute you keep sending into it deepens the problem, and the bounce text itself often tells you exactly which source to start with, the way our walkthrough of reading a Spamhaus listing traces one back to its cause. That is exactly the moment where knowing your listing status ahead of the bounce would have let you pause the stream first. Generator Labs blacklist monitoring watches your IPs and domains across hundreds of data sources and alerts when a listing appears, so by the time a 5.7.1 block bounce arrives, you already know. When a bounce does name a source, a quick blacklist check confirms the scope before you decide how to respond. Start monitoring.