Soft Bounce vs Hard Bounce: What the Codes Mean and What to Do

A hard bounce is a permanent failure: the receiving server answered with a code that starts with 5 (such as 550 5.1.1, "the email account that you tried to reach does not exist") and sending again won't change the answer. A soft bounce is temporary: the code starts with 4 (such as 452 4.2.2, "the recipient's inbox is out of storage space") and the same email may go through later. Stop emailing a hard-bounced address for good. Let a soft bounce retry, and look closer if the same address keeps soft-bouncing.

That's the textbook split. For cold email there's a second split that matters more: some 5.x.x codes don't mean the address is gone, they mean the receiver blocked you. Below are Gmail's own codes with its wording, which bucket each one belongs in, and what to do about it.

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

Every bounce carries an enhanced status code of three numbers, class.subject.detail. The first number is the class:

The three-digit code in front (550, 452, 421) is the older SMTP reply code and follows the same rule: 4xx is temporary, 5xx permanent.

What do the Gmail bounce codes mean?

These are from Google's list of Gmail SMTP errors (updated 22 October 2026). Gmail has several messages for some codes; this is the most common wording.

Outlook.com has its own version of the authentication block: 550 5.7.515 for high-volume senders whose mail fails SPF, DKIM and DMARC.

Which hard bounces mean the address is bad, and which mean you are?

Read the middle number. In 5.1.x (addressing) and 5.2.x (mailbox) the problem is on the recipient's side: the person left the company, the address was guessed wrong, the mailbox is dead. Suppressing the address is the whole fix.

In 5.7.x (security and policy) the address is usually fine. The receiver refused your email: it failed authentication, it looked like spam, or your domain or IP has a bad reputation. Suppressing those addresses and carrying on is the wrong move. The next email to a perfectly good address will get the same answer, and every refusal makes the reputation worse. Check your domain's SPF, DKIM and DMARC (our free check does all three plus 9 blacklists in a few seconds), then look at volume and the list.

A campaign that suddenly returns 5.7.1 from Gmail after weeks of normal results has a reputation problem, not a list problem. Stop that domain's sending for a few days rather than pushing through.

Where do bounces show up when you send from your own mailbox?

Mostly as an email. When you send through Gmail, Google Workspace or Microsoft 365, your provider accepts the message first and delivers it a moment later. If the receiving server refuses it, the bounce comes back to the sending mailbox as a delivery report from mailer-daemon@ or "Mail Delivery Subsystem", usually within a minute, with the code in its body. A soft bounce often arrives first as a "delivery delayed" notice, and then either nothing (it got through) or a final failure days later.

That's why a cold email tool has to read the sending mailbox to know about bounces at all. A tool that only looks at whether the send succeeded will report a 100% delivery rate for a list full of dead addresses.

Errors at send time are different: they come from your own provider, not the recipient. Gmail refusing to send because you hit your daily limit, or a login that stopped working, is a problem with the mailbox, not a bounce from the lead.

How do you fix a soft bounce?

Mostly you don't: the retry does it. The ones worth acting on:

• The same address soft-bounces on every step. A full inbox for weeks is an inbox nobody reads. Remove it after two or three in a row.
• 4.2.1 or 4.7.28 from Gmail. These are about your sending rate. Spread emails over more of the day, lower each mailbox's daily number, and check the Gmail sending limits you're closest to.
• Many soft bounces from one company's domain. Their server may be rate limiting you or quietly filtering. Send fewer emails to that domain per day.

What is a good bounce rate for cold email?

Bounce rate is bounced emails divided by emails sent, so 6 bounces in 200 emails is 3%. Count each address once: a lead who bounces on step 1 shouldn't be emailed again on step 2.

You'll find many "good bounce rate" numbers online, mostly from newsletter tools whose lists people opted into. We won't add another invented benchmark. Here is what we built into Ballast as our own defaults, and why:

• Above 1% hard bounces (on 20+ emails), a mailbox starts taking fewer new leads, down to a quarter of its daily limit at 5%.
• Above 5% over its last 200 emails (at least 50, within 7 days), a mailbox is quarantined until a person looks at it.
• A campaign pauses at 5% by default, and the whole workspace can never be set above 8%.

The reasoning: on a verified list, hard bounces should be rare. Five in a hundred means the list wasn't verified, or a source sold you guesses, and every one of those bounces tells Gmail and Microsoft that you email people you don't know. Google also says sending to many addresses that don't exist can block a Gmail account from sending for up to a day.

How do you prevent hard bounces?

1. Verify the list before the first email. A verifier (MillionVerifier, ZeroBounce, NeverBounce and others) checks that each mailbox exists without sending anything. Paying per address is cheaper than a new domain.
2. Treat catch-all domains as risky. A catch-all server accepts every address at the SMTP check, so the verifier can't tell, and the bounce comes later. Send to them in small numbers, or leave them out.
3. Re-verify old lists. People change jobs. A list that was clean six months ago isn't now.
4. Suppress every hard bounce, across every campaign. An address that bounced in one campaign shouldn't be in the next one.

When this doesn't apply

If you send newsletters or receipts through an email service (Mailchimp, SendGrid, Postmark), that service reads bounces and suppresses addresses for you; check its settings rather than building your own handling. This guide is about cold email sent from your own mailboxes, where nobody does it unless your tool does.

How Ballast handles bounces

Ballast reads each sending mailbox's inbox for delivery reports and matches each one to the exact email it's about, by the Message-ID the report quotes. A hard bounce (any 5.x.x, or wording that means the address is gone) marks the lead bounced, adds the address to the workspace's suppression list so no campaign emails it again, and counts toward the breakers above. Ballast counts the 5.7.x blocks as hard bounces too: it would rather pause a campaign that's being refused than keep sending into a wall. Soft bounces are logged and left to the retry. A sending tool should be able to say no, and that's where ours does. The sending safety docs list every threshold.

FAQ

What is a hard bounce in email?

A permanent delivery failure with a 5.x.x code, most often 550 5.1.1: the address doesn't exist. Sending again gives the same result, so the address should be suppressed.

What is a soft bounce in email?

A temporary failure with a 4.x.x code, such as a full inbox (452 4.2.2) or a server that's busy or rate limiting you. The sending server retries, and the email may still arrive.

Should I remove hard bounces from my list?

Yes, the ones in 5.1.x and 5.2.x: those addresses are gone. For 5.7.x blocks, keep the address and fix your authentication or reputation first, because the next email to a good address would be refused the same way.

How many soft bounces before I remove an address?

Two or three in a row on the same address, spread over different days. One soft bounce means nothing.

Is a 42% bounce rate good?

That number is usually a website bounce rate (visitors who leave after one page), a different metric. For email, a 42% bounce rate means the list is mostly dead addresses: stop sending and verify it.

Does a soft bounce hurt deliverability?

One doesn't. Many soft bounces for rate reasons (4.2.1, 4.7.28) are a warning that you're sending faster than the receiver likes. Slow down before they turn into blocks.

Sources

• Gmail SMTP errors and codes, Google Workspace, updated 22 October 2026, checked 25 October 2026.
• RFC 3463: Enhanced Mail System Status Codes, for the class, subject and detail structure.
• Gmail sending limits, Google Help, checked 20 October 2026.
• Outlook's requirements for high-volume senders, Microsoft Tech Community, checked 16 October 2026.