Recover · Bounce Handling
Email Bounce Handling Guide
Bounces are a fact of life in transactional email. How you classify, suppress, and recover from them determines whether your sending reputation survives high-volume operations.
Representative product UI — illustrative data, not live customer metrics.
Control plane
How Sendarix classifies, suppresses, and routes on bounce signals
Bounce events feed routing decisions and tenant-level suppression — not just a static blocklist. Hard bounces are suppressed immediately; soft bounces follow your retry policy before escalation.
Per-tenant isolation keeps one customer's bad list from affecting others. Webhook events (bounce, soft_bounce, complaint) give your application the detail needed to update CRM records and trigger recovery flows. See email routing for policy configuration.
| Provider | Signal | Status |
|---|---|---|
| Amazon SES | Stable delivery | healthy |
| Postmark | Low deferrals | healthy |
| Mailgun | Elevated deferrals | degraded |
Representative product UI — illustrative data, not live customer metrics.
Hard bounce vs soft bounce — classification
Not all bounces are equal. The response code from the receiving server tells you whether the failure is permanent or temporary — and your system must handle each case differently.
Hard bounce
Permanent delivery failure. The mailbox does not exist, the domain is invalid, or the recipient has permanently rejected mail from your domain.
Response codes:550 Mailbox unavailable, 550 User unknown, 550 No such recipient
Required action: Immediately add to global suppression list. Never attempt to send to this address again.
Soft bounce
Temporary delivery failure. The mailbox is full, the server is temporarily unavailable, or there is a connection issue.
Response codes:450 Mailbox full, 421 Service temporarily unavailable, 451 Server busy
Required action: Retry with exponential backoff. Convert to hard bounce after N consecutive failures.
Retry and backoff strategy
Soft bounces must be retried, but not immediately and not indefinitely. A structured retry schedule prevents your system from hammering servers that are already degraded.
| Timing | Action |
|---|---|
| Immediate | First attempt at time of send |
| +15 min | First retry — server or network error |
| +1 hour | Second retry |
| +4 hours | Third retry |
| +12 hours | Fourth retry |
| Drop | After 5 consecutive failures — convert to hard bounce and suppress |
Suppression list management
The suppression list is your primary defense against sending to addresses that cannot receive mail.
Hard bounces
Permanent. Never attempt redelivery. Stored permanently with timestamp.
Complaints (FBL)
User marked as spam. Long-term suppression. Store with complaint date.
Unsubscribe requests
Must be suppressed immediately per CAN-SPAM and GDPR requirements.
Transient failures
Do NOT suppress during retry window. Only suppress after max retries exceeded.
For multi-tenant SaaS platforms, suppression lists must be isolated per tenant. See tenant isolation for per-domain suppression boundaries.
Webhook event tracking for bounces
Bounce events delivered via email webhooks provide the most detail. Track these event types:
bounce— hard bounce. Immediately suppress recipient.soft_bounce— temporary failure. Schedule retry per your backoff policy.complaint— recipient marked as spam. Long-term suppress.delivery— confirms acceptance by the receiving server.reject— server refused before queueing. Check SPF/DKIM/DMARC records.
Sendarix handles bounce classification automatically
Bounce events are tracked per message, classified as hard or soft, and suppression lists are updated automatically. Retry schedules and failover logic are configurable through the email routing API.
