Treat a soft bounce as a temporary delivery state with an exit rule. Retry while the failure still looks temporary, then stop when further attempts become wasteful. Check the failure class first: temporary 4xx responses are retry candidates, while permanent 5xx responses can be misclassified as soft bounces.1, 2 Five consecutive soft-bounce attempts trigger suppression in a documented policy, which provides a practical default ceiling.3
How to run the policy
Run every failure through the same decision order, and keep the result attached to the address. A result for one recipient must not change another recipient's state.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Classify | whether the failure is temporary | Is this response temporary or permanent? |
| Diagnose | what caused the temporary rejection | What does the delivery response say happened? |
| Retry | whether another attempt still makes sense | Has this address succeeded since the last failure? |
| Suppress | whether repeated failure has reached the exit rule | Has this address reached the retry ceiling without a successful delivery? |
Classify the failure
Start with the server response and its reason. The label in a sending system is only a starting point, so use the response details before setting the policy.
The receiving server's automated Non-Delivery Report contains more detail about the delivery problem.4 Read it before counting the event as a retryable soft bounce. Common temporary causes include a full inbox, an overloaded or offline receiving server, rate limiting against the sending IP, and throttling by the receiving domain.5
In most cases, a soft bounce means the address is valid, the message reached the recipient's mail server, and that server rejected it for the moment.6 If the response shows a permanent failure, remove the address from the soft-bounce path and handle it under the permanent-failure rule.
Retry with a ceiling
Once the response is genuinely temporary, put the address into a controlled retry sequence. This gives the condition time to clear while limiting repeated delivery attempts.
Soft bounces and deferrals are treated as transient failures and retried.7 Space the attempts with increasing delays and use exponential backoff so the receiving server has more time to recover.8 Some delivery systems retry for a day or two, and the message often gets through on a later attempt.9
Track consecutive failed attempts per address. A campaign-level result cannot clear an address-level failure state, because a message can bounce for some contacts and deliver for others.10 A successful delivery ends the consecutive sequence. If the sequence reaches the ceiling without success, move the address out of active sending.
Handle a full mailbox separately
A full mailbox needs a cause-specific pause. Use the response to decide between an ordinary retry sequence and a longer suppression period.
For a full mailbox, no action is required after the first soft bounce. When deliverability problems are serious or long-term, suppress the contact for 14 days after the first soft bounce.11 Then review whether the address should re-enter sending under the normal rules.
Review repeated patterns
The retry count tells you when to stop for an address. The pattern around it tells you what to investigate before allowing future delivery attempts.
An isolated soft bounce is usually no cause for concern.12 Repeated soft bounces from the same address across multiple campaigns may indicate an abandoned mailbox, a mailbox that is permanently over quota, or a receiving server that is blocking the sender.13 Review this pattern separately from a temporary outage affecting many addresses, because the remedy belongs at a different level.
What not to do
- Do not keep sending to an address that continuously soft bounces, because repeated soft bounces can harm sending reputation.14
- Do not treat every repeated soft bounce as random noise. Across multiple campaigns, the pattern may point to an abandoned mailbox, permanent over-quota status, or sender blocking.13
- Do not run a retry sequence at a fixed pace when exponential backoff is available.8