Soft bounce
Your provider's label for a failure it expects to clear: full mailbox, server hiccup, or you sending too fast. Back off, do not give up.
See it
What it is
'Soft bounce' is a label your ESP applies, not something SMTP knows about. The protocol has 4xx (temporary, come back later) and 5xx (permanent for this transaction); your provider maps those replies, plus its own queue state, onto words like 'deferred' and 'soft bounce'. The usual causes really are temporary: mailbox full, receiving server down or busy, throttling because you are sending too fast. Size limits are the one people miscategorize, since an oversized message is normally refused permanently ('552 5.3.4 message size exceeds fixed limit'), not deferred. Classify on the enhanced status code and the provider's own event type rather than on the word. Where the failure is genuinely temporary, most providers retry for you with backoff for something like 24 to 72 hours before converting it into a permanent failure.
Retry behavior is itself a signal. Spam software fires once and moves on, so greylisting exists specifically to reject the first attempt and see who comes back politely. Retry with exponential backoff plus jitter, respect per-provider concurrency limits, and never loop immediately, because retrying a deferral in a tight loop is how a temporary slowdown becomes a block.
Two traps. First, a soft bounce that repeats every day for a week is effectively hard: an abandoned mailbox stays full forever, so suppress after a handful of consecutive failures rather than mailing it quarterly for years. Second, read the text. Gmail's '4.7.0 unusual rate of unsolicited mail' is not a mailbox problem, it is Gmail telling you your reputation is sliding, and slowing down is the actual fix.
Ask AI for it
Add soft bounce handling to our email pipeline. First establish who owns the retry: if we send through a managed ESP that retries deferred mail internally, record its intermediate deferral events for visibility and never resend those messages ourselves, acting only on the provider's final failure event. Build the retry queue (exponential backoff plus jitter at roughly 5 minutes, 15, 1 hour, 4 hours, capped at a 72 hour delivery window) only for mail our own SMTP transport still owns, and cap in-flight connections per receiving domain so retries never dogpile a provider that is already throttling us. Classify on the enhanced status code and the provider event type, not on the word 'soft': log 4.7.x reputation deferrals separately from 4.2.2 mailbox-full events, and route permanent size rejections like 5.3.4 out of the retry path entirely. Track consecutive temporary failures per address and suppress after 5 in a row or 14 days of continuous failure. Alert when reputation deferrals exceed 1 percent of a send.