Soft Bounce vs Hard Bounce: What Each One Costs You

A hard bounce means the address is permanently unreachable, usually because it does not exist, and you should delete it. A soft bounce means delivery failed for a temporary reason such as a full mailbox, and it is safe to retry. That is the distinction every email marketing tool teaches, and for a newsletter it is good enough.

For cold email it is not, because it leaves out the category that actually decides whether your campaign survives. A meaningful share of what your dashboard files as a bounce is not a statement about the address at all. It is a statement about you. And Google, to make things worse, returns the exact same code for three completely unrelated problems.

What is the difference between a soft bounce and a hard bounce?

A hard bounce is a permanent failure, reported with a 5xx SMTP code. The receiving server is telling you this address will never accept mail, so stop sending to it. A soft bounce is a temporary failure, reported with a 4xx code, meaning the server could not take the message right now but might later. The sending tool retries soft bounces on a schedule and suppresses hard bounces immediately.

Here is what those codes actually look like. The wording below is quoted from Google's own SMTP error reference for Workspace administrators, read on 17 August 2026.

Why 550 5.7.1 breaks the soft and hard model

Look at rows three, four and five. Google returns 550 5.7.1 for a recipient-side policy rejection, for a spam block, and for rate limiting. Three unrelated conditions, one code. Any tool that classifies bounces purely by the SMTP code, which is most of them, has no way to tell them apart. It sees a 5xx, calls it a hard bounce, and quietly removes the contact from your list.

That behavior is actively harmful in two directions at once. It inflates your hard bounce number with contacts whose addresses were perfectly valid, which makes your list look worse than it is and can send you off buying a verification tool you did not need. And it hides a reputation problem behind a list hygiene label, so the team responds by cleaning data while the actual cause, sending too much from an underwarmed domain, continues untouched.

The 421 4.7.28 row is the same failure inverted. A rate limit arrives as a 4xx, so the tool files it as a soft bounce and does what it always does with soft bounces: it retries. Retrying into a throttle is precisely the behavior the throttle exists to stop. The correct response is to send less, not to send the same thing again in an hour.

The question to ask instead of soft or hard

Replace the binary with one question: is this bounce about the address, or about me?

Address problems are 550 5.1.1 and its equivalents. The record is stale, the person changed jobs, someone mistyped the domain. These are a data quality issue. They cost you a little reputation if there are lots of them, they are fixed by better sourcing and verification, and they do not compound.

Sender problems are 550 5.7.1, 550 5.7.26 and 421 4.7.28. Nothing is wrong with the address. The receiving server has decided something is wrong with your domain, your authentication or your volume. These do compound, because the reputation that triggered the block gets worse every time you keep sending into it. Left alone for a week, a sender problem stops being about one mailbox provider and starts being about all of them.

The practical version of this is a habit rather than a tool. When your bounce rate moves, read the actual response strings before you touch the list, because the code alone will not tell you which of the two problems you have. Any decent sending platform stores the full SMTP response; if yours only shows you a bounce type, that is a real limitation worth weighing.

What is a good email bounce rate?

Under 2 percent is healthy for cold email and under 5 percent is the point where most senders should stop and investigate. Above 5 percent, mailbox providers are already treating your domain as a low quality sender, and pushing more volume through will not outrun it.

One correction worth making here, because it circulates constantly: Google does not publish a bounce rate threshold. What Google publishes in its sender guidelines is a spam complaint rate threshold, which is to stay below 0.3 percent, and it is a different metric measured a different way. Articles that cite "Google's 2 percent bounce limit" are quoting a number Google never set. The 2 percent figure is a sensible industry convention and worth following, but do not treat it as a published rule, and do not let hitting it convince you that your complaint rate is fine.

Should I retry a soft bounce?

Retry the genuine ones and stop retrying the rest. A 452 4.2.2 full mailbox is worth two or three attempts over a few days, and it often clears. A greylisting delay resolves on the first retry, which is what greylisting is designed to do. But a 421 4.7.28 rate limit should reduce your sending, not trigger another attempt, and any 4xx that repeats more than three or four times against the same domain has stopped being temporary in any useful sense.

A reasonable default: three attempts across 72 hours, then move the contact to a review list rather than either deleting it or retrying forever. Contacts that soft bounce repeatedly at one company are usually telling you that company's gateway does not like your domain, which is a sender problem wearing a soft bounce costume.

Do bounces hurt sender reputation?

Yes, and the mechanism is worth understanding because it explains why the address-versus-sender split matters so much. Mailbox providers treat a high rate of invalid recipients as evidence that you did not collect your list yourself, since a sender emailing people who genuinely opted in would not be guessing at addresses. So hard bounces damage you indirectly, as a signal about how you got the data.

Blocks damage you directly. A 550 5.7.1 spam block is not a signal that something might be wrong, it is the receiving server acting on a decision it has already made. By the time you see one, your domain reputation at that provider is already poor, and the recovery is slower than most people expect: reduce volume sharply, fix authentication, and give it two to three weeks of clean sending before pushing capacity back up. There is a fuller walkthrough in our cold email deliverability guide, and if any of your domains are failing 550 5.7.26, the fix is in SPF, DKIM and DMARC explained.

How do I reduce hard bounces?

Hard bounces are almost entirely a sourcing problem, so they are fixed upstream of the send. Verify every address before it enters a sequence, and prefer sources that were checked recently over a list someone exported eighteen months ago. B2B contact data decays at roughly 2 to 3 percent a month through job changes alone, which means a year-old list can be a quarter wrong before anyone has typed anything incorrectly.

That decay rate is the argument for treating your prospect list as a dataset with a freshness requirement rather than a file. The same discipline teams apply when they monitor a warehouse table for staleness and anomalies works here: the useful alert is not that a send failed, it is that failures against one segment have drifted upward over three campaigns while everything else held steady. Our guide on how to build a cold email list covers the sourcing and verification side in detail.

The other half is pacing. A new domain that starts at 500 sends a day will produce blocks that look like bounces no matter how clean the data is, which is why warming each mailbox for two to three weeks and holding it to 20 to 50 sends a day matters more than any list hygiene step. Capacity should come from adding mailboxes, not from asking more of the ones you have.

What is a hard bounce, in one line?

A permanent delivery failure returned with a 5xx code, most commonly 550 5.1.1, meaning the recipient address does not exist and should be removed from your list immediately. The important caveat is the one this whole article is about: not every 5xx is an address problem, and the most common 5xx in cold email, 550 5.7.1, usually is not one.

What is a soft bounce, in one line?

A temporary delivery failure returned with a 4xx code, most commonly 452 4.2.2 for a full mailbox, meaning the server could not accept the message now but may accept it later. Retry it a few times over 72 hours. The caveat, again, is that rate limiting also arrives as a 4xx, and rate limits should never be retried.

Worth remembering that bounces are only the failures loud enough to report themselves. Mail that is accepted and then filed in spam, or accepted and silently discarded, never appears in your bounce column at all, which is the gap covered in inbox placement vs deliverability.

Where AutoMail sits on this

AutoMail records the full SMTP response for every failed send rather than collapsing it into a bounce type, separates address failures from policy and reputation failures, and treats a rate limit as a reason to slow down instead of a reason to retry. It also checks SPF, DKIM and DMARC alignment on each sending domain before the first message goes out, which removes the 550 5.7.26 class of failure entirely, and warms and rotates mailboxes so volume grows at a pace that does not trigger blocks in the first place. You can see the reply and bounce handling in the deliverability tooling, and there is more on the numbers themselves in cold email bounce rate: what is normal and how to fix it.