Hard bounce vs soft bounce: should you resend the email?

A hard bounce is a permanent email delivery failure; a soft bounce is temporary. Let your sending provider handle appropriate temporary retries. Suppress confirmed nonexistent addresses. For authentication or policy rejections, investigate the full error before another attempt: a permanent failure of this message does not necessarily mean the customer’s address is invalid.

For retention marketing, the decision has two parts: what happens to the failed message, and whether the customer should remain eligible for later email. Read the reason before changing either.

What is the difference between a hard and soft bounce?

A hard bounce is a permanent delivery failure; a soft bounce is temporary. The distinction tells you how to handle the failed message. Read the full response before deciding whether the address should be suppressed from future marketing.

The underlying email protocol makes that distinction explicit. RFC 5321 describes 4xx replies as temporary failures that the sending system should retry. With 5xx replies, it should not repeat the exact request unchanged. The standard also recognizes that some permanent errors can be corrected before a new attempt.

“Permanent” therefore needs an object: permanent failure of the request as it stands. On its own, it does not tell you whether the recipient’s address is invalid.

What does the full bounce response tell you?

M3AAWG’s sender guidance says the numeric response directs the sending server, while the descriptive text helps determine what to do with the address. Keep both.

These examples come from Google’s Gmail SMTP error reference. They illustrate different decisions; your email platform’s hard/soft classification is a separate report field.

The last two rows matter when someone says “a full mailbox is always a soft bounce.” Google’s descriptions distinguish out-of-storage from out-of-storage and inactive. Use the actual response rather than diagnosing from “mailbox full” alone.

For a wider authentication or rejection incident, follow the email deliverability guide. This page focuses on the next decision for the failed send and contact.

Should you resend an email that bounced?

Not automatically. First establish whether the original send is still being retried or has reached a final outcome. Ask your provider if the report does not make that clear. A new campaign is a separate sending decision; do not use it as a substitute for checking the existing attempt.

Record these fields before scheduling another send:

• Message: campaign or flow, recipient, sending route and timestamp.
• Response: full code and text, receiving provider and reported bounce category.
• Attempt status: retry pending, delivered after retry, or final failure.
• Contact status: current suppression reason and eligibility for marketing.
• Next action: address suppression, sending fix, provider-managed retry or review of repeated failures.

For a concrete report path, Klaviyo documents sent campaign → Recipient activity → Bounced, where the report shows category, reason and type. It also documents automatic hard-bounce suppression and suppression after repeated consecutive soft bounces. Check the applicable policy rather than importing another platform’s count.

For excessive frequency or volume, its guidance is to identify the affected mailbox provider and reduce messages to that provider. That gives the sending owner a specific investigation, instead of a request to “resend everything that failed.”

Repeated temporary failures need a decision too. M3AAWG recommends removing consistently bouncing addresses, with the campaign count and period chosen by the sender. Its general best-practice guideline is removal after at least two consecutive bounces over two weeks or more. That covers failures with any code, not soft bounces alone; it is not a universal platform setting.

An example: the same failed-send total, different actions

Consider an invented report of 100 final failed recipients, after the sending service has finished its attempts:

20 + 30 + 50 = 100. The total gives a workload; the reasons determine the work. These are illustrative groups, not a benchmark or a claim about how every ESP labels final failures.

Can you restore a hard-bounced contact?

Treat restoration as a review of a specific cause. Keep a confirmed nonexistent address suppressed. If there is evidence of a corrected address or a resolved sending problem, ask the provider which restoration process applies to that suppression reason.

Answer these questions before restoring a contact:

Leave sending blocked while the relevant cause is unresolved. Record a missing answer as an open issue, rather than treating the customer’s value as evidence that delivery is fixed.

Permission and reachability also need separate checks. Klaviyo’s profile-management guidance says a purchase or started checkout does not lift suppression. It also says applying or removing a manual suppression does not change marketing consent. That manual process does not establish how a hard-bounce suppression can be removed.

An address check or previous order should therefore not replace the permission and suppression checks. If the decision is broader audience maintenance, the list-cleaning guide covers exclusions, suppression and paid validation.

Frequently asked questions

Does a hard bounce always mean the email address is invalid?

No. A permanent rejection can concern the sending setup: Google’s 550 5.7.26 descriptions include authentication failures. Read the full response. When the receiver confirms that the user does not exist, keep that address suppressed from future mailings.

Should you manually resend after a soft bounce?

Check whether the sending provider is still retrying the original message or has recorded a final failure. Let it manage appropriate temporary retries. Before a later campaign, review the reason, repeated failures and current contact eligibility rather than automatically resending.

How many soft bounces should trigger suppression?

Use your provider’s current policy and review persistent failures across campaigns. M3AAWG leaves the campaign count and period to the sender, while giving removal after at least two consecutive bounces over two weeks or more as a general best practice. That guideline covers failures with any code, not soft bounces alone, and is not a universal platform setting.