All packsTransactional Email Deliverability CoreSolve
email soft bounce vs hard bounce suppress or retry
A temporary delivery delay is not a reason to suppress forever
Suppressing an address on any bounce, without distinguishing permanent from transient, blocks all future mail to addresses that were only ever slow to accept it.
What goes wrong
Bounces come in two fundamentally different flavors: permanent (the address doesn't exist, will never accept mail) and transient (a full inbox, a temporarily unavailable server -- the provider will keep retrying on its own). Treating every bounce webhook as a reason to add the address to a permanent suppression list means a recipient who was only ever briefly unreachable stops receiving any mail from the app forever, based on a single transient hiccup.
Why agents get it wrong
"A bounce means the email didn't get delivered" is true of both kinds, and the webhook payload's bounce type field (Permanent vs Transient vs Undetermined) is one more thing to check inside an already-complex event handler -- treating all bounces the same way is the shorter code path, and it doesn't produce an obviously wrong result until a specific address that should have kept receiving mail stops getting it.
What Transactional Email Deliverability Core pre-decides
Suppression decision 5 states the rule explicitly: soft bounces (delivery_delayed, bounce type Transient) are logged, never suppressed -- the provider's own retry logic handles them. Only email.bounced events with data.bounce.type === 'Permanent' trigger suppress(hard_bounce); everything transient or undetermined is recorded for visibility without touching the suppression list.
Source: ARCHITECTURE.md 'Suppression semantics', decision 5