Email bounce management: building the process behind every bounce

Every sending platform labels bounces. Far fewer senders manage them, and the difference shows up months later: a suppression list that didn't survive a platform migration, a policy block that sat in the soft-bounce column for three weeks, a batch of valid B2B contacts deleted because one receiving domain misbehaved for an afternoon. M3AAWG's Sender Best Common Practices are blunt about it: for any organization sending large volumes of mail, a process for handling non-delivery reports is a must.

This guide is that process, stage by stage. It sits above the individual decisions covered elsewhere: what each bounce family means (why do emails bounce), how to read a returned message (email bounce back), what to do with a single hard bounce or soft bounce (hard bounce vs soft bounce), and what the aggregate number should look like (email bounce rate). The question here is how those decisions get made reliably, at volume, without anyone reading every bounce.

Stage one: capture both return channels

Bounces arrive two ways. Most come back synchronously, as a rejection inside the SMTP conversation; M3AAWG's BCP estimated in 2015 that about 95% of returns arrive this way. The rest come later, from a receiving server that accepted the message and then failed to deliver it. RFC 5321 requires that server to mail a notification, sent with an empty reverse-path, to the address in the envelope return path. That address is your return-path, usually on a bounce domain your platform controls.

Capture design follows from those two channels:

• Log every synchronous rejection with its full reply: basic code, enhanced code and text, not just a failed flag.
• Route the return-path mailbox to a parser that can tie each notification to a recipient. M3AAWG says senders must be able to accept and identify the address that bounced; a notification you can't match to a recipient can't update anything.
• Filter what isn't a bounce. Vacation auto-replies land in the same mailbox without being delivery failures. Notifications about messages you never sent are backscatter from forged mail and must never suppress anyone.
• Size it for your volume. The BCP expects returns to be processed at the same volume and rate as the mail that caused them.

Stage two: classify on code and text

M3AAWG makes a point that should shape every classifier. SMTP codes tell a sending server what to do, retry or stop, but they were not designed to tell a bulk sender whether an address belongs on the list. The descriptive text carries that, and the BCP notes it varies greatly from one receiver to the next. A classifier that reads only the first digit will misfile exactly the bounces that matter most.

A working category set, with the default action each one triggers:

| Category | Typical signals | Default action | |---|---|---| | Invalid address | 5.1.1, 5.1.10; "does not exist", "recipient not found" | Suppress immediately | | Disabled mailbox | 5.2.1, "inactive"; Gmail's 552 5.2.2 (out of storage and inactive) | Suppress immediately | | Mailbox full | 452 4.2.2, "out of storage space" | Retry; count toward the repeat rule | | Temporary or rate-limited | 421, other 4xx; "try again later", "rate limited" | Retry with backoff; slow the stream | | Authentication failure | 5.7.26, 5.7.27, 5.7.30, 5.7.23, 5.7.515 | Incident queue; never suppress | | Policy or reputation | 5.7.1 with blocklist, reputation or policy text | Incident queue; never suppress | | Message-level | Gmail's 554 5.6.0 (malformed) and 552 5.3.4 (size, attachment or header limits) | Fix the template or payload | | Unclassified | Anything else | Human review, then write a rule |

The rule that prevents the most damage lives in the right-hand column: only address categories touch the suppression list. Authentication and policy failures describe your sending. Suppressing the recipients hides the fault and deletes valid contacts, so route those to whoever owns DNS and deliverability, with the SMTP error 550 guide as the triage reference.

Two cautions belong in the rulebook. Codes aren't uniform across receivers: Microsoft's Exchange Online documentation uses 5.2.2 for a sender exceeding its submission quota, where RFC 3463 defines x.2.2 as a full mailbox, so provider-specific rules should override generic ones. And RFC 5321 records a historical mix-up worth encoding: a 552 returned for too many recipients should be treated as temporary, because the correct code for that condition is 452.

Stage three: retry transient failures on a schedule

Temporary failures deserve retries, and the schedule matters. RFC 5321 says a sender must delay before retrying a failed destination, recommends retry intervals of at least 30 minutes, and puts the give-up time at generally at least 4 to 5 days. M3AAWG adds a warning: some receivers deliberately return a temporary failure on an initial message to see whether the sender follows the RFCs, since spammers generally don't. That is the logic of greylisting, and a system that treats every 4xx as final fails the test and loses real subscribers.

Two refinements separate management from mere retrying. When a whole receiving domain starts deferring, the problem is rate, not addresses. Google's email sender guidelines tell senders to reduce volume when messages start bouncing or being deferred, until the SMTP error rate decreases, so per-domain email throttling should respond to each deferral pattern automatically. And when retries finally run out, the resulting soft bounce should feed the repeat rule in stage four rather than trigger suppression on its own.

Stage four: suppress on written rules

Write the suppression rules down, because platforms differ and migrations happen. A defensible rule set drawn from the published guidance:

1. Invalid or disabled address: suppress on the first bounce. M3AAWG stresses that when a receiver says no such user exists, the message must not be retried and the address should be suppressed. Yahoo's Sender Hub asks senders to remove invalid recipients promptly.
2. Repeated failures of any kind: suppress after consecutive bounces. M3AAWG recommends removal when an address bounces consecutively at least twice over two weeks or more, a window meant to absorb one-off errors on the receiving side.
3. Sender-side failures: never suppress. Hold those sends until the incident is resolved, then resume.
4. Address suppressions are global. A mailbox that doesn't exist doesn't exist for any stream, tool or future platform, and the suppression must survive list imports.

Store the date, the category and the raw code and text with every suppressed address. That record answers the questions that come later: why a customer stopped receiving invoices, whether a burst of suppressions was genuine, which acquisition source produced the dead addresses. Reinstating an address suppressed as invalid should require fresh confirmation from the subscriber, never a bulk un-suppress.

Stage five: monitor by category and by domain

One blended bounce rate hides the stories. Track these per campaign and per week:

• Invalid-address bounces by acquisition source. A form or import producing a disproportionate share is a collection problem, fixed at the source with double opt-in.
• Bounces by receiving domain. A spike concentrated on one domain is a receiver-side event or a block and needs a look before any suppression runs. B2B lists feel this most, since one domain can be a major account.
• Sender-side categories as alerts. A sudden rise in 5.7.x authentication or policy refusals should reach someone the same day. Common triggers include a DNS edit, a new sending service without DKIM signing and a fresh blocklist entry, and the effect reaches every recipient at that provider.
• Receiver dashboards beside your own data. Google's Postmaster Tools and Microsoft SNDS show the receiver's side of the same relationship.

Where the comfort thresholds for the overall rate sit, and why they are conventions rather than published limits, is covered in the bounce rate guide.

Stage six: close the loop upstream

Bounce management that ends at suppression treats symptoms. The durable fix is upstream, in how addresses arrive and how long they stay. M3AAWG recommends recording how each address came to be on the list, including sign-up source, date and time, precisely so that problem segments can be traced later. Join that record to your bounce data and the bad sources name themselves. Then retire addresses before they fail: a standing list hygiene policy removes the unengaged while they are still deliverable, and Yahoo's advice to monitor inactive recipients alongside hard and soft bounces points the same way. The wider operating model is in bulk email best practices.

If your platform does this for you

Most email platforms run some version of stages one to four automatically, and that is usually the right place for it. Verify rather than assume:

• Does it expose the raw code and text for every bounce, or only a hard or soft label?
• Can you see, or configure, the rule that converts repeated soft bounces into suppressions?
• Does it keep authentication and policy refusals out of the suppression list?
• Can you export the suppression list with reasons, so it survives a move to another platform?

A platform's description of its own bounce handling is a vendor claim until your bounce logs confirm it. If the answer to the first question is no, every later stage becomes guesswork.

Related guides

• Hard bounce vs soft bounce — the per-bounce decisions this process automates
• SMTP error 550 — triage for permanent refusals that aren't about the address
• Email bounce rate — the aggregate metric and its conventions
• Suppression list — the ledger every stage-four rule writes to
• List hygiene — retiring addresses before they bounce
• Email authentication checker — first stop when authentication bounces spike

About this guide

Written by InboxRatio Editorial. Retry timing and the notification duty for failures after acceptance follow RFC 5321; enhanced status code meanings follow RFC 3463. Return handling, classification principles and the consecutive-bounce removal rule come from the M3AAWG Sender Best Common Practices (version 3.0, February 2015). Provider codes come from Google's Gmail SMTP error reference and Microsoft's Exchange Online non-delivery report documentation, and list guidance from Google's email sender guidelines and Yahoo's Sender Hub, checked on 11 September 2026. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on protocol, provider and industry documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

17 October 2026. Specification and provider references reviewed quarterly.

Frequently asked questions

What is email bounce management? The process that captures failed deliveries, classifies each one by its SMTP code and text, retries temporary failures, suppresses invalid addresses on written rules, escalates sender-side failures and monitors the trends. It turns individual bounces into list and infrastructure decisions.

How should hard bounces be handled? Suppress invalid or disabled addresses on the first bounce, permanently and on every platform you send from; M3AAWG's BCP stresses that an address the receiver reports as unknown must not be retried. Hard bounces citing authentication or policy are the exception: fix your setup instead of suppressing the recipient.

How many bounces before removing an address? M3AAWG's Sender Best Common Practices recommend removing an address that bounces consecutively at least twice over two weeks or more, with any failure code. Invalid-address bounces are the exception and should suppress at once. Platforms apply their own thresholds, so check what yours does.

How long should a mail server retry a soft bounce? RFC 5321 recommends waiting at least 30 minutes between retries and continuing for generally at least 4 to 5 days before giving up. Sending platforms usually manage that schedule automatically.

Should authentication failures go on the suppression list? No. A 5.7.26 or 5.7.515 rejection means your SPF, DKIM or DMARC setup failed, and every recipient at that provider would bounce the same way. Route it to whoever manages DNS, and resend after the fix.

What is an asynchronous bounce? A failure reported after the receiving server accepted the message. RFC 5321 requires that server to mail a notification to the envelope return path, so bounce handling must parse that mailbox as well as SMTP rejections. M3AAWG estimated in 2015 that about 95% of returns arrive synchronously instead.

Pull last month's bounces this week and sort them into the categories above. Any contacts suppressed for authentication or policy failures belong back on the list once your setup checks clean in the email authentication checker; then write the rules down.