Email bounce rate: hard vs soft bounces, and what to do when it spikes

Hard and soft bounces in SMTP terms

SMTP replies begin with a digit that carries the verdict. A 4xx reply is a transient negative completion: the action did not happen, but the condition is temporary and the request may be repeated. A 5xx reply is permanent: the request was rejected, and the client should not repeat it as sent. [1]

Enhanced status codes add detail in the form class.subject.detail. The class follows the same logic—4 for a persistent transient failure, 5 for a permanent one—while the subject says what failed. X.1.1 means the mailbox does not exist, X.2.2 means it is full, X.4.x points at network or routing, and X.7.x reports security or policy refusals such as filtering. [2]

Sources [3][4]

Not every bounce arrives during the conversation

Some failures are refused during the SMTP session, so the sender learns immediately. Others are accepted first and fail later, when a downstream server cannot deliver. Those come back as delivery status notifications: machine-readable reports whose action field says whether delivery failed, was delayed, or succeeded. [5]

A sending system therefore needs two intake paths—synchronous replies and asynchronous reports—and both must update the same recipient state. Unique bounce return paths make it possible to tie a late report to the exact message and recipient instead of guessing from the text of the notice.

Temporary failures deserve patience, not persistence. RFC 5321 says the retry interval should generally be at least 30 minutes and that the give-up time generally needs to be at least four to five days. A retry loop measured in seconds turns a deferral into a reputation problem. [1]

Why “good bounce rate” benchmarks mislead

Articles often promise that a bounce rate under some round number is healthy. Those figures rarely say which denominator, which bounce types, which audience, or which period they measured, and a benchmark built on opt-in newsletters says little about a verified B2B list or a newly acquired one.

A bounce rate needs a definition before it means anything: hard bounces divided by messages submitted, over a named window, for a named campaign or sending identity. Mailbox providers are more direct than benchmarks about what they expect. Microsoft tells high-volume senders to remove invalid addresses regularly to reduce bounces, complaints, and wasted messages. [6]

Set a threshold that stops sending before a receiver forces the issue. The right number is the one you will enforce automatically, not the one that keeps a dashboard green.

What usually causes a spike

Read the codes before reaching for a cause. Mailbox errors point at the data; policy errors point at the sender.

• Stale or unverified addresses, especially from old exports or guessed address patterns.
• Catch-all domains, where verification cannot confirm the mailbox and some real messages fail later.
• A new source or import that skipped the usual verification and suppression checks.
• Authentication or DNS drift, which shows up as policy refusals rather than mailbox errors.
• A reputation problem: 5.7.x refusals clustering at one receiver usually mean that receiver has decided against the mail, not that the addresses are bad.

How to handle each kind

Keep the rule simple enough to automate. If a person has to read every bounce before anything stops, the system keeps sending while the review queue grows.

• Permanent mailbox failures (5.1.x): suppress immediately, and never let a later import reactivate the address.
• Temporary failures (4.x.x): retry with backoff, slow the affected route, and stop after a defined give-up period.
• Policy refusals (5.7.x, or repeated 4.7.x deferrals): pause the affected identity or campaign and investigate authentication, reputation, and audience before sending more.
• Asynchronous reports: parse the delivery status notification, match it to the exact message, and update the same suppression record a live rejection would.

Actually Agentic’s bounce thresholds

Actually Agentic pauses a campaign for review at three hard bounces, or when hard bounces reach 2 percent of submitted messages once at least 20 have been submitted, measured over the campaign’s recent window of up to 30 days. The same 2 percent ceiling also applies to the sending server as a whole, across campaigns. Permanent bounces suppress the recipient for future sends. [7]

Soft failures create temporary cooldowns for the affected provider and route instead of immediate retries, and a blocklist or authentication problem holds work for investigation rather than routing around it. Verification comes first: no domain is registered until at least one candidate verifies as valid, catch-all results do not count, and catch-all addresses are excluded from sending unless the reviewed plan expressly allows them. [7][8]

These are conservative defaults for a prelaunch service, not a claim about what any mailbox provider requires.