There is no provider-independent “safe bounce rate” that makes every campaign acceptable. The failure class, reason, trend, audience source, sending identity, and provider response matter more than one blended percentage.
Distinguish hard bounces, soft bounces, and rejections
| Observed outcome | Typical meaning | Default response |
|---|---|---|
| Permanent 5.x failure | The server says delivery will not succeed without a material change | Stop automatic retries; suppress the address when the failure is recipient-specific |
| Persistent transient 4.x failure | Delivery may succeed later | Honor controlled retry timing; reduce volume or pause when the pattern broadens |
| Policy or reputation rejection | The provider objects to identity, reputation, rate, content, or policy compliance | Investigate the exact code before changing audience or infrastructure |
| Accepted message | The receiving server accepted responsibility for delivery | Do not call it a bounce; inbox or spam placement is a separate outcome |
IETF enhanced status codes begin with a class: 2.x indicates success, 4.x a persistent transient failure, and 5.x a permanent failure. The remaining digits and provider text identify the subject and detail; keep them instead of flattening every event into “bounced.”
What should be suppressed
- Addresses with recipient-specific permanent failures, such as a mailbox that does not exist.
- Recipients who unsubscribe, complain, explicitly ask to stop, or are manually blocked.
- Domains or exact addresses placed on an operator-controlled block list.
- Addresses whose policy or risk status requires a hold until reviewed.
A domain-wide policy rejection is not proof that every recipient address is invalid. Preserve the contacts while pausing the affected sending path; do not convert an infrastructure problem into false address-level data.
How to treat transient failures
A soft failure may reflect a full mailbox, temporary server condition, throttling, reputation, or policy issue. Use the detailed status code and retry guidance. Repeated automatic retries can worsen a rate or reputation problem, so the retry system needs bounded timing and an eventual stop.
Google tells senders to reduce volume when messages start bouncing or being deferred. Increase slowly after SMTP errors fall. A broad rise in 4.x outcomes calls for investigation.
How to interpret a bounce rate
- Separate hard failures, transient failures, policy blocks, and provider throttling.
- Segment by audience source, verification age, provider, domain, inbox, campaign, and time.
- Compare the current pattern with that same stream's recent baseline.
- Act on small but concentrated failures instead of waiting for a blended site-wide percentage to rise.
- Audit the input source whenever new or old records fail disproportionately.
How MailSequence handles suppression
MailSequence distinguishes hard and soft bounce outcomes. Hard-bounce suppression blocks future sends to the affected address, while a recent soft bounce can temporarily make the contact ineligible for that inbox. Unsubscribes, complaints, manual suppressions, and email or domain block-list matches are also enforced at send time.
Imports and migrations use the same suppression-aware contact path. Prior stop decisions remain in force when a campaign moves.
Primary sources
- IETF RFC 3463: Enhanced Mail System Status Codes
Success, persistent transient failure, permanent failure, subject, and detail classifications. - Google: Email sender guidelines
Bounce and deferral response, gradual volume, suppression, authentication, and monitoring guidance. - Google: Fix bounced or rejected emails
Provider-specific instruction to preserve and inspect bounceback error details. - Microsoft: Outbound spam protection
Outbound restrictions, non-delivery reports, authentication, and list-hygiene practices.