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.
This is one of the things Transactional Email Deliverability Core already handles. Send transactional email that actually lands, and stop emailing people who bounce or complain.
Is this you?
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 this one is easy to get 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 you get instead
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 — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 13 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
3 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →