Bounce Handling Guide: Hard vs Soft Bounces, SMTP Codes, Suppression, and Provider Guardrails

Start with the operator distinction: hard vs soft bounce

A hard bounce means the delivery path is not expected to recover without changing the recipient or the sender-side configuration. The classic examples are an unknown user, an invalid recipient domain, or a permanent policy refusal. Remove the address from the sendable audience immediately. Keeping it active turns one permanent failure into a repeated list-quality signal.

A soft bounce means the receiver has not accepted this attempt, but a later attempt may work. Greylisting, a busy receiving server, a full mailbox, a temporary rate limit, and transient network failures belong here. A soft bounce still needs a policy: retry with backoff for a bounded period, then age it into suppression if the mailbox never recovers. “Soft” does not mean “retry forever.”

The word shown in an ESP dashboard is only a convenience label. Read the SMTP reply and the enhanced status code in the DSN (Delivery Status Notification) as the source of truth, then add provider, campaign, recipient, and timestamp to the event. The operator question is not “did it bounce?” but “is this recipient unavailable, or is this receiver telling us to change how we send?”

Read 4xx and 5xx as a decision tree, not a dashboard color

SMTP reply classes give you the first branch. A 4xx response is a temporary negative completion: the receiving server is asking you to try later, or it is refusing this attempt while a condition may clear. A 5xx response is a permanent negative completion for that delivery attempt and should not be replayed blindly. The enhanced code supplies the useful second branch — 5.1.1 says something very different from 5.7.1.

Use exponential backoff for retryable responses: retry after the receiver's requested delay when it provides one, then increase the delay between attempts and cap both the attempt count and total age. Keep retries in the same provider bucket so a Gmail throttle does not cause you to increase Outlook traffic, and stop the queue if the same 4xx pattern spreads across a meaningful share of the campaign. A retry policy without a stop condition is a sender-side amplification loop.

Treat the code as evidence, not a complete verdict. A 550 across thousands of different recipients is unlikely to be a simple list of bad addresses; it may be a reputation, blocklist, authentication, or content-policy event. Compare the SMTP text, receiving provider, sending IP, domain, and message version. The SMTP bounce codes explained guide is the code-reference companion, while the business email bounce-fix guide covers the sender-side recovery loop.

Provider guardrails: thresholds are operating controls, not guarantees

There is no universal Gmail or Outlook bounce-rate number at which every sender is automatically stopped. Receiver decisions vary by traffic type, recipient mix, domain and IP history, authentication, complaint rate, and the exact SMTP reason. Set conservative internal guardrails anyway, then interpret them beside provider telemetry. The numbers below are operating controls for deciding when to pause a stream — not promises about receiver behavior and not a substitute for reading the code distribution.

Gmail-facing traffic deserves a low hard-bounce ceiling because stale lists and repeated unknown-user failures can quickly become a broader sender-quality signal. Outlook-facing traffic needs earlier intervention when a rate-limit response such as 421 4.7.28 repeats: the problem may be pacing or reputation, not recipient validity. Keep the streams separate in reporting. A blended 1% number can hide a severe provider- specific failure.

Use the same pause rule during warm-up, after a domain reactivation, and after a list or content change. The Gmail bulk-sender requirements guide explains the broader Gmail sender posture, while the Outlook junk-folder troubleshooting guide gives the Microsoft-specific recovery context.

Suppression-list hygiene: make every refusal stateful

Suppression is the control that stops a delivery event from becoming a reputation event. Write the state at the moment the provider responds, consult it before the next send, and retain enough reason data to distinguish a dead address from a sender-side policy block. A suppression list that is only exported once a month is a report, not an operating safeguard.

• Suppress hard bounces immediately. Unknown-user, invalid-domain, and permanently rejected recipients should not enter the next retry or campaign audience.
• Bound soft-bounce retries. Set a maximum attempt count and age window, use exponential backoff, and stop when the provider continues returning the same transient failure.
• Age mailbox-full failures. A full mailbox can recover, so give it a bounded grace period; if repeated 5.2.2 responses outlive that period, suppress until the recipient is explicitly revalidated.
• Deduplicate before counting. Normalize casing and surrounding whitespace, use one canonical recipient key, and prevent the same address from appearing once per CRM, ESP, or list import.
• Synchronize every send surface. Keep suppression state aligned across the sending platform, CRM, warehouse, enrichment tool, and any secondary automation. One unsynchronized source can reintroduce the address you just suppressed.

Store the address, normalized key, first-seen and last-seen timestamps, provider, campaign, SMTP code, enhanced status code, response text, retry count, and reason category. Keep the original event even if a later operator reclassifies it. This gives you the evidence to tell a list-quality problem from a provider-wide refusal, and it makes a replay after recovery deliberate rather than accidental.

Gmail and Outlook feedback loops: read bounces with reputation

Bounce rate tells you that delivery failed; feedback and reputation surfaces help explain why. For Gmail, read Postmaster Tools domain and IP reputation, spam-rate movement, and delivery behavior alongside the SMTP distribution. For Outlook, read SNDS and complaint feedback such as JMRP alongside per-IP response patterns. These surfaces are directional and traffic-dependent, but they are much more useful than a single blended bounce percentage.

The important combined signal is a bounce and complaint move in the same provider segment. That usually means the issue is not just a handful of dead addresses: the audience may be stale, the message may be unwanted, the authentication or domain alignment may have regressed, or a blocklist / reputation event may be changing the receiver's treatment. Pause that segment, stop retries, and validate the sending stack before resuming.

Before restarting, verify the authentication foundation: the SPF troubleshooting guide covers lookup limits and include-chain failures, and the email warm-up guide covers the volume ramp and the pause signals for a new or reactivated domain. Authentication and pacing are upstream controls; suppression is what prevents the same bad recipients from poisoning the recovery attempt.

The recovery runbook: from bounce wave to safe resend

When a campaign produces an unusual failure spike, do not start by editing the template or replaying the queue. Freeze the affected provider segment and work through the evidence in this order:

1. Freeze retries and preserve the sample. Keep the raw SMTP and DSN response, provider, IP, domain, campaign, and time window for at least the full incident review.
2. Bucket by code and provider. Separate unknown users, mailbox-full, throttling, policy, authentication, and blocklist-shaped responses instead of averaging them together.
3. Apply suppression immediately. Remove permanent recipient failures, then cap and age the retryable bucket.
4. Check the upstream sender posture. Validate SPF, DKIM, DMARC, blocklists, PTR, content changes, and provider reputation before changing the pace.
5. Send a small, clean test batch. Use known-good, engaged recipients on the affected provider and compare the code distribution before returning to the previous volume.
6. Resume below the last stable pace. Keep the provider stream isolated, monitor the guardrail, and stop again if the same pattern returns.

A recovery is complete when the response distribution is stable, the suppression state is synchronized, and the provider reputation surface is no longer moving in the wrong direction. “The campaign eventually delivered” is not enough if the retry storm trained the receiver to distrust the next campaign.

Related guides and tools

Use the bounce signal as the entry point, then follow the link that matches the dominant cause. The fastest fix is usually the one that narrows the provider, code, and recipient segment before you change anything globally.

• Free email warm-up checker → — Check authentication, blocklist posture, and bounce readiness before a recovery send.
• Email Warm-Up Guide → — Set a safe ramp and know when bounce or complaint signals require a pause.
• SPF Troubleshooting Guide → — Fix include-chain and lookup-limit failures that can surface as sender-side refusals.
• SMTP Bounce Codes Explained → — Decode the enhanced status code before you choose retry or suppression.
• Business Email Bounce Fix → — Follow the sender-side recovery checklist for a bounce wave.
• Email Reputation Guide → — Read Gmail, Outlook, and Yahoo reputation signals as one operating system.