CloudWizard.eu Blog

Hard vs Soft Bounces Explained

Not all bounces are the same. Treating them the same way is one of the most common mistakes in email marketing — and it's one that quietly kills sender reputation over time.

Hard bounces

A hard bounce means permanent failure. The address doesn't exist, the domain is gone, or the server has explicitly rejected the message in a way that says "don't try again." The SMTP code is usually 5xx — 550, 551, 553. Whatever the specific reason, the message is: this address is dead, move on.

Hard bounces should go straight to your suppression list, immediately, after the first occurrence. There's no benefit in trying again. Continuing to send to known-bad addresses is one of the fastest ways to damage your sender score.

Soft bounces

Soft bounces are temporary failures. The mailbox is full. The server is down. The message was too large. The SMTP code is 4xx — these are transient errors that suggest trying again later might work.

The right approach with soft bounces is to give them a few attempts over a few days, then suppress if they keep failing. Most senders use a threshold — three or four consecutive soft bounces and the address gets treated like a hard bounce. The exact number is up to you, but you need some threshold, otherwise you'll be retrying dead addresses forever.

The grey area

Some bounces are ambiguous. "Policy rejection" could mean a spam filter blocked you (fixable) or the domain has blocked your entire IP range (not so fixable). "Mailbox unavailable" might be temporary or permanent depending on the server. These are worth logging separately so you can review them, rather than automatically suppressing or ignoring.

Why this distinction matters

If you suppress on the first soft bounce, you'll throw away valid subscribers who just had a full inbox. If you never suppress soft bounces, you'll keep hammering addresses that haven't worked in months. Neither is great.

The goal is a clean feedback loop: hard bounces out immediately, soft bounces monitored and suppressed after a reasonable threshold, ambiguous cases logged for review. It sounds like overhead, but once it's automated it runs itself.