Email Bounce Handling: Hard Bounces, Soft Bounces, and the Patterns That Protect Sender Reputation

Most engineering teams build their transactional email pipeline once, send a few thousand messages, and assume the system works because no one is complaining. They learn the truth six months later, when a customer reports that they have not received any emails from the product in two weeks, or when a deliverability audit reveals that 30 percent of the team's emails are landing in spam folders. The proximate cause is almost always the same: the team did not handle bounces, and their sender reputation has eroded to the point where mailbox providers route their mail aggressively to spam.

This post covers the patterns that keep transactional email actually arriving — bounce categorization, suppression lists, complaint handling, and the feedback loop that mailbox providers use to score sender reputation. The patterns apply across all four of our products that send transactional email: DocuMint, CronPing, FlagBit, and WebhookVault.

Hard bounces and soft bounces

Every bounce has an SMTP status code that classifies it. The first digit determines the broad category: 4xx codes are temporary failures, 5xx codes are permanent failures. The right response differs sharply between the two.

A hard bounce — 5xx, typically 550 No such user or 553 Mailbox unavailable — means the address does not exist or has been permanently disabled. Sending another email to a hard-bounced address provides zero value (the recipient cannot receive it) and substantial cost (mailbox providers track repeated sending to dead addresses as a strong negative signal). The right response is to add the address to a permanent suppression list and never attempt to send to it again, regardless of which feature triggers the email.

A soft bounce — 4xx, typically 421 Service unavailable or 452 Insufficient system storage — means the recipient's mailbox is temporarily unable to accept mail. The right response is to retry with exponential backoff for up to 72 hours, then give up. A single soft bounce should not affect the sender's behavior toward the recipient on future sends; persistent soft bounces (more than 5 in 7 days) should be treated like hard bounces because they indicate an effectively dead address.

The categorization is rarely as clean as the SMTP codes suggest. Many bounces arrive as 5xx codes that are actually temporary (overloaded servers, anti-spam holds), and the bounce body text matters for accurate categorization. Mature email infrastructure providers (Postmark, SendGrid, Amazon SES) provide already-categorized bounce events; if you operate your own SMTP infrastructure, you need to maintain a categorization library that classifies bounces by status code, response text, and provider-specific quirks.

The suppression list as central data structure

The suppression list is the most important table in any transactional email system. Every send must check the suppression list before attempting delivery; every bounce must add to the suppression list. The suppression list is the single source of truth for "should we send to this address."

The minimum suppression list schema has the address, the suppression reason (hard_bounce, soft_bounce_threshold, complaint, manual, unsubscribe), the timestamp, and the source event ID for forensic traceability. Production systems usually add a per-stream dimension (transactional vs marketing) because suppression of marketing email should not block password resets, but suppression for hard bounce should block both because the address does not exist.

The suppression list must be append-only in normal operation. Removing an address from suppression should require explicit human action with audit logging, because the consequences of accidentally re-enabling suppressed addresses are immediate (more bounces, reputation damage). Some systems support automatic re-evaluation after 30 days, but only for soft-bounce-threshold suppressions, never for hard bounces or complaints.

Complaint handling and the FBL

A complaint is a recipient marking your message as spam in their mail client. Mailbox providers report complaints back to senders through Feedback Loops (FBLs), which are essentially webhook-style notifications saying "this user marked your email as spam." Major providers including AOL, Yahoo, Microsoft, and (with caveats) Gmail offer FBL programs.

Complaint rate is the single most heavily weighted reputation signal at most major mailbox providers. A complaint rate above 0.3 percent will trigger spam folder routing at Gmail; above 1 percent will trigger outright blocking at most providers. The math means that if you are sending 10,000 emails per day, more than 30 complaints in a day is enough to start damaging reputation.

The mandatory response to a complaint is to add the complainant's address to the suppression list immediately, and to do so for all streams, not just the one that triggered the complaint. The complaint indicates the recipient does not want any mail from your domain; sending more, even legitimately transactional mail, will produce more complaints and accelerate reputation damage.

The strategic response to complaints is to investigate why they are happening. Complaints on transactional email usually indicate one of three problems: mail going to addresses the recipient did not consent to (data quality issue), mail from a brand the recipient does not recognize (sender alignment issue), or mail content that does not match the recipient's expectation (UX issue, often "unsubscribe is hard so I'll just hit spam"). All three are fixable; ignoring them is not.

List-Unsubscribe and one-click unsubscribe

Since February 2024, Gmail and Yahoo require senders of more than 5,000 messages per day to include a one-click unsubscribe header per RFC 8058. The header is a List-Unsubscribe-Post line with a URL that handles a POST request and unsubscribes the recipient without further interaction.

The implementation is small (an HTTP endpoint that decodes a token from the URL, looks up the recipient, and adds them to the suppression list) and the cost of not implementing it is large (Gmail and Yahoo will route your mail to spam more aggressively if the header is missing). The endpoint must respond within a few seconds and must not require login, because the GMail bot calls it without a user session.

The often-overlooked detail is that the one-click endpoint is hit by the mail provider's bot to verify functionality, not just by users actually unsubscribing. The endpoint should be idempotent and should not send a confirmation email (some senders send "Are you sure you want to unsubscribe?" which defeats the one-click guarantee).

Reputation monitoring and the feedback loop

Mailbox providers expose reputation signals through Postmaster Tools (Gmail), Smart Network Data Services (Microsoft), and Sender Hub (Yahoo). Each provides a domain reputation score, IP reputation score, and breakdowns of authentication compliance, spam rate, feedback loop volume, and delivery metrics.

The recommended weekly check is: domain reputation should be high or medium-high; spam rate (complaints divided by inbox placements) should be below 0.1 percent; SPF, DKIM, and DMARC should all show 99-percent-plus compliance. Anything outside these thresholds is a leading indicator of deliverability degradation that will become a customer-visible problem within a few weeks.

The hard truth about email deliverability is that it is mostly a reputation game and reputation is mostly a function of bounce rate, complaint rate, and authentication compliance. Sending less mail to better-curated lists with proper authentication and aggressive bounce handling beats sending more mail with sloppy operations every time. Most deliverability problems are self-inflicted by skipping the unglamorous bounce-handling work.

The deeper observation

Transactional email feels like a solved problem because the SMTP protocol is forty years old and the major providers (SES, SendGrid, Postmark) handle the protocol details. The illusion holds until your sender reputation degrades enough that 30 percent of your password reset emails are landing in spam, at which point you discover that the unglamorous work of bounce categorization, suppression list maintenance, complaint handling, and reputation monitoring was the actual product. The teams that get email right treat it as a long-running operations problem rather than a one-time engineering project. Bounce handling is the floor; everything else is built on top of it.