Bounce Handling Best Practices for Every ESP

The Bounce Handling Framework

Every bounce requires a decision: retry, suppress, or investigate. Getting this wrong in either direction hurts you — removing valid addresses loses subscribers, keeping invalid ones damages sender reputation.

Bounce Type	First Occurrence	Repeated	Action
Hard (5xx permanent)	Suppress immediately	N/A — never retry	Remove from list
Soft (4xx temporary)	Auto-retry (ESP handles)	3+ campaigns	Convert to hard, suppress
Block (reputation)	Investigate cause	Ongoing	Fix reputation, check blacklists, don't remove address
Undetermined	Treat as soft	Monitor	Investigate if pattern emerges

ESP-Specific Configuration

SendGrid

Automatic handling: SendGrid automatically suppresses hard bounces and retries soft bounces up to 72 hours.

Suppression list: Check Settings → Suppression → Bounces. Hard-bounced addresses appear here and won't receive future mail.

Webhooks: Enable Event Webhook at Settings → Mail Settings → Event Webhook. Subscribe to bounce, blocked, and deferred events.

Key gotcha: SendGrid's "blocked" events are different from "bounced" — blocked means the address was on the suppression list already. Both matter for keeping your database clean.

Mailgun

Automatic handling: Mailgun stops sending to hard-bounced addresses automatically. Soft bounces get retried for 8 hours.

Suppression list: Available via API at /v3/{domain}/bounces or in the dashboard under Sending → Suppressions.

Webhooks: Configure at Sending → Webhooks. Subscribe to permanent_fail and temporary_fail events.

Key gotcha: Mailgun's retry window (8 hours) is shorter than most ESPs. Some legitimate soft bounces (full mailbox on a weekend) might not resolve in time.

Amazon SES

Automatic handling: SES tracks bounces and complaints. When your bounce rate exceeds 5%, SES puts your account on probation. At 10%, you're suspended.

SNS notifications: Set up an SNS topic for bounce notifications. This is critical — SES doesn't have a web dashboard for bounce management like other ESPs.

Suppression list: SES has an account-level suppression list (opt-in). Enable it at SES → Configuration → Suppression list. Without this, SES won't suppress bounces automatically — your application must handle it.

Key gotcha: SES requires you to manage bounce handling yourself unless you enable the account suppression list. Many developers skip this and end up with reputation problems.

Practitioner note: SES bounce handling is the #1 thing I see misconfigured in custom email systems. Developers set up SES to send but never configure SNS bounce notifications. They keep sending to dead addresses until SES suspends them. Always set up SNS first, before you send a single production email.

Postmark

Automatic handling: Postmark is aggressive about bounce handling. Hard bounces are suppressed immediately and permanently.

Bounce management: Dashboard → Activity → Bounces. Postmark categorizes bounces with clear types and descriptions.

Webhooks: Settings → Webhooks → Bounce. Postmark's bounce webhook payload includes detailed bounce classification.

Key gotcha: Postmark's strict bounce policies mean they may classify some soft bounces as hard faster than other ESPs. Monitor your suppression list if you're seeing legitimate addresses suppressed.

Mailchimp

Automatic handling: Mailchimp handles bounce processing entirely — hard bounces are cleaned automatically, soft bounces are retried across campaigns.

Cleaned contacts: Bounced addresses appear as "Cleaned" contacts in your audience. These contacts count toward your subscriber limit but can't be mailed.

Export: You can export cleaned contacts to keep your external databases in sync.

Key gotcha: Mailchimp's "cleaned" status is permanent within Mailchimp. To re-add a cleaned address, you need to manually remove it from the cleaned list — and Mailchimp may resist if the bounce was recent.

Practitioner note: The ESP that causes the most confusion is Mailchimp, because "cleaned" contacts still count toward your billing limit. Clients pay for contacts they can't mail. Export and audit your cleaned list quarterly — if it's growing fast, you have a list acquisition problem.

Building a Webhook Processing Pipeline

For any ESP, the pattern is the same:

1. ESP sends bounce event to your webhook endpoint
2. Your server classifies the bounce — hard, soft, or block
3. Hard bounces: Mark the contact as invalid in your database/CRM
4. Soft bounces: Increment a counter; if threshold exceeded, treat as hard
5. Block bounces: Alert your deliverability team; don't modify the contact
6. Log everything — bounce data is critical for diagnosing reputation issues

Webhook payload → Classification → Database update → Alert (if needed)

Cross-ESP Suppression

If you send through multiple ESPs (common in agency setups), a bounce on one ESP won't automatically suppress on another. You need a centralized suppression list:

• Maintain a master suppression database in your application
• Feed bounce events from all ESPs into this central list
• Check against this list before every send, regardless of ESP
• Include hard bounces, unsubscribes, and complaints

Practitioner note: Multi-ESP suppression is the gap nobody thinks about until they get blacklisted. A client was sending through both SendGrid (marketing) and SES (transactional). An address hard-bounced on SendGrid but SES kept sending transactional mail to it. A centralized suppression list would have caught this immediately.

If you need help configuring bounce handling across your email infrastructure, schedule a consulting session — I'll audit your bounce processing and fix the gaps.

Sources

• SendGrid: Bounce Documentation
• Mailgun: Suppressions
• Amazon SES: Monitoring Sender Reputation
• Postmark: Bounce Processing
• RFC 3463: Enhanced SMTP Status Codes

---

v1.0 · April 2026