Hard bounce or soft bounce?

Every bounce forces one decision: remove this address, or leave it and try again. Getting it wrong is expensive in both directions. Suppress too eagerly and you lose subscribers who were never unreachable. Retry a permanent failure and you accumulate the unknown-user rate that spam filters watch most closely.

The usual shorthand — 4xx is soft, 5xx is hard — is close enough to be believed and wrong often enough to cost you.

What the two actually mean

A hard bounce is a permanent refusal. The address does not exist, the domain does not exist, or the receiver will never accept mail for it. The answer will not change tomorrow. Remove the address.

A soft bounce is a temporary refusal. A full mailbox, a server that is down, greylisting, rate limiting. Your mail server queues the message and retries on its own schedule, usually for several days. There is nothing for you to do and nothing to remove.

Almost everything downstream — list hygiene, reputation, whether your next campaign lands — follows from classifying these correctly.

Why the 4xx/5xx rule fails

The clearest case is a full mailbox. Some receivers report it as 4.2.2 and some as 5.2.2 — the same condition, on the same day, from the same recipient, classified differently depending on whose server answers. The 5.x.x prefix says permanent. The reality is that people empty their mailboxes.

Suppressing on the first 5.2.2 means removing a real subscriber because they were on holiday with a full inbox. The right policy is to treat it as temporary and only suppress after it repeats for a week or so.

It runs the other way too. Microsoft returns 5.2.2 Submission quota exceeded for a completely different situation — your sending account hitting a rate limit, not the recipient’s mailbox being full. Same code, opposite meaning, and Microsoft’s own documentation notes it usually indicates a compromised account.

This is why the numeric code alone is not enough, and why this suite’s bounce decoder classifies by what you should actually do rather than by the first digit.

The classification worth using

Sort by whose problem it is, not by the number:

• Your problem — fix and stop sending. 5.1.1 user unknown, 5.1.2 domain not found, malformed addresses. A typo or a person who has left. Remove immediately; the answer will never change.
• The recipient’s problem — wait, then give up. Full mailboxes, disabled accounts, servers that are down. Retry for a few days. If it persists for a week or more, the address is abandoned in practice.
• Your reputation — stop and investigate. Blocklistings, policy rejections, throttling. These are not about the address at all, and suppressing the recipient fixes nothing. Continuing to send makes it worse.
• Your authentication — fix DNS. 5.7.26, SPF and DMARC failures. Every message you send is affected, not just this one.

The last two categories are the ones people mishandle by pruning their list. A blocklisting does not improve because you removed the recipient who happened to surface it.

A workable policy

1. Hard bounce: suppress on the first one. No retries, no exceptions. Retrying an address that does not exist is the fastest way to build the unknown-user rate receivers use as a spam signal.
2. Soft bounce: let the queue do its job. Do not requeue manually and do not resend — you are adding load to a server already saying it cannot take more.
3. Soft bounces that repeat: suppress after three to five sends across at least a week. A mailbox full for a fortnight is abandoned, whatever the code says.
4. Reputation bounces: stop the campaign. These are the ones where continuing does real damage, and they are the ones people most often push through.

Worth knowing: a high bounce rate is itself a spam signal, separately from the bounces. Receivers read a sender with many unknown-user failures as someone mailing a purchased or ancient list, and filter accordingly. Cleaning the list is usually a faster fix than anything technical.

Working out which one you have

The numeric code narrows it down; the text after it identifies it. A 550 with no enhanced code covers everything from a typo to a blocklisting, and 5.7.1 alone spans authentication, relaying, blocklists and content.

Paste the whole bounce into the decoder rather than just the code. With the full text it identifies which provider rejected it and gives that provider’s own remedy — which is usually the difference between knowing what the code means and knowing what to do.