What are the best practices for managing hard and soft bounces in daily email campaigns?
Published 7 May 2025
Updated 24 Oct 2026
16 min read
Summarize with
Updated on 24 Oct 2026: We clarified how to measure bounce rates and apply suppression rules without discarding valid subscribers.
The best practice for daily email campaigns is simple at the policy level: suppress confirmed permanent recipient failures immediately, handle soft bounces by reason over a rolling time window, and never let a high send frequency turn one temporary delivery problem into five separate penalties in the same day.
For a daily sender, especially one sending up to five messages per day based on preferences, use bounce days for recipient suppression rather than raw bounced messages. Five campaigns that fail for the same recipient on Monday should count as one bounce day. Tie retries to the original message and recipient, then count the final outcome once using the original send date. A newer accepted delivery can reset the live counter for that recipient, reason, and sending stream. A recent click can support a manual review, but it should not replace delivery evidence or erase the historical bounce log.
- Hard bounce rule: Suppress after one confirmed permanent recipient failure, such as an invalid user, an invalid destination domain, or a permanently closed mailbox.
- Soft bounce rule: Pause repeated recipient-level soft failures using a documented rolling window. Set separate rules for mailbox full and other temporary failures; the example windows below are internal starting points.
- Retry rule: Keep temporary deferrals in a pending state during the retry window. Do not count each retry attempt as a new bounce.
- Policy bounce rule: Do not treat authentication, reputation, throttling, or blocklist (blacklist) failures as proof that the recipient address is bad.
- Reset rule: Reset the relevant active counter after a newer accepted delivery, but retain the raw events and unrelated stream failures.
Hard and soft bounce handling rules
A good bounce policy has two goals. First, it protects sender reputation by stopping mail to addresses that receivers have told you are bad. Second, it avoids suppressing real subscribers because of temporary mailbox, network, rate-limit, or sender-side problems. Those goals conflict when the rule is too blunt.
Do not treat a temporary "mailbox full" response as an instant removal event. It means the mailbox cannot accept the message now, rather than proving the address is invalid. Pause repeated failures using the window below. A permanent mailbox-full rejection needs separate review before any further send, and engagement alone does not establish that storage is available.
|
|
|
|---|---|---|
Invalid user | 5.1.1 | Suppress now |
Invalid destination domain | 5.1.2 | Suppress now |
Disabled or closed mailbox | 4.2.1 or 5.2.1; inspect reply | Suppress confirmed permanent closure; pause a temporarily disabled mailbox |
Mailbox full | 4.2.2 or 5.2.2 | 4xx: retry with limits; 5xx: stop this message and review |
Message too large | 5.2.3 or 5.3.4 | Fix message size |
Rate limit | 4.7.28 or explicit throttle reply | Throttle sending |
Policy block | 5.7.x | Investigate source |
Unknown response | Missing or ambiguous diagnostic detail | Hold new campaigns and review raw reply |
A starting point for daily campaign bounce handling.
Suppress confirmed invalid addresses after one failure
If the receiving server clearly says the user or domain does not exist, suppress that address after one event. Waiting for three confirmed hard bounces adds avoidable negative signals. The exception is an ambiguous hard-classified response, where the address should be quarantined and the raw reply reviewed before permanent suppression.
That distinction matters because a bounce label is often a product decision, not a universal truth. One sending platform can classify a response as hard while another calls the same reply soft, and receivers do not always return clean enhanced status codes. Treat the label as a starting point, then store the raw SMTP reply, the enhanced status code, the receiver family, and the sending IP or stream.
Classify by cause and bounce label
The most important operational habit is classification. Hard and soft are useful labels for reporting, but they are not detailed enough for automation. A failed delivery can mean the recipient address is gone, the mailbox is full, the message is too large or complex, the receiver is greylisting or throttling you, DNS or routing is temporarily failing, your sending IP has a reputation problem, the message failed a policy check, or the response text is too vague to trust.
When a bounce report or non-delivery report (NDR) is available, keep it with the event. The diagnostic text helps distinguish recipient failures from sender authentication or message-size problems. Distinguish a confirmed invalid destination domain from a DNS timeout or SERVFAIL, which calls for retry rather than permanent suppression.
Use the SMTP reply class to decide whether the current message is retryable, then use the reason to decide recipient eligibility. A 4xx reply indicates a temporary failure; a 5xx reply rejects the current attempt permanently and should not be retried unchanged without review. Enhanced status codes add detail: X.1.x covers addressing, X.2.x mailbox status, X.3.x mail systems, X.4.x routing, X.6.x content, and X.7.x policy. See RFC 5321 for retry behavior and RFC 3463 for enhanced status codes.
For SMTP suppression rules, start with the receiver's full reason. A 5.7.x policy or reputation rejection does not prove the address is invalid. Greylisting normally returns a temporary deferral, so keep it in the retry state rather than counting it as a bad recipient.
Weak bounce logic
- One label: Only stores hard or soft, with no raw reply or receiver context.
- Message count: Counts every failed campaign as a separate strike, even on the same day.
- Substring match: Matches partial codes and turns similar policy replies into wrong actions.
Better bounce logic
- Reason family: Stores invalid user, disabled mailbox, mailbox full, rate limit, policy, and unknown.
- Bounce day: Counts one failed recipient-day, even when several campaigns are sent.
- Retry state: Keeps deferred attempts separate from final bounce events.
- Exact parsing: Uses exact code tokens plus raw text and receiver-specific exceptions.
The common parsing mistake is substring matching. A rule that searches for 5.7.6 can also match 5.7.60 and apply the wrong policy rule. Parse the complete enhanced status token, then check the raw reply and receiver-specific documentation.
A mailbox can be temporarily disabled. Suppress confirmed permanent closure, but pause new campaigns and retain normal retries for a temporarily disabled mailbox response such as 4.2.1. Gmail also uses 5.2.1 for recipient rate limits, so inspect the text before deciding. Gmail's SMTP response reference documents these distinctions and a permanent 5.2.2 response for an out-of-storage, inactive inbox.
Example bounce classification modeljson
{ "recipient": "user@example.com", "eventDate": "2026-05-23", "smtpCode": "550", "enhancedCode": "5.1.1", "receiverFamily": "consumer_mailbox", "reasonFamily": "invalid_user", "rawReply": "550 5.1.1 user unknown", "action": "suppress_permanent", "counterScope": "recipient_day" }
Separate recipient failures from sender failures. Invalid users and confirmed permanent mailbox closures require recipient suppression. Rate limiting, authentication failure, reputation blocking, and content rejection need action on the affected stream, domain, IP, or campaign. Suppressing individual users does not solve a sender problem.
How to count bounces for a daily sender
Frequency changes the math. If a subscriber can receive five messages per day, a raw "10 bounces" rule can suppress someone after only two bad days. Use a rolling window with at most one counted recipient failure per calendar day per reason family, using a consistent timezone. Exclude sender-wide failures such as rate limits from recipient strikes. Do not let a late bounce from an older message undo a newer accepted delivery.
Separate temporary deferrals from final bounces. The retry window depends on the sending system and message lifetime. RFC 5321 describes delayed retries and a general queue lifetime of at least 4 to 5 days; campaign systems use their configured expiry. Record that expiry for each sending path and count the final outcome once. Expire time-sensitive campaign content before it becomes stale.
A reasonable soft bounce tolerance depends on failure reason. Give mailbox full more time than a generic repeated failure, because it often has a clear user-side explanation. Give rate limits no recipient penalty at all, because the fix is volume shaping and reputation work.
|
|
|
|
|---|---|---|---|
Invalid recipient | Confirmed permanent recipient failure | Corrected address and review | Suppress across streams |
Mailbox full | Bounce days | Newer accepted delivery | Pause first |
Transient | Bounce days | Newer accepted delivery | Pause and review |
Rate limit | Receiver | Receiver recovery | Do not suppress |
Example counters for high-frequency daily mail.
There is no universal soft-bounce suppression count. For daily campaigns, one internal starting policy is a pause after 3 to 5 distinct transient bounce days within 7 days, or 7 mailbox-full bounce days within 14 days. After pausing, review queue outcomes and keep unresolved addresses out of routine sends at 10 to 14 elapsed days after the first mailbox-full failure. Do not send extra campaigns just to accumulate strikes. Account activity supports an address-recovery review, not an automatic suppression override.
A clean reset still needs audit history
A newer accepted delivery can reset the live soft-bounce counter for the affected reason and stream. A click supports manual review but does not prove that a later message was accepted. Keep event timestamps and the full history so late notifications or unrelated successful streams do not clear the wrong counter.
How to calculate and review email bounce rate
Calculate campaign email bounce rate using final failed recipient deliveries divided by attempted recipient deliveries, multiplied by 100. Count each message-recipient pair once, exclude contacts suppressed before sending, and exclude intermediate retry attempts. While messages remain queued, label the rate provisional and report pending deferrals separately.
Email bounce rate formula and illustrative exampletext
Bounce rate (%) = final bounced recipient deliveries / attempted recipient deliveries * 100 Example: 10,000 attempted deliveries, 120 hard bounces, 80 final soft bounces Hard bounce rate = 120 / 10,000 * 100 = 1.2% Soft bounce rate = 80 / 10,000 * 100 = 0.8% Total bounce rate = 200 / 10,000 * 100 = 2%
Keep later bounce notifications attached to the original campaign so reporting windows stay comparable. Review hard and soft bounce rates separately by recipient domain and acquisition source. Policy rejection is a reason category within failed delivery, so do not count it again as an additional bounce. Recipient bounce-day counters control suppression; they are separate from this campaign calculation.
Example internal bounce rate thresholds
Illustrative review triggers for total final bounce rate. Your sending provider's rules and normal baseline take priority; investigate sharp increases at any rate.
Below review trigger
Under 2%
Check against your usual rate; a low total can hide a failing segment.
Review
2% to under 5%
Investigate the affected source or recipient domain.
Pause and investigate
5% or more
Pause the affected stream until the cause is understood.
Low bounce rates do not prove inbox placement: accepted email still faces spam filtering. An out-of-office reply is not a bounce. Compare the total with your normal baseline and investigate sharp changes even below an example review threshold.
Retry soft bounces without creating duplicate sends
A 4.x response leaves the original message eligible for another delivery attempt, but it does not justify launching a new campaign send while that message remains queued. Give one system ownership of retries for each message. Otherwise, the mail server can deliver its queued copy after a campaign workflow has already sent a replacement.
- Record queue state: Store the original message and recipient IDs, first attempt, next attempt, queue expiry, and final delivery status. Deduplicate repeated webhook events using a stable event ID.
- Back off by receiver: Slow connections and volume for explicit throttling, greylisting, or temporary receiver failures instead of repeatedly hitting the same domain.
- Deduplicate campaigns: Before another daily send, check active retries for the same campaign and honor recipient pauses. Cancel or expire outdated queued campaigns instead of allowing a backlog to arrive together.
- Count the final outcome: Mark one delivery, one final soft bounce, or one permanent bounce. Keep intermediate deferrals as attempts, not separate bounce strikes.
- Escalate patterns: Move repeated receiver-wide deferrals to sender-side investigation and move repeated recipient-level failures to the soft-bounce counter.
Wait for the active queue to finish
Do not clone and resend a soft-bounced campaign while its original delivery attempt remains pending. Resend only after the queue has ended, the failure reason still supports a retry, and the content is still useful to the recipient.
Prevent avoidable bounces before sending
Bounce management starts before the SMTP failure. Use address validation at signup and confirmed opt-in for new subscribers. Segment inactive contacts before daily sends. Email verification does not guarantee future delivery or establish permission to send.
- Validate entry points: Catch syntax errors, domain typos, and obvious bad addresses before they enter the production list.
- Confirm consent: Use confirmed opt-in (double opt-in) for new signups, especially sources with repeated hard bounces. Import only contacts with documented permission; do not buy or scrape lists.
- Pause stale records: Hold long-inactive subscribers before daily campaigns instead of waiting for bounces to identify abandoned addresses.
- Centralize suppression: Feed hard bounces, persistent soft bounces, inactive records, expired consent, and import failures into one send-time suppression source.
- Track source quality: Trend bounce rate by form, import, partner, campaign, and recipient domain so one bad source does not damage the whole program.
Do not make deletion the first control. Keep a central suppression table keyed by recipient ID or email, apply it after every import and before every campaign send, and store the suppression reason, source, first suppressed date, and last evaluated date. Keep inactive suppression separate from hard bounces, complaints, and unsubscribes. This keeps list management auditable and stops an import from re-enabling addresses that should stay out of daily campaigns.
Unengaged subscribers need a separate rule before they become bounce data. Define inactivity using reliable signals such as human clicks or replies, rather than opens alone, then run a short re-engagement path for eligible contacts. Keep nonresponders out of routine daily campaigns. A purchase or account event does not restore marketing consent or prove that promotional mail will be accepted.
This prevention layer also makes daily bounce rules fairer. A clean acquisition source can use patient soft-bounce windows, while an imported or dormant segment with rising hard bounces should be slowed or cleaned before more volume.
When a bounce is not a list hygiene problem
Some bounces look like recipient failures in a dashboard, but the real issue is authentication or reputation. A policy rejection, a DMARC identifier mismatch, a DKIM signature failure, a broken SPF change, a sudden rate-limit wave, or a blocklist (blacklist) listing should trigger sender-side investigation before recipient suppression.
Suped's DMARC reporting and email authentication platform supports the sender-side investigation. Use Suped's DMARC monitoring to review SPF and DKIM results by sending source when policy bounces rise, and compare those findings with SMTP logs. Suped's blocklist monitoring supports reputation checks. DMARC aggregate reports do not provide recipient-level bounce events, so keep bounce counters and suppression in your sending system.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Before changing bounce thresholds, check the domain and authentication baseline. A quick domain health review helps identify broken DNS records and sender setup issues. Broad failures by receiver, IP, or campaign need sender-side investigation, but scope alone does not prove the cause; an invalid destination domain can also affect multiple contacts.
If an ESP exposes a shared, global, or account-level bounce status, treat it as a platform suppression state rather than a local list rule. Reactivate only when the recipient is proven valid, the blocking cause is fixed, and the raw reply supports the change.
Treat 5.7.x with care
A 5.7.x response often points to policy, authentication, permissions, reputation, or abuse controls. Do not mark those recipients as invalid without evidence that the address itself is bad. Pause the affected stream, group events by receiver, and inspect authentication plus blocklist or blacklist status.
When bounces or deferrals rise across one receiver, reduce and pace that stream until SMTP error rates fall, then increase volume gradually while watching the same response family. For a new sending domain or IP, start with small batches to recently engaged, opted-in recipients and increase only while error rates stay stable. Avoid sharp volume spikes.
A rule engine should separate recipient actions from sender actions. Recipient actions include suppress, pause, retry, or review. Sender actions include throttling, fixing authentication, correcting rejected content or message format, investigating list sources, or contacting the receiver through its support channel.
A daily email bounce management workflow
Flowchart showing a daily email bounce classification workflow for SMTP codes, receiver checks, and suppression decisions.
The safest workflow is repeatable and reviewable. The system should make obvious decisions automatically, quarantine ambiguous cases, and give the deliverability owner enough evidence to tune rules without guessing.
- Parse first: Capture SMTP code, enhanced code, NDR or raw reply, receiver family, campaign, IP, domain, and message stream.
- Classify reason: Map the event to invalid user, invalid domain, disabled mailbox, mailbox full, transient, rate limit, policy, or unknown.
- Pick scope: Decide if the action belongs to the recipient, sending IP, domain, campaign stream, or receiver grouping.
- Apply window: Use distinct recipient bounce days within a rolling window, actual queue expiry for pending retries, and immediate suppression for confirmed permanent recipient failures.
- Review drift: Sample raw replies each week so provider-specific text changes do not silently break your rules.
Testing matters because bounce handling is downstream of delivery setup. When DNS, sender identity, content templates, or routing changes, send a real test and inspect headers, authentication, and visible failures before blaming the list. That does not replace production bounce logs, but it catches obvious configuration problems early.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For daily campaigns, split temporary holds by mail stream, but apply confirmed invalid-address suppression across transactional and marketing sends. A marketing unsubscribe is a separate status from an invalid address. If essential account mail cannot be delivered, request a corrected address through an authenticated account flow or another established channel rather than bypassing an invalid-address suppression.
Example daily sender suppression policytext
confirmed_invalid_user: suppress across all streams immediately confirmed_invalid_domain: suppress across all streams immediately confirmed_permanently_closed_mailbox: suppress across all streams immediately temporarily_disabled_mailbox: pause new campaigns, allow configured 4xx retries mailbox_full_4xx: allow configured retries; pause after 7 bounce days within 14 days mailbox_full_5xx: stop this message, hold new campaigns and review mailbox_full_unresolved: keep routine sends suppressed at 10-14 elapsed days after first failure transient_recipient_failure: pause after 3-5 bounce days within 7 days rate_limit: throttle stream, do not suppress recipient as invalid policy_or_auth_failure: fix sender issue, do not suppress recipient as invalid unknown_response: hold new campaigns and review raw replies
Views from the trenches
Best practices
Count one bounce day per recipient so high sending frequency does not overstate failures.
Separate disabled mailboxes, rate limits, policy blocks, and invalid users before suppression.
Reset active counters after accepted delivery, while retaining older failures for review.
Common pitfalls
Treating every 5.x response as permanent can suppress valid users during policy blocks.
Substring matching turns similar codes into wrong actions, especially in 5.7.x failures.
Removing mailbox full immediately is too strict for subscribers who receive daily mail.
Expert tips
Review bounce reasons by receiver family before changing thresholds across all streams.
Quarantine unknown replies first, then promote only verified patterns into automation.
Audit old rule maps quarterly because receiver messages and provider behavior change.
Marketer view
Marketer from Email Geeks says classification decides the next action because failed mail can mean invalid user, temporary limits, or a sender-side policy problem.
2026-02-14 - Email Geeks
Marketer view
Marketer from Email Geeks says a mailbox that stays full for 10 days in a daily program often looks abandoned, but immediate removal is too strict.
2026-02-16 - Email Geeks
