Soft Bounces That Become Hard Bounces: Time Thresholds and Suppression Logic

• May 2022
• Engineering Memo · External Release

The distinction between soft bounces (temporary delivery failures that should be retried) and hard bounces (permanent delivery failures that should suppress the address) is foundational to list quality management. What is less commonly discussed is that soft bounces do not remain soft indefinitely — a 4xx deferral that persists across multiple campaigns and weeks of retry attempts eventually indicates an address that will not be successfully delivered to, which functionally makes it a hard bounce regardless of the SMTP response code. The suppression logic that only classifies 5xx responses as hard bounces, while treating all 4xx responses as indefinitely-retriable soft bounces, produces a list that accumulates undeliverable addresses and generates ongoing bounce rate pressure without the clarity that would produce suppression.

This note documents the time thresholds and campaign persistence conditions that should trigger reclassification of soft bounces as effective hard bounces, the specific soft bounce types that have different reclassification timelines, and the suppression logic that implements these thresholds correctly in the list management system.

Why Soft Bounces Accumulate Without Reclassification

PowerMTA retries soft-bounced messages within the queue-life setting — typically 3-5 days for promotional email. If the message delivers within the queue-life, the bounce is resolved. If it does not deliver within the queue-life, the message expires and the delivery attempt is recorded as a failure. But the sending application's suppression logic may still keep the address active for the next campaign, because the address only failed with a 4xx response, not a 5xx.

The result: the next campaign injects a message to the same address that failed in the previous campaign. If the address is a genuinely temporary deferral (mailbox full that the user cleared, server temporarily unavailable), the next campaign delivers successfully. If the address is a permanently abandoned mailbox (the user stopped checking the account years ago and the ISP is responding with 452 "mailbox full" because it is over quota and never cleared), the next campaign generates the same 452 deferral. After 3 campaigns generating 452, the address has generated 3 consecutive soft bounces — it is functionally undeliverable — but the suppression logic has not suppressed it because no 5xx code was ever returned.

Over time, a list that lacks soft-bounce reclassification accumulates a growing proportion of these functionally undeliverable addresses. They generate constant deferral rate pressure, accumulate retry load in the queue, and contribute to the bounce rate metrics that ISPs monitor as list quality signals. The list's technical bounce rate may show mostly 4xx codes (which appear benign) while the list quality problem is real and accumulating.

The Reclassification Thresholds by Bounce Type

Over-quota bounces (452 / 552 mailbox full): The most common soft bounce that becomes a hard bounce over time. An over-quota mailbox may be a temporary state (the user is on holiday and hasn't cleared their inbox) or a permanent state (the account is abandoned). Reclassification threshold: 3 consecutive campaigns generating quota bounces, or 90 days of consistent quota bounce. After 3 campaigns, the probability that the mailbox is genuinely abandoned is high enough to justify suppression. The cost of false positive suppression (suppressing a valid address that was temporarily full) is lower than the cost of continuing to send to genuinely abandoned addresses.

Temporary unavailable bounces (450 mailbox unavailable): Indicates the recipient's MX server is temporarily unreachable or the mailbox is temporarily unavailable. Reclassification threshold: 5 consecutive campaigns, or 120 days. A server that is unavailable for 5 consecutive monthly campaigns (approximately 5 months) is likely permanently decommissioned or the domain has expired. The longer threshold reflects that legitimate server outages (hosting provider issues, domain migrations) can extend beyond 90 days in some cases.

Greylisting deferrals (451 try again): Greylisting should self-clear on retry and should not generate consecutive soft bounces in the accounting log. If a 451 greylisting response persists across multiple retry attempts within a single campaign's queue-life (3-5 days of retries, not clearing), it may indicate a deeper problem — the destination server consistently rejecting the IP, which is closer to a policy block than genuine greylisting. Reclassification threshold: not applicable for standard greylisting (which clears on retry); investigate persistent 451 responses that do not clear within 48 hours.

ISP policy throttle (421 try later): Rate-limit responses should not trigger reclassification — they indicate ISP-level throttle rather than address-specific delivery problems. 421 responses should not accumulate on individual addresses; they are ISP-wide signals that affect all recipients at the throttled ISP simultaneously.

Soft bounce reclassification is the list management discipline that prevents the silent accumulation of functionally undeliverable addresses that generate ongoing delivery friction. It does not require new infrastructure — only consistent tracking of per-address bounce history across campaigns, and suppression logic that acts on the reclassification thresholds defined in this note. The sending application's database is the natural home for this tracking: a per-address bounce_count field incremented for each consecutive soft bounce campaign, with a suppression trigger when the count reaches the threshold. This simple implementation keeps the list quality aligned with the actual deliverability of each address in it — which is the fundamental goal of all list management practices.

Implementing Consecutive Bounce Tracking

Per-address consecutive soft bounce tracking requires three database fields in the contact/subscriber table: soft_bounce_count (integer, incremented after each campaign where the address generates a soft bounce), last_soft_bounce_date (the date of the most recent soft bounce), and last_successful_delivery (the date of the most recent successful delivery). These three fields together provide the data needed to implement the reclassification thresholds.

The reclassification logic: after each campaign's delivery is complete, query the accounting log for all addresses that generated a soft bounce in the campaign and did not deliver successfully (even on retry) within the queue-life period. For each such address, increment soft_bounce_count and update last_soft_bounce_date. For addresses that delivered successfully in the campaign, reset soft_bounce_count to zero and update last_successful_delivery. Finally, apply the suppression trigger: any address where soft_bounce_count exceeds the threshold for its bounce type (3 for quota bounces, 5 for mailbox-unavailable bounces) is moved to the suppression list with the reason "soft_bounce_threshold."

The reset condition — successful delivery resets the consecutive bounce count — is important for addresses that genuinely recover. An over-quota mailbox that the user eventually clears will deliver successfully when re-sent, resetting the counter and avoiding suppression. Only addresses that fail consecutively across multiple campaigns without any intervening successful delivery trigger the suppression threshold. This reset condition ensures that the reclassification logic correctly distinguishes genuinely temporary failures (which recover) from permanently undeliverable addresses (which never recover).

The 90-Day Time-Based Threshold

For programmes with infrequent send cadences (quarterly campaigns rather than monthly), campaign-count thresholds may trigger suppression too slowly. A programme that sends only 4 times per year requires 9 months (3 quarterly campaigns) to trigger the 3-consecutive-bounce threshold for quota bounces. An address that has been over quota for 9 months is certainly abandoned; waiting that long to suppress it generates ongoing bounce rate pressure that could have been resolved much earlier.

The time-based threshold supplements the campaign-count threshold: suppress any address where last_successful_delivery is more than 90 days ago AND soft_bounce_count is greater than zero. This threshold catches addresses that would pass the campaign-count threshold check (fewer than 3 consecutive soft bounces) but have not delivered successfully in 90 days — which indicates functional non-deliverability regardless of the bounce count.

Combining the campaign-count threshold with the 90-day time threshold gives soft-bounce reclassification two-axis coverage: the campaign-count threshold catches addresses that bounce in consecutive high-frequency campaigns, and the 90-day threshold catches addresses that bounce in infrequent campaigns with long gaps between sends. Together they ensure that functionally undeliverable addresses are suppressed within a reasonable timeframe regardless of the programme's sending frequency.

Re-Engagement Before Suppression

Before applying the soft-bounce suppression threshold, some programmes run a re-engagement pass — a single send specifically to the accumulated soft-bounce addresses that have not yet crossed the suppression threshold, with a simple "Is this email address still valid?" message that prompts recipients to confirm their address. Addresses that deliver successfully on the re-engagement pass (or that generate a positive engagement event — click, confirmation) are removed from the suppression candidate list and continue to receive the programme's normal campaigns. Addresses that generate another soft bounce on the re-engagement pass cross the threshold and are suppressed.

The re-engagement pass strategy delays suppression by one additional campaign but reduces false positive suppressions (valid addresses that were temporarily bouncing). For programmes with high-value individual contacts (B2B lists where each contact may represent significant commercial opportunity), the additional re-engagement pass before suppression is worth the delay. For high-volume consumer lists where the cost of individual false positive suppressions is low relative to the list management overhead of the re-engagement process, applying the threshold directly is more efficient.

Soft bounce management — tracking, reclassification, and suppression — is one of the list quality practices that directly affects ISP reputation signals. Every soft bounce that generates a retry attempt represents real SMTP traffic to an ISP that may eventually be classified as delivering to an invalid or abandoned address. ISPs that observe high rates of extended retry sequences to non-delivering addresses treat this as a list quality signal. Implementing correct soft-bounce reclassification thresholds reduces this retry noise, improves measured bounce rates in ISP reputation systems, and keeps the active sending list aligned with the addresses that are genuinely reachable — which is the foundation of list quality that all reputation management depends on.

The List Quality Compound Effect

Soft bounce reclassification is one component of the list quality management system that prevents list quality from degrading over time. Without it, lists accumulate invalid addresses at the rate that contacts become undeliverable — through job changes (B2B addresses), account abandonment (consumer addresses), domain expiry, and mailbox deprovisioning. The rate of address decay varies by list type: B2B contact lists may lose 20-30% of their valid addresses per year due to job changes and company restructuring; consumer lists may lose 10-15% per year to account abandonment.

Without proactive reclassification and suppression, the percentage of undeliverable addresses in the active list grows monotonically. A list that was 98% deliverable at acquisition becomes 85% deliverable after 1 year, 70% deliverable after 2 years, without any list quality management interventions. The bounce rates, deferral rates, and ISP complaint signals all worsen proportionally. With consistent soft-bounce reclassification (combined with hard-bounce suppression, engagement-based retirement, and annual re-validation), the list's deliverability percentage can be maintained above 95% indefinitely — the quality management interventions offset the natural decay rate.

The compound effect of list quality management is visible in the reputation trend data: programmes that maintain consistent list hygiene practices show stable or improving domain reputation over time; programmes that allow list quality to decay show gradually worsening reputation trends that become increasingly expensive to reverse. Soft bounce reclassification, implemented correctly and applied consistently, is one of the core list hygiene practices that maintains the list quality on which all reputation management depends. It requires a small ongoing investment in data tracking and suppression logic that produces indefinitely sustained list quality — which is the operational foundation of indefinitely sustained deliverability performance.

A list is not a static asset — it is a living population of contact points, each with its own deliverability trajectory. Active management of that population — suppressing addresses that are no longer reachable, retiring addresses that are no longer engaged, and validating new additions before they enter the active list — is the discipline that keeps the list's deliverability profile strong enough to maintain the ISP reputation that inbox placement requires. Soft bounce reclassification is the piece of that management system that catches the addresses falling out of the addressable category without a hard bounce — the slow degradation that compound into a significant quality problem if left unaddressed. Implement it, apply the thresholds consistently, and the list will remain as deliverable as its acquisition quality allows.

Soft Bounce Reclassification in MailWizz

MailWizz includes built-in bounce handling that classifies bounces from PowerMTA's FBL and bounce processing pipelines. The default MailWizz configuration processes hard bounces (5xx codes) as immediate suppressions and soft bounces (4xx codes) as deferral records without triggering suppression. The consecutive soft bounce reclassification logic described in this note must be added as a custom extension to MailWizz's subscriber management, or implemented in the ETL pipeline that processes PowerMTA's accounting log data.

The implementation approach that works cleanly with MailWizz's existing architecture: add the soft_bounce_count and last_soft_bounce_date fields to MailWizz's subscriber table via a database migration. Create a post-campaign processing script that queries the PowerMTA accounting log for the completed campaign's soft bounce outcomes, updates these fields in the subscriber table for affected addresses, and applies the suppression logic for addresses that have crossed the reclassification threshold. Run this script as a scheduled job (via cron or a MailWizz extension) after each campaign's queue-life period has elapsed and all retries are complete.

The queue-life awareness is important: the script should only run after the campaign's full queue-life period (3-5 days for promotional campaigns) has elapsed, so that messages still in retry are not counted as final soft bounces before all retry attempts have completed. A message that is deferred on day 1 and retried successfully on day 3 should not trigger the soft bounce counter — it delivered successfully, just with a delay. Only messages that exhaust their queue-life without delivery (final status: expired or failed) should increment the soft bounce counter.

PowerMTA's accounting log distinguishes between active deferrals (messages in the retry queue) and final delivery failures (messages that have expired from the queue without delivering). Filtering the accounting log for the type=delivered and type=failed fields (rather than all deferral events) selects only the final outcome for each message, avoiding false positive soft bounce counts from messages that eventually delivered after initial deferral.

Reporting Soft Bounce Reclassification to Stakeholders

Soft bounce reclassification generates suppressions that reduce the active list size without any corresponding opt-out or hard bounce event that stakeholders might expect. Marketing teams reviewing subscriber counts may notice unexplained decreases after reclassification runs. Documentation of the reclassification logic — what it does, when it runs, what threshold it applies — prevents confusion and ensures that stakeholders understand that list size reductions from reclassification reflect list quality improvement rather than deliverability problems.

The monthly list quality report that communicates reclassification outcomes: the number of addresses reclassified as effective hard bounces in the current month (segmented by bounce type — quota vs unavailable), the total cumulative reclassified address count, and the active list size trend showing that the reclassification is maintaining list quality rather than depleting it. This reporting converts the technical list management operation into a business-level quality narrative that stakeholders can understand and evaluate.

Soft bounce reclassification, like most list quality management practices, is most valuable when it is invisible: the list stays clean, bounce rates stay low, ISP reputation stays high, and campaigns deliver efficiently to the addresses that are actually reachable. The investment in implementing and running the reclassification logic correctly is the operational discipline that keeps the list in the state where this invisible quality maintenance is possible. Implement it once, run it consistently, report it clearly, and it becomes part of the ongoing operational infrastructure that makes every subsequent campaign perform at the quality level the programme's acquisition and engagement practices deserve.

Integration with Validation and Hygiene Practices

Soft bounce reclassification works best as part of a layered list quality management system that includes real-time validation at acquisition, hard bounce suppression, engagement-based retirement, and annual re-validation. Each element addresses a different source of list quality degradation; none is sufficient alone.

Real-time validation at acquisition prevents invalid addresses from entering the active list — it catches syntax errors, non-existent domains, and known spam traps before the first send. Hard bounce suppression removes addresses that generate immediate 5xx rejections. Engagement-based retirement removes addresses that are technically valid (they accept messages) but generate no engagement signals — inactive addresses that may eventually generate complaints. Annual re-validation catches addresses that have become invalid since they were last validated — domain expiry, account deprovisioning, and employer changes that make B2B addresses unreachable. Soft bounce reclassification catches the addresses in between: technically still accepting connections, but not successfully delivering — the grey zone between deliverable and undeliverable that neither hard bounce suppression nor validation catches.

Each element of the list quality management system addresses the addresses that the other elements miss. Together they maintain the active list in a state where the deliverable percentage stays high, the bounce rate stays low, and the ISP reputation signals remain positive. Soft bounce reclassification is the element that is most frequently missing from programmes that have implemented the other elements -- it is the less obvious practice that fills the gap between the clear cases (valid and delivering vs invalid and hard bouncing) with appropriate handling for the ambiguous middle ground. Implement all four elements consistently, and the list quality management system closes coverage of all the ways that an address can become undeliverable over time.

Soft bounces are temporary. Lists are permanent. Managing the transition correctly -- suppressing when temporary becomes permanent -- is the discipline that keeps the list's quality permanently high even as individual addresses inevitably become undeliverable over time.

Track consecutive bounces. Apply the thresholds. Suppress what is no longer deliverable. The list stays healthy; the reputation follows.

Soft bounce reclassification is list quality management at its most precise: applying the right suppression threshold to the right bounce type at the right time, so the list always reflects the programme's true addressable audience rather than an accumulation of addresses that have quietly become unreachable.