Hard vs Soft Bounces: What the SMTP Codes Mean and What to Do

The first digit decides

When your server hands a message over, the receiving server answers with a three-digit SMTP reply code (RFC 5321). A code starting with 5 is a permanent failure: the server will not take this message, and sending the same thing again gets the same answer. That is a hard bounce. A code starting with 4 is a temporary failure: try later. That is a soft bounce, and your server retries on its own before giving up.

Most servers add an enhanced status code after the reply code (RFC 3463), such as 5.1.1. Its first digit repeats the class; the other two say why. x.1.x is about the address, x.2.x the mailbox, x.7.x security and policy. That middle digit is the one that tells you what to do.

Five codes you will actually see

The first four are Gmail's replies, shortened; the last is a typical greylisting answer. Other providers word them differently but use the same codes.

550 5.1.1  The email account that you tried to reach does not exist
           -> hard: the address is wrong or deleted. Suppress it.
550 5.7.26 Unauthenticated email ... is not accepted
           -> hard for this message, but the address is fine.
              Fix SPF, DKIM and DMARC, then send again.
452 4.2.2  The recipient's inbox is out of storage space
           -> soft: the server retries. Repeated, treat as abandoned.
421 4.7.28 Unusual rate of unsolicited mail
           -> soft: Gmail is rate limiting your domain or IP. Slow down.
451 4.7.1  Greylisted, please try again later
           -> soft: expected once from a new sender. The retry gets in.

The second line is the one that catches people out. A 5.7.x refusal is permanent for that message, but it says nothing bad about the address. Gmail returns 5.7.26 when the message fails authentication. Suppressing every address that bounced this way would wipe out a healthy list because of a DNS record. Check the domain with the deliverability checker, fix the record, and send again.

What to do with each

• Address does not exist (5.1.x). Suppress it after the first bounce. Your sending service usually does this for you; make sure your own database agrees, or the next import puts the address back.
• Policy or authentication (5.7.x). Do not suppress. Read the text after the code, fix the cause, and resend. If the same address keeps refusing after the fix, treat it as a block and contact the provider.
• Mailbox full or server busy (4.x.x). Let the retries run. If the same address soft-bounces on three to five sends in a row, suppress it: that inbox is probably abandoned.
• Rate limited (4.7.x). This is about you, not the recipient. Send less per hour and let your reputation catch up, the same way you would during a domain warm-up.

Slow delivery is often a soft bounce you never saw

A soft bounce that succeeds on retry never reaches your bounce report. The message just arrives late. RFC 5321 recommends waiting at least 30 minutes between attempts and trying for four to five days before giving up, so a password reset that was greylisted on the first try can land half an hour after the user asked for it.

If mail from a new domain is consistently late, look at the receiving server's answers in your sending service's logs. Greylisting fades once your server has retried successfully a few times; a 4.7.x rate limit fades only when the volume or the complaint rate comes down. To see where the hours went on a message that did arrive, paste its raw headers into the email header analyzer: each Received hop carries a timestamp.

Why the rate matters

Inbox providers read a high bounce rate as a sign the list was bought, scraped or left to rot. Google's sender guidelines ask bulk senders to keep their lists clean and stay under a 0.3% spam rate; sending services set their own bounce thresholds and pause accounts that cross them. Resend's warm-up guidance, for instance, treats 4% as the point to stop and investigate.

Suppressing hard bounces promptly is the cheapest thing you can do for that number. The rest is not collecting bad addresses in the first place: confirm sign-ups, and remove people who have not opened in a long time before they turn into bounces. For the records that keep 5.7.x refusals away, see the email deliverability guide.