How to reduce email bounce rate (verify, warm, and auto-pause)

Before you reduce a bounce rate, define it — because four choices about the measurement move the number more than any change to your list will. Which failures go in the numerator, which sends go in the denominator, over what window, and at what scope. Then accept that the signal is lagging: large receivers accept a message and reject it later, so a bounce rate always describes outcomes that arrived rather than sends that happened. Everything useful follows: filter before you send, ramp so the damage is bounded, and pause automatically on a sample large enough to mean something.

Four choices that change the number more than your list does

Two teams with identical lists and identical sending can report bounce rates that differ by a factor of three, entirely from definitional choices. The four decisions:

• The numerator. Every failed delivery? Only permanent ones? Only permanent ones caused by the recipient rather than by your own configuration? A rejection of your sending identity is a failure that says nothing about the list, and counting it makes the number describe your setup rather than your addresses.
• The denominator. Attempted sends, accepted sends, or delivered sends. Accepted is the usual choice and it is the one that quietly inflates the rate, because messages refused at connection time never enter it.
• The window. A rolling 24 hours, a rolling 7 days, a calendar month, or a volume-based window. A short window is far less forgiving: one bad import cannot be averaged away inside it.
• The scope. Per campaign, per mailbox, or per workspace. A per-workspace rate lets one bad campaign gate every other one; a per-campaign rate gives no signal at all until that campaign has volume.

Autocloz resolves all four explicitly rather than leaving them implied. The rate is computed over sent and bounce events in a rolling 24 hours, scoped to the campaign being evaluated when that campaign has a large enough sample, and falling back to the whole workspace when it does not — so a workspace-level reputation incident bleeding across campaigns is still caught. Write your own four choices down before you quote a figure to anyone.

Whose definition are you being judged by?

Your own dashboard is not the one that suspends your account. Two published definitions are worth knowing verbatim, because they measure different objects.

Amazon SES. AWS states that "your bounce rate includes only hard bounces to domains you haven't verified", that "hard bounces are permanent delivery failures such as 'address does not exist'", and that "temporary and intermittent failures such as 'mailbox full,' or bounces due to blocked IP addresses, don't count toward your bounce rate". The thresholds are published: maintain below 2% for best results; "if your bounce rate is 5% or greater, we'll place your account under review"; "if your bounce rate is 10% or greater, we might pause your account's ability to send additional email". Complaints have their own pair — 0.1% for review, 0.5% for a pause.

Two details in that definition change how you should read your own numbers. First, AWS does not use a fixed period: it calculates over a "representative volume — an amount of email that represents your typical sending practices", which "is different for each user". Second, AWS says plainly that you cannot reproduce its figure from the console or the send-statistics API, because of that representative volume and because only unverified domains count. Your dashboard and theirs will legitimately disagree, and neither is wrong.

Google. Postmaster Tools has no bounce-rate chart. Its nearest equivalent is the Delivery errors dashboard, which Google defines as "the percent of all authenticated messages (SPF or DKIM) that were rejected or that temporarily failed". Note what that includes: temporary failures, which most bounce-rate definitions exclude. And note the qualifier — authenticated messages only.

So there are at least three numbers in play, all called a bounce rate, none of them comparable. Quote the scope with every figure you report internally, and treat a number without one as unusable.

Your bounce rate is a lagging measurement, and that limits every control built on it

A synchronous rejection arrives inside the SMTP conversation. An asynchronous one does not: the receiving edge returns 250, takes responsibility for the message, and only later discovers it cannot deliver — then generates a separate delivery status notification addressed to the envelope sender in the Return-Path. Minutes later. Sometimes days.

Three consequences follow, and each one constrains what a threshold can achieve.

1. The rate you see now describes deliveries that resolved now. In a 24-hour rolling window, a bounce from yesterday's send counts against today's rate. That is correct behaviour and it means the rate is not a measurement of the campaign currently running.
2. A pause always fires after some of the damage. By the time enough asynchronous bounces have arrived to cross a threshold, the sends that caused them have already been made. A threshold is a limiter on how much worse it gets, not a preventer.
3. Bounces you never see still count against you. If nothing reads the Return-Path mailbox, those notifications are discarded and the addresses stay in your list. The provider recorded the failure regardless. This is the single most common reason a workspace's internal bounce rate is far lower than the receiving side's view of it, and reading a bounce properly starts with making sure you receive them at all.

The design conclusion is not "abandon thresholds". It is that the only control which acts *before* damage is pre-send filtering, and everything else is containment.

What a verifier can actually prove, and what it cannot

This is where most bounce-reduction advice overstates the tooling, so here is the honest version of what a verification pass does.

Autocloz's in-house verifier is a layered pipeline in which the first definitive verdict wins: RFC-shaped syntax; a Damerau-Levenshtein typo guard against the top hundred domains, so gmial.com and hotnail.com are caught; roughly three thousand known disposable providers; role addresses such as info@ and support@, flagged as risky rather than blocked because a role account harms reputation rather than delivery; and finally an MX lookup, cached per domain rather than per address so a hundred-thousand-row list resolves a few thousand domains.

Now the part worth being blunt about. That pipeline cannot return "deliverable" on its own, and it is designed not to. The SMTP RCPT TO probe that would prove a specific mailbox exists was removed on 31 July 2026, for reasons that are their own argument: the probe required per-mail-exchanger rate limiting because recipient enumeration gets the probing IP listed on blocklists, outbound port 25 is blocked on most hosts, and a verification path that must be throttled cannot honestly be sold as unlimited. So an address that clears every layer is reported as risky and unconfirmable, which is the truthful verdict.

"Deliverable" is written only by evidence that cannot be fabricated — a real delivery acceptance, or the Microsoft directory oracle for Microsoft-hosted domains. Verdicts also carry a deterministic 0–100 confidence score with published bands: 95–100 for proven deliverable, 70–94 for softer evidence, 30–69 risky or unconfirmable, 10–29 unknown, and 0–9 undeliverable, with a catch-all domain costing 25 points because an accept-all answer is not evidence a mailbox exists.

Read that as a positive rather than a limitation. A verifier that confidently returns "valid" for a catch-all domain is guessing; one that says unconfirmable is telling you what it actually established. The four stages of cleaning a list covers what to do with each verdict, and the free address checker runs the same layers on a single address.

The three controls, in the order they actually help

1. Filter before you send. The only control that prevents rather than contains. Two parts: verification at import and re-verification before mailing an aged cohort, and a suppression list that survives the import so an address which bounced hard last quarter cannot be reintroduced by this quarter's CSV. Autocloz's free plan includes 1,000 verifications a day and workspace-scope suppression, and the per-tier verification allowances rise from there.

2. Ramp, so the damage is bounded. A new mailbox on a 21-day smoothstep ramp cannot send its configured volume, which means a contaminated list on a new identity produces a fraction of the bounces it would on a mature one. That is a genuine benefit of warmup that has nothing to do with reputation theory: it caps the blast radius of a mistake you have not found yet.

3. Pause automatically, on a sample that means something. The specification matters more than the number:

• Threshold resolution. Per-campaign setting first, then the workspace default, then the autopilot rulebook cap for autopilot campaigns, then a 15% safety floor applied only to manual campaigns with nothing configured. The floor exists so a runaway list cannot tank a workspace that never set a value; it is deliberately loose, because a tight floor imposed on people who did not choose it stops legitimate sending.
• A minimum sample of 100 send-or-bounce events in the window before any threshold can fire, universally. Three bounces out of twelve is 25% and means nothing.
• Per-campaign first, workspace as fallback, so one bad list halts its own campaign rather than every campaign.
• A notification the owner can act on, naming the measured rate and the configured threshold, deduplicated to one per campaign per hour so the operator gets one alert rather than twenty a minute.

Per-mailbox health decay is a separate control operating at a different scope, and conflating the two is a common mistake. Each send adjusts a mailbox's health score: plus one on success, minus two on a transient failure, minus eight on a permanent one, with auto-pause at or below 40. Critically, a failure with no provider verdict — a transport error, an expired credential, a bug in your own queue — leaves the score untouched, because charging your own outage to the domain's reputation is worse than not scoring at all.

The arithmetic on one bad import

Numbers make the containment argument concrete. Take a 2,000-address import in which 6% of the addresses are dead — a figure you should measure on your own list rather than borrow, since it depends entirely on where the list came from and how old it is.

That is 120 hard bounces waiting to happen. Send it across a fleet of 18 mailboxes each clearing about 56 campaign sends on a working day, and the whole list goes out in roughly two days at about 1,008 sends a day. The workspace rate over those sends is 120 in 2,016, or 5.95% — past Amazon SES's published 5% review line and past any threshold a sensible operator would configure.

Now change one thing. Verify at import, remove what the pipeline can prove is undeliverable, and hold the merely unconfirmable back for a smaller first batch. The bounces that remain are spread over a smaller denominator of confirmed sends, and — this is the part that matters — they are discovered on a hundred-message test batch rather than on two thousand. The arithmetic of the threshold has not changed; what changed is which sample it fired on.

Autocloz's free plan covers 5 users and 10 mailboxes with 1,000 verifications a day, the 21-day ramp and the automatic bounce gate active from the first campaign — start free and run the first hundred addresses of an import as their own batch before the other 1,900 go anywhere.

What to do when the rate is already high

In order. Do not skip to step four; it is where most people start and it is the least effective.

1. Stop sending from the affected identity. Not the whole workspace, the affected mailbox or campaign. Every further send adds to a window that is already over.
2. Read ten actual bounces. Not the count — the text. If most are 5.1.1, it is list quality. If most are 5.7.x policy or authentication codes, it is your configuration and the list is innocent.
3. Fix the class you found. Dead addresses: suppress them permanently and re-verify the remaining list. Authentication: publish or align the record, which is a DNS change rather than a list change.
4. Wait out the window. With a rolling 24-hour rate, the number falls on its own once bad sends stop entering it. There is nothing to do here but not make it worse.
5. Resume properly. A resume that flips the status flag while leaving the health score at its paused value re-trips on the very next send, because successes recover only one point. Autocloz lifts a resumed mailbox to 20 points above the auto-pause threshold and zeroes the bounce-spike counter — a real trial window rather than an amnesty, and it survives two more permanent failures before pausing again.
6. Re-enter at a fraction of previous volume, and watch the email channel's per-mailbox numbers rather than the workspace average.

What bounce-rate management cannot fix, and what Autocloz does not do

A low bounce rate is a hygiene result, not a performance result. It says your addresses exist. It says nothing about whether anyone wanted the message, and complaint rate — which no amount of verification touches — is the signal every provider weighs more heavily than bounces.

Verification cannot detect a spam trap. A recycled trap is a technically valid, accepting mailbox; it passes every check a verifier can perform. The only defence is provenance: never buy, rent or scrape a list, and suppress hard bounces promptly so your own addresses are not recycled into traps.

Verification cannot prove a mailbox exists without sending to it. That is a property of the protocol at the large providers, not a gap in any particular product, and any tool claiming a confident "valid" on a catch-all domain is reporting a guess as a fact.

And Autocloz specifically: its verifier opens no connection to a mail server, so it can prove undeliverable and never deliverable on its own. It does not sell contact data or bundle a lead database, so bounce rate is a property of a list you brought. It cannot read a Return-Path mailbox it has not been given access to, which means asynchronous bounces routed elsewhere are invisible to it as they are to you. And no threshold, ramp or verification pass makes placement certain — what they remove are the failure modes that are documented, measurable and yours to control.