What is a soft bounce? Difference from Hard bounce

What is a soft bounce? Temporary failure, retry policy, and the point where temporary becomes chronic

The subtle part is that a soft bounce is not a promise that delivery will eventually succeed. Repeated temporary failures can exhaust the sender's retry window and become a final delivery failure, and platforms can apply their own chronic-soft-bounce suppression rules.

The protocol model: temporary now, not guaranteed later

RFC 5321 describes 4yz replies as transient negative completion responses. The SMTP client should generally try again. RFC 3463 describes 4.X.X as persistent transient failure: the message is valid, but a temporary condition has caused delay or abandonment, and future delivery may succeed. Typical temporary conditions include:

• mailbox temporarily full
• receiving server unavailable
• throttling or rate limiting
• temporary DNS or routing issues
• provider-side resource pressure
• a temporary reputation or policy deferment

The ESP label may appear after retries, not at the first 4xx

This is where dashboard terminology can confuse operators. Amazon SES distinguishes DeliveryDelay from its final Bounce event. A DeliveryDelay means SES could not deliver because of a temporary issue. SES says soft bounces appear in bounce reporting only when SES is no longer retrying for a period of time. So an application can see:

1. a temporary deferment
2. provider retries
3. eventual successful delivery

or:

1. a temporary deferment
2. repeated retries
3. retry window exhausted
4. final failure event classified by the provider

That is why "soft bounce" needs provider context. The same underlying temporary condition can be represented at different stages in different ESP dashboards.

Soft bounce is not the same as "mailbox full"

Mailbox full is a familiar example, but it is only one possible cause. Temporary failures can be sender-side signals too. For example, a mailbox provider may temporarily throttle an IP because volume increased too quickly. If many recipients at the same provider begin soft-bouncing at the same time, it is unlikely that all of their mailboxes became full simultaneously. The pattern points toward provider, reputation, or rate behavior. The diagnosis should therefore consider:

• enhanced status code
• provider domain
• sending IP
• campaign/stream
• time window
• retry history
• whether the issue affects one recipient or thousands

Chronic soft bounces need a policy

A single temporary failure is not a reason to permanently suppress a recipient. Repeated temporary failures can become a list-health problem, however, because the system keeps spending delivery attempts on an endpoint that is not recovering.

Platforms solve this differently. A sender may suppress an address after a provider-defined retry window, a repeated-failure threshold, or an internal risk decision. Any count or time window is an implementation rule, not an SMTP standard or universal threshold. Your platform should expose its own rule clearly rather than teaching "7 soft bounces" as an industry law.

One isolated temporary failure

Let the delivery provider retry according to its queue policy. Do not create custom rapid retries from your application that fight the ESP's backoff logic.

Many recipients at one provider fail at once

Treat it as a provider-level incident until proven otherwise. Check sending rate, IP/domain reputation, authentication, and the provider's SMTP diagnostics.

The same address repeatedly fails over a long period

Escalate from temporary retry to chronic suppression according to your ESP or internal policy. Preserve the reason so support can distinguish chronic temporary failure from an unsubscribe or complaint.

The address succeeds after a temporary failure

Clear the delivery incident according to provider behavior, but keep the event history. Repeated episodes can still indicate a deteriorating endpoint or sending problem.

Soft bounce versus hard bounce

A useful shorthand is:

• soft bounce: retry may work without changing the message or recipient
• hard bounce: the exact request should not simply be repeated because the failure is considered permanent

But the enhanced status code and text remain the source of truth for diagnosis. An ESP's normalized category is a convenience layer.

Worked example

Campaign A sends to 50,000 recipients.

• One recipient gets 452 4.2.2 mailbox full
• 8,000 recipients at the same mailbox provider get temporary rate-limit responses starting within the same minute

• Both are temporary failures, but they demand different actions

• For the single full mailbox, normal retry behavior is appropriate

For the 8,000-provider cluster, continuing at the same rate can worsen the problem. The operator should slow or pause the affected traffic, inspect provider-specific guidance and reputation evidence, and allow controlled retry rather than treating 8,000 addresses as independently unhealthy. That is the information a top-line "soft bounce count" hides.

Common mistakes

1. Suppressing every address after one soft bounce
2. Retrying immediately from your application while the ESP is already retrying
3. Treating every soft bounce as mailbox-full
4. Ignoring provider-wide clusters of temporary failures
5. Teaching one ESP's chronic-bounce threshold as universal
6. Losing the original SMTP response when normalizing events
7. Counting final soft-bounce events without understanding the provider's retry window

Soft bounce checklist

• For each temporary delivery problem, retain:
• recipient
• timestamp
• SMTP reply and enhanced status code
• provider / destination domain
• sending IP or pool where available
• send stream
• retry state
• normalized soft-bounce category
• final outcome
• chronic-suppression reason if the platform eventually suppresses
• That lets you answer whether an address recovered, whether one provider throttled you, and whether the same endpoint has been failing for months

Questions we get asked