Short answer
A soft bounce is a temporary failure: the receiving server answers with a 4xx code (mailbox over quota, rate limited, try again later) and the sending server retries. A hard bounce is a permanent failure: a 5xx code, where sending the same message again won't work.
The code tells you which, but not why. A hard bounce about the address (550 5.1.1, the mailbox doesn't exist) means stop sending to it. A hard bounce about the sender (550 5.7.26, failed authentication) means the address is fine and your setup needs fixing. Suppress the first kind; fix the cause of the second.
Soft bounce and hard bounce, defined
| Topic | Soft bounce | Hard bounce |
|---|---|---|
| Also called | Deferral, temporary failure, transient failure | Permanent failure, rejection |
| SMTP reply code | 4xx, for example 421, 450, 452 | 5xx, for example 550, 552, 554 |
| Enhanced status code | 4.x.x, for example 4.2.2, 4.7.0 | 5.x.x, for example 5.1.1, 5.7.1 |
| What the standard says | The error is temporary and the request may be made again | The client should not repeat the exact request |
| What the sending server does | Keeps the message in its queue and retries | Stops and reports the failure |
| What you do | Usually nothing; let the retries run | Depends on whether it's about the address or about you |
Reply classes from RFC 5321, section 4.2.1; enhanced status classes from RFC 3463.
RFC 5321's rule of thumb: a reply is 4xx if the same command could succeed if repeated unchanged, and 5xx if something has to change first, such as the spelling of the address or the recipient's account status. RFC 3463 says the same for its classes: 4.x.x is a "persistent transient failure" where "sending in the future may be successful", and 5.x.x is a permanent failure.
"Bounce" is used loosely. Strictly, a soft bounce is a deferral, and you only get a bounce message if the sending server gives up. RFC 5321 suggests retrying for at least 4 to 5 days before giving up, though providers choose their own window.
How to tell them apart
A bounce carries a three-digit reply code, usually an enhanced status code, and a line of text from the receiving server. Read them in that order:
- First digit of the reply code:
4is a soft bounce,5is a hard bounce. - First digit of the enhanced code repeats it:
4.x.xor5.x.x. - Middle digit of the enhanced code says what the problem is about:
1addressing,2the mailbox,3the mail system,4network and routing,5the protocol,6the message content,7security and policy. - The text says why, in the receiver's words. It's often the only way to tell whether a
5.7.1is about you or the recipient.
452 4.2.2 The recipient's inbox is out of storage space. Please direct the recipient to [...]550 5.1.1 The email account that you tried to reach does not exist. [...]550 5.7.26 This email has been blocked because the sender is unauthenticated. [...]The same mailbox can produce either kind. Gmail answers 452 4.2.2 when a recipient's inbox is out of storage, and 552 5.2.2 when it's out of storage and inactive. The first will probably clear; the second probably won't.
Common soft and hard bounces
Soft bounces (4xx)
| Code | What it means | About |
|---|---|---|
452 4.2.2 | Mailbox full (Gmail: "The recipient's inbox is out of storage space") | Recipient |
450 4.2.1 | The recipient is receiving mail too fast (Gmail) | Recipient |
421 4.7.0 | Try again later. At Gmail, also used for a missing PTR record or very low IP or domain reputation | Often the sender |
421 4.7.28 | Gmail has seen an unusual rate of mail from your IP or domain | Sender |
421 4.7.26 | Rate limited because the message is unauthenticated (Gmail) | Sender |
451 4.3.0, 421 4.4.5 | A temporary problem or a busy server at the receiver | Receiver |
Wording from Google's Gmail SMTP error list.
Soft bounces aren't always harmless. Gmail uses 4xx replies to slow down senders it doesn't trust yet, so a run of 421 4.7.0 or 421 4.7.28 deferrals is an early warning about your reputation or authentication, not a recipient problem.
Hard bounces (5xx)
| Code | What it means | About | What to do |
|---|---|---|---|
| 550 5.1.1 | The mailbox doesn't exist | Address | Suppress |
552 5.2.2 | Mailbox full, and at Gmail also inactive | Address | Suppress; send again only if the person tells you it's cleared |
| 550 5.7.26 | Gmail: unauthenticated, or failed your DMARC policy | Sender | Fix SPF, DKIM and DMARC |
| 550 5.7.1 | Delivery not authorized: a block, a policy or a recipient restriction | Usually the sender | Read the text, fix the cause |
| 554 5.7.1 | Transaction failed: relay denied, blocklist or policy | Usually the sender | Read the text, fix the cause |
| SPF PermError | Your SPF record can't be evaluated | Sender | Fix the SPF record |
| 550 permanent failure | A generic permanent refusal with the detail stripped | Depends | Find the receiver's original reply |
What to do with each
- Soft bounces: let the retries run. Your provider queues the message and tries again. Don't resend it from your own code as well, or the person may get two copies once the first one is delivered.
- Repeated soft bounces from many recipients at one provider: slow down. Google's sender guidelines say that if messages start bouncing or being deferred, reduce the sending volume until the error rate falls.
- Hard bounces about the address: suppress. Stop sending to the address until the person gives you a corrected one. Google's guidelines say to automatically unsubscribe recipients who have multiple bounced messages.
- Hard bounces about you: fix the cause, keep the address. Read the text. Authentication failures are fixed in DNS (SPF, DKIM and DMARC); blocklist listings need delisting (blocklist checker).
- Fix the source of bad addresses. Most
5.1.1bounces start as a typo at sign-up. A verification email, or a check on the address before you accept it, catches them before they cost you.
What's a good bounce rate?
Lower is better, and there's no single published line. Google's sender guidelines set a limit for spam complaints (below 0.3% in Postmaster Tools, ideally below 0.1%), not for bounces; for bounces they say to remove addresses that keep bouncing and to slow down when bounces or deferrals rise.
As a practical bar, Groundmail's own new-account sending limit only grows while an account's bounce rate stays under 2% (and complaints under 0.1%). Transactional mail to people who just signed up usually sits well below that. A sudden jump almost always means one of three things: a batch of imported or old addresses, a broken sign-up form, or a receiver blocking you, which shows up as 5.7.x bounces rather than 5.1.1.
Count only address bounces in that rate. Block bounces say nothing about your list, and counting them hides the real cause.
How Groundmail handles soft and hard bounces
| What the receiver said | What Groundmail does | Address suppressed? |
|---|---|---|
A temporary 4xx | Retries automatically. The email shows delayed, an email.delivery_delayed webhook fires, and the receiver's reply is kept in delivery.deferred_response. If the receiver keeps deferring until the retries run out, the email ends as failed with an email.failed webhook. | No |
A permanent refusal of the address (550 5.1.1, disabled mailbox, 552 5.2.2 mailbox full) | Sets bounce_type: "hard" on the email and keeps the reply in bounce_reason. The email is bounced (with an email.bounced webhook) when the receiver sent a bounce message, or failed (with email.failed) when it refused the email during delivery. Later sends to the address return 422 with it under suppressed. | Yes, automatically |
| A refusal of the sender (blocklist, reputation, failed authentication, spam policy) | Marks the email bounced with bounce_type: "block" and fires email.bounced. The bounce doesn't count toward your bounce rate. | No: you can send to it again once the cause is fixed |
A refusal for the message's size (552 5.3.4) | Marks the email failed with bounce_type: null. A smaller email reaches the same person. | No |
Groundmail reads the receiver's whole reply, not just the code, to tell an address bounce from a block. Before a send goes out, Groundmail validation also holds back addresses that can't receive mail (a malformed address, a domain with no mail server, a mailbox already known not to exist), so many hard bounces never happen. If a suppressed person tells you their address works again, remove it with DELETE /suppressions. Details are in the emails, webhooks and suppressions docs.
Frequently asked questions
Is a soft bounce bad for deliverability?
One isn't. A full mailbox or a busy server is the recipient's problem and clears on retry. Many soft bounces from one mailbox provider are different: Gmail and others defer mail from senders with low reputation or failing authentication, so read the text of the deferrals.
When does a soft bounce become a hard bounce?
When the sending server gives up retrying, the message fails for good and you get a bounce, but the cause was temporary, so the address may still be fine. Don't suppress an address for a single expired deferral. If one address soft-bounces on every send for weeks, it's probably abandoned.
Should I retry a hard bounce?
Not the same message to the same address. If the bounce was about the address, suppress it. If it was about you (a 5.7.x block), fix the cause first; once it's fixed, new mail to that address can go out normally.
Is a full mailbox a soft or hard bounce?
Either. RFC 3463 describes mailbox full as a condition the recipient can fix by deleting messages, and many servers answer 452 4.2.2 (soft). Some answer 552 5.2.2 (hard); Gmail uses it for a full mailbox that's also inactive.
What's the difference between a bounce and a block?
Both are refusals, usually 5xx. A bounce in the strict sense is about the address: it can't receive mail. A block is about the sender: the address is fine but the receiver won't take mail from you right now. They need opposite responses: suppress the address, or fix your setup and keep it.
Sources
Facts on this page about other companies' products, prices and policies come from these public pages. They change, so check them before you decide.