Common causes of a soft bounce
A full mailbox, a temporarily unavailable or overloaded receiving server, a message exceeding the recipient server’s size limit, or greylisting (where a server deliberately issues a temporary rejection on first contact) all produce soft bounces. These map to SMTP 4xx response codes in RFC 5321 — a signal that the issue is expected to resolve, not permanent.
Why soft bounces shouldn’t be ignored either
A single soft bounce is unremarkable. But an address that soft-bounces on every single campaign over weeks or months isn’t experiencing a transient issue — it’s effectively undeliverable in practice, even though no individual attempt returned a permanent 5xx failure. Most ESPs apply a consecutive-failure threshold to convert chronic soft bounces into suppressions.
Soft bounce vs. greylisting at verification time
Greylisting specifically produces a soft-bounce-like response (450/451) on the first connection attempt from an unrecognized sender, then accepts the retry. A verification tool that doesn’t retry after a greylist response will misreport a perfectly valid address as “unknown” — this is one of the more common sources of false-negative results in basic verification implementations that only attempt a single SMTP connection.
What to do about soft bounces operationally
Most ESPs handle retry logic automatically for a single campaign send. The actionable step on your end is monitoring the pattern: an address with three or more consecutive soft bounces across separate campaigns is a strong candidate for suppression or re-verification, since continuing to mail it has low expected value and nonzero reputation cost.
Look up a specific bounce code
See the full SMTP bounce code reference for what specific temporary codes like 450 4.2.0 (mailbox full) or 451 4.3.0 (often greylisting) mean and whether to retry.