Should I resend emails to users with soft bounces due to full mailboxes, and what bounce rate is acceptable?
Published 17 May 2025
Updated 5 Oct 2026
13 min read
Summarize with
Updated on 5 Oct 2026: We clarified full-mailbox retry timing, consecutive-failure suppression, and how to interpret bounce rates.
Yes, let the sending platform retry a temporary full-mailbox response within its configured retry window. A full mailbox can produce a temporary 4xx response or a permanent 5xx response, so the SMTP class and diagnostic text control what happens next. Let automatic retries finish before considering a new send, pause repeated over-quota addresses, and stop retrying the current message after a permanent response.
A 0.1% bounce rate for one mailbox provider, such as Gmail, is low when calculated against messages attempted to that provider. For permission-based marketing, use under 1% total bounces as an internal target, review 1-2%, and investigate anything over 2%. These are operating targets, not universal acceptance limits. Suppress confirmed invalid addresses promptly; permanent policy rejections require diagnosis because the address can still be valid. Full-mailbox bounces matter most when they trend upward, cluster by provider, or appear alongside lower engagement and higher complaints.
Keep an address eligible after one isolated temporary full-mailbox bounce. Apply a timed pause when failures repeat, then base future sending on verified engagement, bounce history, and the SMTP response class.
When to resend full-mailbox soft bounces
Keep the contact eligible if the SMTP response is temporary and the contact is engaged, especially when failures are concentrated in a short period. Pause future sends after a permanent full-mailbox response, or when the same address keeps returning temporary full-mailbox errors across campaigns over several weeks without a successful delivery.
- Let the sending platform retry temporary full-mailbox failures within its configured window. Consider eligibility for later campaigns separately, using recent verified engagement.
- Pause after repeated temporary full-mailbox bounces across separate campaigns. Count each final recipient-message failure once, excluding the queue retries for that message.
- Avoid a reminder campaign whose only purpose is to test whether a full mailbox has room again. Use the next relevant campaign or a recipient-requested message to check recovery.
- Track full-mailbox bounces by provider, response class, source, signup age, and last engagement. A raw bounce count misses the timing and cause that matter.
Suggested total bounce rate targets
Illustrative internal review targets for permission-based marketing, not published mailbox-provider limits.
Target
Under 1%
Review the bounce mix even when the total is low
Review
1-2%
Segment by provider and bounce reason
Investigate
Over 2%
Check list quality and the actual failure codes
Those thresholds are operating benchmarks, not mailbox-provider limits. A password reset program, a legal notice, and a discount newsletter carry different delivery risks. For more context on bounce rate thresholds, the important part is trend and mix: hard bounces, soft bounces, complaints, clicks, replies, and provider concentration.
How full-mailbox responses work
The enhanced status family X.2.2 means the mailbox is full. The leading class changes the instruction: 4.2.2 is a temporary failure that the sending system can retry, while 5.2.2 is a permanent failure for that delivery. Providers can add their own diagnostic text, so store the complete response rather than only the label "soft bounce."
IANA's status registry defines X.2.2 as a mailbox storage-quota condition with transient-failure semantics. In practice, Gmail's SMTP documentation lists 452 4.2.2 for an out-of-space inbox and 552 5.2.2 for an out-of-space, inactive inbox. Follow the actual SMTP class instead of assuming every mailbox-full error is retryable.
|
|
|
|---|---|---|
Temporary full mailbox | 4.2.2 | Retry automatically; pause only if failures persist |
Permanent over quota | 5.2.2 | Stop this delivery; hold future sends until recovery is confirmed |
Invalid address | 5.1.1, recipient does not exist | Suppress the invalid address |
Blocked | Policy or reputation rejection; the address can still be valid | Investigate the rejection before changing recipient eligibility |
Spam complaint | Recipient feedback, not an SMTP bounce | Suppress marketing regardless of later mailbox recovery |
Delivery failures and complaints require different handling.
The nuance is time. Several retry attempts for one message in one day can describe one storage problem. Full-mailbox failures across separate campaigns over several weeks, without a successful delivery between them, are stronger evidence of a persistent problem. A count-only suppression rule misses both the time window and recovery.
Do not mix temporary and permanent responses in the same suppression rule. A 4xx response asks the sender to retry later. A 5xx response says not to retry that message without correcting the cause or receiving new evidence that the mailbox is usable.
Read the SMTP response before resending
A dashboard category such as "soft bounce" is only a summary. Save the SMTP reply class, enhanced status code, diagnostic text, and recipient provider for each failed delivery. Those fields show whether to retry the message, slow the affected stream, repair authentication, or suppress the address.
- For 4.2.2, let the mail transfer system retry with backoff. Count a final recipient-message failure once after the retry window ends.
- For 5.2.2, stop automatic retries for that message and pause future marketing until there is evidence that the mailbox can receive mail again. Purchase history alone does not establish storage recovery.
- For 4.7.x, inspect the full diagnostic. These are security or policy responses, including some rate limits, and require a different investigation from mailbox storage errors.
- Review unknown responses before changing list policy. A generic bounce label should not override the actual SMTP class.
One recipient message can have several SMTP delivery attempts. Deduplicate by message and recipient when calculating bounce rate or applying a pause rule; retries that eventually succeed are not final bounces.
How long to wait before resending
There is no single wait time for every sending platform. RFC 5321 recommends retry intervals generally at least 30 minutes and a give-up time generally at least four to five days for standard SMTP delivery. Sending platforms use configured retry windows that can be shorter, so check the actual queue lifetime and retry schedule.
While a message is deferred or queued, let automatic retries finish. A manual resend creates a new message that can arrive alongside the original if the mailbox recovers. After a final temporary failure, leave recurring marketing to the next scheduled campaign unless the recipient requests a specific, still-relevant resend.
For time-sensitive transactional email, set a delivery lifetime that matches the message. Stop retrying an expired password-reset link or an offer after its deadline. Provide an account recovery path or use an already verified alternate contact channel when needed.
When to retry and when to pause
Full-mailbox soft bounce decision flow for retries, timed pauses, and resumed sending.
A resend policy should separate automatic mail transfer retries from marketing sends. Check how your sending platform handles temporary failures and when it reports a final bounce. The decision you control is whether the subscriber stays eligible for the next campaign after the platform gives up on that delivery.
Keep eligible
- The user clicked, replied, purchased, or used the account recently, so the contact still has value. Verify that marketing permission remains active.
- Failures cluster within one campaign or a short delivery period, and the existing retry queue is still running.
- Provider bounce rate remains low and other health metrics are stable.
Pause or suppress
- Temporary full-mailbox failures recur across separate sends over several weeks without a successful delivery between them.
- The contact has no verified engagement within your sunset-policy window, or the mailbox returns a permanent full-mailbox response.
- Provider-wide complaints or policy blocks require investigation before changing individual recipient suppression.
One example internal rule keeps the address eligible after isolated 4.2.2 failures, then pauses after three consecutive final failures across separate campaigns within 60 days. Adapt the illustrative 30-90-day pause to engagement and sending frequency. Reset the consecutive counter after successful delivery, retaining bounce history and clearing only the temporary mailbox-full pause. Mailbox recovery does not override an unsubscribe or complaint. Persistent failures and inactivity support your marketing sunset policy.
A soft bounce suppression rule should store the SMTP class, bounce reason, provider, campaign date, last successful delivery, and last positive action. Without those fields, the rule can punish recent buyers while retaining stale addresses.
A practical suppression policy
For recurring marketing mail, use a staged policy that removes chronic temporary failures from the main audience. The example below is an internal policy to adapt to sending frequency and platform rules. Apply it to final recipient-message outcomes after automatic retries finish.
Example full mailbox suppression logictext
Honor unsubscribes, complaints, and invalid-address suppression first. if delivery_succeeds_for_this_recipient: reset full-mailbox streak; retain history clear only the temporary mailbox-full pause if final_smtp_status == "4.2.2": increment streak once per recipient message window_count = consecutive failures within 60 days missing engagement = inactive if streak >= 5 and no engagement for 12 months: suppress from marketing elif window_count >= 3 and last engagement <= 90 days: pause for 30 days elif window_count >= 3: pause for 90 days elif streak == 2 and last engagement > 90 days: pause for 30 days else: keep eligible if final_smtp_status == "5.2.2": stop retrying the current message hold future marketing until recovery evidence
- Keep the contact eligible after the first final temporary bounce. Avoid a special reminder email.
- After the second consecutive final failure, this example pauses contacts inactive for more than 90 days for 30 days.
- After three consecutive final failures within 60 days, pause recently engaged contacts for 30 days or inactive contacts for 90 days.
- After the pause, use the next relevant campaign to check recovery, honoring consent and existing suppression.
- This example suppresses marketing after five consecutive final failures and 12 months without engagement. Invalid addresses, unsubscribes, and complaints follow their own immediate suppression rules.
Sending frequency changes the tolerance. If you send four times a week, three final full-mailbox failures can happen quickly and still describe one temporary storage problem. If you send monthly, three consecutive failures span roughly two months between the first and third failures. Extend the history window when needed to capture persistent failures in a lower-frequency program.
A useful rule includes response class, consecutive failures, elapsed time, successful delivery, and provider diagnostic. A count-only rule is too blunt for high-frequency senders and too lenient for low-frequency senders.
What bounce rate is acceptable
A 0.1% full-mailbox bounce rate is low when measured against attempts to that provider. One bounce among 1,000 attempts and 100 among 100,000 both equal 0.1%; assess the count and trend alongside complaints and verified engagement.
Bounce and acceptance rate formulastext
final bounce rate = final bounced recipient messages / attempted recipient messages x 100 SMTP acceptance rate = SMTP-accepted recipient messages / attempted recipient messages x 100 Deduplicate retries by message and recipient; report pending mail separately. acceptance rate = 100% - bounce rate only if accepted and bounced are mutually exclusive and cover every attempted message. Pending mail and bounces after acceptance break this shortcut.
Use the same attempted-message denominator and reporting window, excluding pre-send suppression. Provider rates use only that provider's attempts. Final bounce counts include delayed notifications after acceptance. Acceptance does not measure inbox placement: an accepted message can land in spam.
|
|
|
|
|---|---|---|---|
Total bounce | Internal target: under 1% | 1-2% or above baseline | Investigate over 2% |
Invalid-address hard bounce | Near zero | Any confirmed invalid address | Suppress immediately |
Full mailbox | Isolated temporary failures | Consecutive final failures | Retry 4.2.2; stop retries on 5.2.2 |
One provider | Stable against provider baseline | Sudden increase | Inspect diagnostics |
Suggested internal targets and cause-specific review triggers, not universal provider limits.
Spam-complaint rate is a separate metric. Google's sender guidelines recommend keeping the reported spam rate below 0.10% and avoiding 0.30% or higher. These are complaint thresholds. A 0.1% bounce rate does not establish compliance.
The mix matters more than the headline number. A 1.5% bounce rate made mostly of temporary full-mailbox bounces on an older but engaged list is different from a 1.5% hard-bounce rate on a new acquisition source. The second case points to list quality problems.
For full mailbox recovery, the recovery rate depends heavily on provider storage rules and user activity. Some users clear space quickly because the mailbox is active. Others let the mailbox sit full for months. Your own historical data is the best guide.
What to check before changing the policy
Before tightening suppression, check whether the trend is truly about mailbox storage. A provider-specific increase can also come from authentication failures, content filtering, rate limits, message size, or reputation problems. Full-mailbox wording is usually clear, but bounce classification is not always accurate.
- Compare Gmail, Yahoo, Microsoft, Apple, and business domains separately, using each provider's attempted-message denominator.
- Separate mailbox full, temporary deferral, rate limit, policy block, and invalid-address failure codes. Message-size rejections require a smaller message, not a full-mailbox suppression rule.
- Compare recent clickers, repliers, purchasers, and account users with people who have not acted for a year. Use verified actions rather than open tracking alone.
- Review signup source, list age, lead source, and import batch. Check address-entry errors and use confirmed opt-in where appropriate; ask users to correct their addresses.
If one provider starts returning rate-limit or generic deferral responses, reduce volume for that stream until SMTP errors fall, then increase it gradually. A timed full-mailbox suppression rule will not fix provider throttling.
Send a real message to Suped's email tester after template or infrastructure changes to check authentication and headers. Use the failed message's actual SMTP diagnostic to establish whether content, message size, or recipient storage caused the rejection.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If SMTP diagnostics identify an authentication rejection, repair the affected sender's configuration. Suped's domain health check checks published DMARC, SPF, and DKIM records. Verify the authentication result on a real message as well, then use Suped's DMARC monitoring to review source-level authentication results over time. These checks do not resolve a confirmed full-mailbox error.
Also check reputation. A sudden policy block is not the same as an over-quota mailbox. Suped's blocklist monitoring tracks IP and domain blocklist (blacklist) listings. Compare any listing with the SMTP diagnostic and timing before attributing a rejection to reputation.
Investigating authentication issues with Suped
Suped is our DMARC and email authentication platform. Bounce handling remains in the sending platform, while Suped helps teams check whether a bounce spike coincides with DMARC, SPF, or DKIM failures. Suped also provides hosted authentication records, alerts, and blocklist monitoring for this investigation.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
The workflow is straightforward: identify the bounce spike in the sending platform, then use Suped to confirm whether the domain still authenticates cleanly, whether a new sender fails DKIM, whether SPF lookup limits are involved, and whether a blocklist or blacklist event appeared at the same time.
Sending-platform data
- Shows failed deliveries, SMTP responses, and bounce categories.
- Controls retries, timed pauses, and recipient suppression.
- Provides the recipient-level evidence needed to confirm mailbox-full failures.
Suped authentication data
- Shows source-level DMARC, SPF, and DKIM results, with authentication records and alerts.
- Identifies authentication gaps that need correction.
- Adds authentication evidence to the bounce investigation; confirm the recipient's failure reason in sending-platform logs.
The cause determines the fix. Tighten a poor acquisition source when the spike consists of invalid addresses. Repair authentication when diagnostics show that a legitimate sender fails authentication. Apply timed suppression when the responses are temporary full-mailbox failures. Source-level authentication results do not establish whether an individual mailbox has storage available.
Views from the trenches
Best practices
Count final recipient-message failures across time; reset the streak after successful delivery.
Segment mailbox full bounces by provider, signup source, list age, and recent engagement.
Pause chronic soft bounces, then let normal campaigns test mailbox recovery later.
Common pitfalls
Counting retries as separate bounces inflates failures and pauses contacts before recovery.
Sending a special reminder to full mailboxes adds risk without clear delivery value.
Judging bounce rate alone misses complaint, engagement, provider, and trend context.
Expert tips
Compare a 0.1% provider bounce rate with its baseline, sample size, and verified engagement.
High send frequency needs shorter review windows and stronger fatigue checks per domain.
Use a sunset rule for stale contacts, then layer full-mailbox behavior on top of it.
Marketer view
Marketer from Email Geeks says full-mailbox recipients can return, and repeated mailing has not always caused visible negative impact in their programs.
2024-01-26 - Email Geeks
Marketer view
Marketer from Email Geeks says the time between bounces matters more than the raw count because three bounces in one day and three bounces over months mean different things.
2024-01-26 - Email Geeks
