Are bounce codes standardized across the industry?

You open your bounce report and see a wall of codes. Some say 550 5.1.1. Some say 550 Mailbox does not exist. One from a corporate server just says User unknown. Are any of these the same thing? Sort of, yes. But only in the loosest sense.

Here's the short version: the number is standardized. The text is not.

Every mail server follows SMTP standards that define three code families. A 2xx means delivery succeeded. A 4xx means a temporary failure (try again later). A 5xx means a permanent failure (stop trying). That structure comes from RFC 5321 and every serious mail server respects it. So when you see a 5xx, you can trust that the bounce is hard, regardless of where it came from.

Then there's a second layer called enhanced status codes, defined in RFC 3463. These look like 5.1.1 and add more detail. The first digit mirrors the SMTP class (5 is permanent), the second points to the category (1 is addressing), and the third is the specific condition (1 is bad destination mailbox). So 550 5.1.1 is technically the same across providers: the address doesn't exist.

That's where standardization ends. After the code, providers write whatever they want. Gmail might say "The email account that you tried to reach does not exist." A corporate server running its own filtering might just say "User unknown." Outlook adds its own proprietary identifiers on top (things like BL000001 or policy codes that are completely Outlook-specific). Same underlying reason for rejection, totally different message text.

This matters practically because many bounce parsers rely on matching message text, not just the code. If your ESP or your own code is looking for specific phrases like "does not exist" to classify a bounce, it'll miss rejections that say "Mailbox unavailable" or "No such user here." You end up with a bunch of bounces sitting in an ambiguous bucket.

So the better way to read a bounce is to work in layers:

1. Look at the 3-digit SMTP code first. 5xx is a hard bounce. 4xx is soft (and worth retrying before giving up). This part you can trust.
2. Check the enhanced code if there is one. 5.1.1 or 5.1.2 tells you why the address failed with more precision. This part is usually reliable.
3. Treat the message text as a hint, not a rule. It adds context, but it varies by provider. Use it to confirm what the code already told you, not to make the classification yourself.

One thing to watch for: some providers deliberately obscure rejection reasons. Gmail in particular sometimes returns a soft bounce code for what is effectively a permanent problem, or gives you a vague rejection to avoid revealing how their filtering works. So even the codes aren't always the full story.

If you're seeing a lot of ambiguous bounces you can't classify cleanly, that's worth digging into. Our SOS hotline is free if you want a second pair of eyes on a specific bounce pattern.