9 Bounce and Suppression Best Practices That Protect Your Reputation

A bounce is the receiver telling you an address is bad. Ignore it and keep sending, and you tell every mailbox provider you do not clean your list. Here is how to handle bounces so they protect your reputation instead of wrecking it.

Bounces are not the problem. Ignoring them is. One dead address costs nothing; a thousand uncaught bounces with automatic retries on top tells Gmail and Yahoo you are mailing a list you do not maintain, and that is how reputations slide into the spam folder. These nine practices keep bounce data working for you, and they matter more on a self-hosted Cloudflare stack where nobody manages the suppression list but you.

1. Split hard bounces from soft bounces

The first decision on every bounce is permanent versus temporary, and it changes everything you do next. A hard bounce means the address is dead: unknown mailbox, invalid domain, or a flat block. A soft bounce means try again later: full mailbox, message too large, greylisting, or a server that is briefly down. Suppress hard bounces on sight and retry soft bounces within limits. Get this split wrong and you either keep mailing dead addresses or you give up on recipients who were only temporarily unreachable. The full breakdown of each bounce class and what to do with it is in how to handle email bounces.

2. Read the SMTP code, not just the bounce message

The classification lives in the response code, and human-readable text lies. A 5xx code is a permanent failure (suppress); a 4xx is temporary (retry). Within 5xx, a 550 unknown-user is a clean hard bounce, while a 5xx that mentions "spam" or "policy" is a reputation signal you need to act on separately. Do not pattern-match on the English in the bounce body, because every provider phrases it differently. Parse the enhanced status code (the 5.1.1-style number) and branch on that.

3. Suppress every hard bounce, permanently

One hard bounce means the address goes on the suppression list and stays there. There is no reason to ever send to a confirmed-dead mailbox again, and every attempt chips at your sender score. Keep a single suppression table that lives in your own database, and add hard bounces to it the moment they land. The suppression list is append-mostly: addresses go on automatically and only come off when a human has a verified reason. On a Cloudflare stack this is a row in D1 that every send path consults, no external vendor holding your blocklist hostage.

4. Check the suppression list before every send

A suppression list nobody checks is just a log file. The whole point is the pre-send gate: before any message leaves, the address gets looked up against suppressions and dropped if it matches. This has to cover transactional and marketing alike, and it has to be the same list, because an address that hard-bounced your newsletter is just as dead for your receipts. Make the lookup a required step in the send pipeline, not an optional one a caller might forget. Wire it once at the choke point and every future send inherits the protection.

5. Cap your soft-bounce retries

Soft bounces deserve patience, not infinite persistence. A full mailbox might empty out and a greylisted message usually gets through on the second try, so retries are correct here. But a retry budget without a ceiling becomes the same reputation problem as mailing hard bounces: endless attempts at an address that is never coming back. Cap it at a handful of attempts over a day or two, back off between tries, and if it still fails, promote the address to a hard suppression. The cadence matters because aggressive immediate retries look like a misconfigured loop to the receiver.

6. Process bounces through a webhook or queue, not inline

Bounce handling that blocks the send path will fall over at the worst moment. Bounces arrive asynchronously and in bursts, especially after a campaign, so capture them as events and process them off the hot path. On Cloudflare that means an inbound handler that drops each bounce onto a queue, and a consumer that classifies it and updates suppressions without holding up anything else. This also gives you a retryable, observable pipeline instead of a fire-and-forget side effect. The architecture, from receiving the bounce to updating the list, is in processing bounce webhooks.

7. Treat spam complaints like hard bounces

A complaint is worse than a bounce: the address works and the person reported you anyway. Feedback-loop signals and abuse-style complaints should trigger an instant, permanent suppression, no retry, no second chance. Gmail and Yahoo expect bulk senders to stay under a 0.3% complaint rate, and the fastest way to blow past it is to keep mailing someone who already hit "report spam." Fold complaint processing into the same suppression pipeline as bounces so both feed one list. How to capture and act on these signals is covered in detecting spam complaints and feedback loops.

8. Verify addresses before you send, not after they bounce

The cheapest bounce is the one that never happens. Syntax validation, MX-record checks, and catching obvious typos at signup time stop a large share of hard bounces before a single message goes out. This matters most on imported lists and public signup forms, where a chunk of addresses are fat-fingered or fake on arrival. A bounce after sending costs reputation; a rejection at the form costs nothing. The validation layers worth running are in verifying email addresses before sending.

9. Prune spam traps and stale addresses on a schedule

Some bad addresses never bounce, and those are the dangerous ones. Recycled spam traps were once real mailboxes that now silently accept mail and report you to blocklists, so they will not show up in your bounce data at all. The defense is list hygiene: sunset contacts who have not engaged in months, never mail purchased lists, and re-confirm anyone who has gone quiet for a long stretch. A clean list bounces less and traps less, which keeps your whole reputation steady. The hygiene playbook, including how traps get onto a list, is in spam-trap and list-hygiene practices.

Ship it

The thread across all nine: a bounce is free intelligence about your list, and the only wrong move is to ignore it and keep sending. Classify it, suppress what is dead, retry what is temporary within limits, and gate every future send on the result. Bounce handling is one lever in a larger reputation game, so pair it with the broader sender-reputation habits, the alert thresholds in the deliverability metrics worth watching, and the proactive list-hygiene habits that keep bounces from happening at all. Managed providers like Postmark and SendGrid do a lot of this for you, and that automation is genuinely convenient when you are moving fast. The trade is that your suppression list, your bounce history, and your complaint data all live in their account, and you inherit whatever retry policy they chose.

Tinbox runs the whole loop on your own Cloudflare account: bounces arrive through an inbound handler, get classified and queued, and feed one suppression list in your D1 that every transactional and marketing send checks before it goes out. You can read the bounce log, tune the retry budget, and export the list, because it is yours.

Deploy your own email stack: npx tinbox init <domain>. The library and source are on GitHub if you would rather assemble the bounce pipeline yourself.