Where you saw it: The same addresses in your soft bounce report campaign after campaign, or a retry queue that never empties.
Why it happens
- A full mailbox that nobody is emptying, which returns 552 indefinitely and is functionally dead.
- Greylisting that your platform is not retrying correctly, so every attempt is treated as a first attempt.
- A receiving server rate-limiting you specifically, which returns 4xx to your IP while accepting other senders.
- A domain with persistent infrastructure problems, where temporary failures are the normal state.
- A filtering appliance returning a temporary failure instead of a rejection, deliberately, to slow down bulk senders.
The fix, in order
Separate the pattern from the noise
Pull addresses that have soft bounced on three or more consecutive sends. A single soft bounce is meaningless. The repeat is the signal.
Group them by domain
If they concentrate on one domain, you have a rate-limiting or reputation problem with that receiver, not an address problem. That changes the fix completely.
Read the actual response text
552 is a full mailbox, 421 is a rate limit, 450 is often greylisting. Your platform collapses these into soft bounce and throws away the diagnosis.
Set a suppression rule and enforce it
Most platforms will suppress after a configurable number of consecutive soft bounces. Five is a reasonable ceiling. Without a rule, the retries continue indefinitely.
Fix the domain-level problems separately
If one receiver is rate-limiting you, reduce send rate to that domain and work on reputation with them. Suppressing their addresses treats the symptom.
How to know it worked
The short version
- The repeat-offender list shrinks after a few sends rather than growing.
- Your retry queue empties between campaigns.
- Soft bounces are spread across domains rather than concentrated on one.
Questions people ask
How many soft bounces before I should suppress?
Three to five consecutive failures across separate sends is a reasonable rule. The key word is consecutive, and one soft bounce is not a signal.
Can verification prevent soft bounce loops?
Partly. A mailbox that is permanently full often shows as a problem during verification. Rate limiting and greylisting are properties of the receiving server and cannot be predicted from a probe.
Is a soft bounce loop harming my reputation?
Repeated delivery attempts to a server that keeps deferring you are read as unwanted persistence. It is not as damaging as hard bounces, and it is not free either.