Managing Email Bounces: Hard vs Soft Bounce Handling Protocols
An email bounces, and your ESP shows you a number. 2.3% bounce rate this campaign. Is that bad? Maybe. It depends on what type of bounces they are, which domains are generating them, and whether the pattern is getting better or worse.
Not all bounces are equal. A hard bounce and a soft bounce have completely different implications and require completely different responses. This guide covers the exact protocols for handling each type.
Hard Bounces: The Permanent Failures
A hard bounce means the email permanently cannot be delivered. The most common causes are: the mailbox does not exist (the person left the company or never had that address), the domain does not exist (typo in the domain or the domain expired), or the receiving server permanently rejected the email.
SMTP codes for hard bounces typically start with 5xx: 550 means the mailbox is unavailable, 551 means the user is not local, 553 means the mailbox name is not allowed.
Protocol for hard bounces: Suppress immediately. Do not retry. Do not wait. Do not try again next campaign. A hard bounce is permanent. Every additional attempt to send to a hard-bounced address damages your sender reputation without any possibility of delivery.
Add the address to your suppression list. This prevents it from being accidentally re-added through a future import or sync. Your suppression list should be centralized and respected by all your sending systems.
If you see a spike in hard bounces (say, going from 0.5% to 3% in a single campaign), pause and investigate before continuing. Common causes of sudden hard bounce spikes include importing an unverified list, a data enrichment source providing outdated data, or a batch of addresses that decayed since your last verification.
Soft Bounces: The Temporary Failures
A soft bounce means the email could not be delivered right now but might succeed later. Common causes include: mailbox full, server temporarily unavailable, message too large, rate limiting by the receiving server, or graylisting (the server intentionally rejects the first delivery attempt to filter spam).
SMTP codes for soft bounces typically start with 4xx: 421 means the service is not available (try again later), 450 means the mailbox is temporarily unavailable, 452 means insufficient system storage.
Protocol for soft bounces: Retry, but with limits. Most ESPs handle retry logic automatically, but you should understand and configure the rules.
First retry: 1-4 hours after the initial attempt. Second retry: 12-24 hours later. Third retry: 24-48 hours later. If the email still soft bounces after 2-3 retries over 48-72 hours, convert it to a hard bounce and suppress the address.
Some soft bounces are effectively permanent even though they use temporary error codes. A "mailbox full" error on a corporate email address usually means the person left the company and their mailbox is no longer maintained. If the same address soft bounces on consecutive campaigns, treat it as a hard bounce.
Bounce Rate Thresholds
Industry benchmarks for acceptable bounce rates: below 1% is ideal, below 2% is acceptable, above 2% requires investigation, and above 5% is an emergency that demands immediate action.
Gmail requires spam complaints to stay below 0.3% (and below 0.1% for senders of 5,000+ daily emails). While this is a complaint threshold rather than a bounce threshold, high bounce rates correlate with high complaint rates because they both signal poor list quality.
Track your bounce rate per campaign, per segment, and over time. A single campaign with a 3% bounce rate is concerning but manageable. A sustained trend of increasing bounce rates across multiple campaigns indicates systemic list quality decay that needs immediate attention.
Domain-Level Bounce Analysis
When your bounce rate spikes, do not just look at the total number. Break it down by domain to understand what is happening.
If a specific domain accounts for most of your bounces, investigate that domain. Did the company shut down? Did they change their email provider? Did they implement new spam filtering? Sometimes a single corporate domain migration (moving from on-premise Exchange to Google Workspace, for example) can invalidate hundreds of addresses at once.
If bounces are spread evenly across many domains, the problem is more likely general list decay. Your database needs re-verification.
If bounces concentrate on a specific list segment (like contacts from a recent import), the import source is the problem. Quarantine that segment, re-verify it, and reconsider using that data source in the future.
Bounce Handling in Active Campaigns
When you are in the middle of a multi-step email sequence or drip campaign, bounces require real-time decisions.
Hard bounce on step 1: Remove the contact from the sequence immediately. Do not send steps 2, 3, or 4 to an address that already hard bounced. Soft bounce on step 1: Retry per your protocol. If it resolves, continue the sequence. If it converts to hard bounce, remove from sequence.
Monitor your campaign bounce rate in real time if possible. If bounces exceed 3% within the first hour of a send, pause the campaign. Something may be wrong with the list segment, and continuing to send will compound the reputation damage.
Prevention Through Verification
The best bounce handling protocol is preventing bounces in the first place. Verification before sending catches invalid addresses before they generate bounces.
Standard verification catches most hard bounce candidates by identifying invalid mailboxes and non-existent domains. But catch-all domains present a gap. The server accepts everything, so verification shows "valid," but the individual address might not have a real mailbox behind it. When you send, the email is accepted by the catch-all server but may silently fail to reach anyone.
CatchallVerifier addresses this gap by resolving catch-all addresses into deliverable and undeliverable. This prevents the silent failures and unexpected bounces that catch-all domains can generate.
Verify your list before every campaign, or at minimum every time you import new contacts or when your last verification is more than 3 months old. Email data decays at 2-3% per month. A list verified in January could have 6-9% invalid addresses by April.
Building a Bounce Management System
Put together a system that handles bounces consistently across all your sending tools:
Centralized suppression list shared across all sending platforms. Automatic hard bounce suppression with no manual intervention required. Soft bounce retry logic with automatic conversion to hard bounce after threshold. Per-campaign bounce monitoring with alerting at 2% threshold. Monthly bounce trend reporting. Quarterly list re-verification schedule.
Most ESPs handle some of this automatically, but the cross-platform suppression and trend reporting usually require additional tooling or manual processes. The investment is worth it. A well-maintained bounce management system prevents the slow reputation decay that catches companies off guard when their inbox placement suddenly drops.




