Hard bounce vs soft bounce: what to do with each
Hard and soft bounce are operational labels for permanent-looking and temporary-looking delivery failures. The label is useful, but the original response and your sending provider’s classification matter more than the colour of the badge.
Open the relevant free tool →Different failures need different actions
Use the delivery report as the source of truth
Record the reply code, extended status code and diagnostic text. A provider may group several causes under one bounce label. An invalid recipient and a sender-policy rejection should not automatically trigger the same contact-list action. Read the reason before deciding whether to retry, correct an address or fix authentication.
Handling a permanent recipient failure
When the evidence clearly identifies a nonexistent or disabled mailbox, suppress that destination from normal sending. Preserve the suppression record so a later CSV import does not reintroduce it. If the contact is a customer, ask them to update the address through your established account channel. Avoid guessing a different username and resending sensitive information to it.
Handling a temporary failure
For a temporary deferral, let your delivery provider apply its bounded retry policy. Do not create a second campaign or repeatedly submit the same message while the first is still queued. Track how long the issue persists and whether it affects one recipient, one domain or many destinations. A repeated temporary problem may eventually require manual review, but the first deferral does not establish an invalid address.
A useful list model
Store delivery outcome separately from verification status. For example, a contact can have usable MX records and a recent temporary delivery failure. Neither field should erase the other. Include last_success_at, last_failure_at, failure_reason and suppression_reason in your own data model when those fields are useful to the workflow. This is more actionable than a single permanent “bad email” column.
Example: two failures, two actions
An old contact with a recipient-not-found report should be suppressed and reviewed. A recent customer whose message was temporarily deferred during a destination outage should remain in the retry workflow. Running both through the same cleanup rule would either keep sending to the invalid destination or remove a legitimate customer. The distinction matters most when your list is imported or synchronized across systems.
Put it into practice
- Base actions on the detailed reason.
- Let one system own message retries.
- Keep suppression history across imports.
- Do not overwrite delivery history with a verification score.