How do enhanced status codes (X.Y.Z) work?

You send an email, it bounces, and your logs spit back something like 5.1.1 or 4.7.0. The three-digit SMTP code tells you roughly what happened. The enhanced status code (the X.Y.Z part) tells you exactly what happened.

Enhanced status codes were defined in RFC 3463 as a way to give machines (and humans) a more precise read on delivery results. They always appear alongside a basic SMTP reply code, never instead of one.

How the three parts break down

Each code follows the format X.Y.Z, and every digit carries a specific meaning.

X is the class. This is the most important digit. It tells you whether the situation is permanent, temporary, or fine.

• 2 means success. The message was accepted.
• 4 means a temporary failure. Try again later.
• 5 means a permanent failure. Don't try again without fixing the underlying problem.

Y is the subject category. It narrows down which part of the email system raised the flag.

• 0 = Other or undefined
• 1 = Addressing (the recipient address itself)
• 2 = Mailbox (the inbox or storage)
• 3 = Mail system (the receiving server)
• 4 = Network and routing
• 5 = Mail delivery protocol
• 6 = Message content
• 7 = Security or policy

Z is the specific detail. This is the most granular layer. It pinpoints the exact condition within the subject category. A 7 in the subject category means something security-related happened. A 7.1 means delivery wasn't authorized. A 7.26 means a DKIM signature was missing.

The codes you'll actually see in the wild

Most of what you'll encounter in bounce logs and delivery reports comes down to a handful of codes.

• 5.1.1 The recipient address doesn't exist. Suppress it.
• 5.1.2 The recipient domain can't be reached. Check if the domain is live.
• 5.2.2 The mailbox is full. This is technically a soft problem but if it's consistent for that address, it's worth flagging as inactive.
• 5.2.3 The message is too large. Reduce your email size or strip heavy attachments.
• 5.7.1 Delivery not authorized or message refused. Usually a policy block. Could be authentication, a blocklist, or the receiving server's own rules.
• 4.7.0 Temporary authentication failure. Your sending credentials had a hiccup. Try again, but investigate if it repeats.
• 4.4.2 Connection timed out. A network or server availability issue, not a problem with your message.

The critical difference between 4xx and 5xx behavior

When the class is 4, your sending server is supposed to retry. The receiving server is saying "not now" rather than "never." Most ESPs will retry for 24 to 72 hours before giving up and reporting a bounce.

So when the class is 5, you stop. Retrying a 5xx is a signal that you're ignoring clear rejection signals, which damages your sender reputation. A good ESP will hard-bounce the address immediately and suppress it from future sends. (If yours doesn't do this automatically, that's worth looking into.)

The practical takeaway is that 4xx codes require patience and monitoring. 5xx codes require action on your list.

If you're seeing a spike in 5.7.1 rejections, there's a good chance your domain or IP has landed on a blocklist or your authentication is broken. You can check both with our free blocklist checker and SPF checker. And if the bounce codes in your logs are confusing, the email header analyzer can help decode what's actually happening end to end.