What is a hard bounce? Difference from Soft bounce

What is a hard bounce? Permanent delivery failure without deleting the customer

The important word is delivery. A hard bounce is evidence about an email address or delivery attempt, not a reason to delete the entire customer profile, order history, or consent record.

The protocol underneath the label

SMTP itself does not define a universal business object called "hard bounce." It provides reply codes and delivery-status semantics. RFC 5321 describes 5yz replies as permanent negative completion responses: the requested action did not occur, and the client should not repeat the exact request in the same sequence. RFC 3463 similarly defines 5.X.X enhanced status codes as permanent failures that are not likely to be resolved by resending the message in its current form.

Email service providers then map those protocol outcomes into friendlier categories such as hard bounce.

What a sending platform should do

Amazon SES defines its Bounce sending event as a hard bounce when the recipient's mail server permanently rejects the message. It also notes that soft-bounce information can appear after SES has exhausted retries.

Sending platforms commonly map a permanent delivery event to a suppression action for the affected destination. That is a provider implementation, not a new SMTP standard. The operational response is still clear: stop repeatedly attempting marketing delivery to an address that produced a permanent failure.

Hard bounce versus soft bounce

The table is a mental model, not a parser. Providers can classify ambiguous outcomes differently, and the actual SMTP response is more informative than a generic label.

When can a hard-bounced address become sendable again?

Be conservative. An address that did not exist yesterday could be created later, but blindly reactivating it creates repeated-bounce risk. A typo can be corrected when the recipient supplies or confirms the correct address. A provider-side false classification can sometimes be resolved through support evidence.

Platform behavior varies. A delivery suppression should be treated separately from an ordinary preference change, and any reactivation should require evidence that the destination or the classification has changed.

Worked example

A merchant sends to alex@gmial.com and receives a permanent recipient-domain failure. The order record also contains the customer's phone number and purchase history.

• The correct response is to suppress the bad email destination and, if the customer later provides alex@gmail.com, treat that as a corrected address with its own delivery history. Deleting the entire customer would throw away valid commerce data because one channel endpoint was invalid

Now consider a different message to alex@gmail.com that receives a permanent policy rejection because the sender's domain fails authentication. That should trigger a sender-infrastructure investigation. Changing Alex's address would solve nothing.

What passes and what does not

• An invalid recipient is the classic hard-bounce example:
• 550 5.1.1 User unknown
• But permanent delivery failure can also result from policy, sender, or content conditions. The precise enhanced status code and diagnostic text matter
• This distinction changes the action:
• invalid/nonexistent recipient: suppress that destination from future email
• domain or address typo: correct only when you have evidence of the intended address
• policy rejection: investigate authentication, reputation, content, or provider policy before concluding the recipient itself is invalid
• blocked sender: fix the sender-side problem rather than editing the customer's email address
• A system that turns every 5xx into "delete contact" destroys useful customer data and can hide a sender-side incident

Common mistakes

1. Deleting the customer record because one email address hard bounced
2. Treating every hard bounce as "mailbox does not exist."
3. Retrying permanent failures repeatedly
4. Dropping the original SMTP diagnostic and keeping only a generic label
5. Unsuppressing an address merely because the user is still subscribed in a consent field
6. Mixing email deliverability state with SMS, push, or other channel eligibility

Hard bounce checklist

• A durable contact system should preserve more than a boolean hard_bounced=true
• Useful fields include:
• email address
• event timestamp
• sending provider
• campaign or transactional stream
• SMTP reply and enhanced status code where available
• normalized bounce category
• suppression reason
• whether the failure applies to email delivery only or a broader contact state
• source event ID for auditability
• This lets you distinguish "user unknown" from "sender rejected by policy" months later

Questions we get asked