Hard bounce vs soft bounce: what's the difference and what should you do?

When an email can't be delivered, the receiving server answers with a status code. Senders sort those failures into two buckets: hard bounces, which are permanent, and soft bounces, which are temporary. The difference decides what you do next: retry, remove the address, or fix something on your side. This guide explains how the codes map to each, and how to handle them without damaging your list or your reputation.

What is the difference between a hard and soft bounce?

"Hard" and "soft" aren't terms from the email standards. They're industry shorthand, and the M3AAWG Sender Best Common Practices define them:

• Hard bounce: delivery failed "due to a permanent failure such as the email address no longer exists or has never existed, or the domain no longer exists or has never existed."
• Soft bounce: delivery failed "due to a temporary failure such as a full mailbox, a connection problem, a technical issue at the provider, or throttling" of the sending IP.

The standards behind them are SMTP reply codes in RFC 5321 and enhanced status codes in RFC 3463.

How do status codes tell you which kind of bounce it is?

A rejection usually carries two codes, for example 550 5.1.1. The first is the SMTP reply code. The second is the enhanced status code, written as class.subject.detail.

The class: first digit

RFC 3463 defines three classes:

RFC 5321 gives a rule of thumb for the reply codes: a reply is 4yz if the same command could succeed if repeated without any change. A 5yz reply means the client "SHOULD NOT repeat the exact request."

The subject: second number

The middle number tells you what went wrong:

The subject matters as much as the class. A 5.1.1 and a 5.7.1 are both permanent, but they call for opposite actions.

Which bounces mean you should remove the address?

Here's how common codes sort out in practice. Each link goes to our reference page for that code.

Why "mailbox full" is a special case

RFC 3463 says the mailbox-full code X.2.2 "should be used as a persistent transient failure," which means a 4.2.2. In practice many servers send 552 5.2.2 with a permanent 5 class. The RFC's intent is clear: a full mailbox can be emptied, so it's a soft condition. Don't remove the address on the first one.

Why policy rejections aren't list problems

M3AAWG notes that "many types of 5xx codes indicate a policy violation according to the descriptive text," and that the text might show the sender's IP "is on a blocklist/blacklist." The address may be perfectly valid. The receiver objected to your server, domain or message. Removing the recipient hides the problem instead of fixing it. Check the IP with the Blacklist Checker and the PTR Lookup, and test authentication with the Email Deliverability Test.

What happens to a soft bounce over time?

Your mail server handles soft bounces for you. It keeps the message in its queue and retries. RFC 5321 says the "give-up time generally needs to be at least 4-5 days." If every retry fails, the server finally returns a bounce, often with the delivery-time-expired code X.4.7. RFC 3463 describes it as a message "considered too old by the rejecting system."

M3AAWG stresses that senders must not treat temporary failures as permanent, "because some receivers will tempfail or greylist an initial message to see if the sender is following the RFCs correctly, as spammers generally do not do so."

Bounces also arrive in two ways. Most are synchronous: the receiver rejects the message during the SMTP conversation, and your server or platform records it at once. Some are asynchronous: the receiver accepts the message, then sends a bounce message to your Return-Path address, sometimes hours or days later. M3AAWG notes that B2B mail "may have a higher rate of asynchronous bounces." Your system needs to process both.

If you're receiving bounces for messages you never sent, that's backscatter, not a delivery problem with your mail. See our guide on backscatter bounce messages.

What about bounces from everyday business email?

Bounces aren't only a newsletter problem. When a colleague emails a customer and gets a non-delivery report back, the same logic applies:

• 5.1.1 or 5.1.10 usually means a typo or an address that no longer exists. Check the spelling, then ask the contact for their current address.
• 5.2.2, mailbox full, means the message may get through later. Wait, then try again or use another channel.
• 5.7.x means the receiver refused your organization's mail. Pass the full bounce to whoever manages your email, because other people's messages are probably failing too.

Our guide to reading email headers helps when you need to trace where a message went.

Why do bounces matter for deliverability?

Receivers read a high bounce rate as a sign of a careless sender. M3AAWG says "many times a receiver will penalize a sending IP for too many messages that end up bouncing with permanent failures," and that large volumes of hard bounces "are too often indicative of a poorly managed registration process or an old or misapplied mailing list."

The providers say the same in their own words:

• Yahoo's best practices tell senders to "monitor hard and soft bounces as well as inactive recipients" and to remove invalid recipients promptly.
• Microsoft's sender guidance says invalid addresses that produce non-delivery reports "put your outbound email at risk for further scrutiny by email filtering services."
• Google's sender guidelines say that if messages start bouncing or being deferred, "reduce the sending volume until the SMTP error rate decreases."

How do you keep your list clean?

1. Suppress hard bounces at once. A "user unknown" or "domain doesn't exist" reply means stop. M3AAWG: "it is very important this message not be retried and the email address be suppressed from future mailings."
2. Track soft bounces per address. M3AAWG says "generally it is considered a best practice to remove an address from the list if it bounces consecutively at least two times over two weeks or more."
3. Read the text, not just the code. M3AAWG notes the numeric codes "do not clearly state whether or not the address should be removed." The descriptive text tells you whether it's the address or your setup.
4. Separate policy bounces. Route 5.7.x rejections to whoever runs your email setup, not to list cleanup.
5. Confirm addresses at sign-up. Google advises confirming each recipient's address before subscribing them. A confirmation step stops typos and fake addresses entering your list.
6. Share one suppression list across every tool that mails the same people.
7. Watch for sudden jumps. A spike in hard bounces after importing contacts means the import was bad. Stop and clean it before the next send.

If you're bringing a new domain or IP online, bounces are one of the first signals to watch; see how to warm up a new domain or IP.

Next steps

1. Look up any bounce code you don't recognize in the SMTP Error Code Lookup.
2. Set your sending platform to suppress hard bounces immediately and soft bounces after repeated failures.
3. For 5.7.x rejections, check your IP with the Blacklist Checker and your authentication with the Email Deliverability Test.
4. If mail is delivered but lands in junk, read why your emails are going to spam.

Browse more guides on running email day to day.