Email bounce rate: hard bounce vs soft bounce explained

A bounce is a message the recipient's server refused to deliver. Sending platforms split bounces into hard and soft, and that split decides whether you drop the address or wait.

A bounce reaches you one of two ways. Most often the server rejects the message during the SMTP session and never accepts it. Sometimes it accepts the message and fails to deliver it later, and then the sender gets a separate report, a delivery status notification (DSN). Its Action field says delayed when the server is still trying and failed when it has given up. A "Delivery delayed" notice is not a bounce yet.

What is a hard bounce

A hard bounce is a 5xx reply. RFC 5321 treats these as permanent: the client should not repeat the same request. When a report says "hard bounced", the receiving server said no, and sending again will not change its mind.

Where hard bounces come from

• The mailbox is gone. Someone left the company, the account was deleted, or the address was mistyped at signup (gmial.com for gmail.com). The server answers 550 5.1.1.
• The domain is gone or takes no mail. If a domain publishes a null MX (RFC 7505), the sending server can refuse right away with 556 5.1.10 and never queue the message at all.
• The address is malformed: a space, two @ signs, forbidden characters. The reply is 553.
• The mailbox is permanently disabled (5.2.1).

Remove an address after its first hard bounce. Mailbox providers and sending services both expect it. Yahoo says a message that gets a 5xx error should not be retried and that list managers need a policy for removing such addresses. The Amazon SES FAQ says to remove bounced addresses and stop sending to them immediately.

5.7.1 is permanent too, but it means a filter or policy refused the message, and 5.3.4 means it was too large. The mailbox is alive in both cases, so deleting it fixes nothing. Look at your own side instead: the blocklists, your SPF, DKIM and DMARC setup, the size of your attachments.

What is a soft bounce

A soft bounce is a 4xx reply. The address most likely exists, but the server cannot take the message right now. RFC 5321 files a reply as transient if the identical request could succeed when repeated.

Why a server asks you to wait

• The mailbox is full (452, the second code 4.2.2). Once the owner clears space, mail gets through.
• The receiving server is overloaded or down for maintenance (421).
• Greylisting: an unfamiliar sender gets a temporary error on the first try, usually 450 or 451, and is accepted on the retry.
• You exceeded a rate limit and the server wants you to slow down.
• The mailbox is temporarily blocked by server policy, a case RFC 5321 names in its description of 450.

A temporary error does not lose the message. The sending server queues it and tries again. RFC 5321 says the retry interval should generally be at least 30 minutes and that the sender should keep trying for at least four to five days before giving up. If nothing works by then, a DSN with failed goes back, and the soft bounce shows up as a hard one. Sending platforms usually run a shorter retry window of their own.

If an address bounces once, leave it on the list. If it bounces campaign after campaign, a counter decides. Mailchimp, for example, allows seven soft bounces for a contact with no activity and up to fifteen for one who has engaged before, then treats the address as a hard bounce and cleans it.

Hard bounce vs soft bounce

SMTP error codes: reading a bounce

A server reply carries two codes. The three-digit one comes from RFC 5321. The second, shaped like 5.1.1, is an enhanced status code from RFC 3463 and narrows down the cause. This is how Gmail answers mail for a mailbox that does not exist:

550-5.1.1 The email account that you tried to reach does not exist.

Basic reply codes

The 552 caveat is in RFC 5321 itself. The old standard wrongly assigned 552 to "too many recipients", so clients are told to treat that 552 as temporary; the correct code is 452. And 550 covers more than a missing mailbox, since policy rejections use it too. Decide by the second code and the reply text, not by the first digit alone.

Enhanced codes worth telling apart

Some reports mention an "error 571". The standard does not define such a code, but some servers send it; read it as 5.7.1.

Bounce rate: formula and what is acceptable

Bounce rate is the number of bounces divided by the number of messages sent, times 100. Send 2,000 messages, get 30 back, and the rate is 1.5%.

bounce rate = bounces ÷ sent × 100%

Platforms do not all count the same way. Amazon SES counts only hard bounces, and only to domains you have not verified; a full mailbox or a blocked IP does not enter its bounce rate. It also measures over a "representative volume" of your mail rather than a fixed period. Numbers from different services are not directly comparable.

So what counts as acceptable? There is no single answer. Mailbox providers do not publish their bounce limits, and Mailchimp explains that the limits vary and that spammers should not get the details. The most concrete public numbers come from Amazon SES:

• keep the bounce rate below 2%;
• at 5% or more, the account is placed under review;
• at 10% or more, sending may be paused until the issue is fixed.

Those figures work as a benchmark elsewhere too. For transactional mail the bar is lower: a real person just typed the address, so a noticeable share of bounces means the signup form does not check it.

A message the provider files as spam is not a bounce and never shows up in the bounce rate. If bounces are rare but almost nobody opens, find out why your emails go to spam.

Why bounces hurt your reputation

Amazon SES notes that mailbox providers and anti-spam organizations use high bounce rates to spot senders with bad practices, and that the result can be mail landing in the spam folder instead of the inbox. A sender who keeps mailing addresses that do not exist clearly does not know where the list came from.

The second risk is quieter. Some spam traps are converted from addresses that once worked, then sat unused and bounced for a long time. Mail to such a trap arrives without any bounce, yet hitting it shows that hard bounces were never removed.

How to handle bounces after a campaign

1. Export the bounces and split them by code: 5xx and 4xx.
2. Put addresses with 5.1.1, 5.1.2, 5.1.10 and 553 on the suppression list for good.
3. Do not blindly delete 5.7.1 and 5.3.4. Check which provider they came from and fix the reputation or the message size.
4. Keep a per-address counter for 4xx. A streak across several campaigns means the mailbox is abandoned.
5. Calculate the campaign's bounce rate and compare it with earlier sends.

The suppression list has to cover every channel. A common mistake is keeping it inside the marketing platform while transactional mail leaves through your own server. The address is suppressed for campaigns and still gets receipts, bounces pile up, and the reports never show why.

An "I'm on vacation" reply is, under RFC 3834, an ordinary message marked Auto-Submitted: auto-replied. Count such replies apart from bounces or they will skew your numbers.

How to reduce your bounce rate

• Validate the list before sending. A validator finds dead mailboxes and domains without mail before they turn into hard bounces. The uChecker report sorts addresses into valid, invalid and unknown, with a reason for every rejected one.
• Check the address right in the signup form. Amazon SES also suggests asking people to type it twice.
• Use double opt-in: a confirmation email never reaches a typo.
• Do not buy or rent lists. It is the first item on the Amazon SES list.
• Mail an old list you have not used in a while in small batches, and only after checking it.