Incident: Soft Bounces

What Is a Soft Bounce?

A soft bounce is a temporary delivery failure indicated by a 4xx SMTP response code. The receiving server is telling your sending server: “I can’t accept this message right now, but you can try again later.”

The distinction from hard bounces (5xx permanent failures) is critical:

• Soft bounce (4xx): Temporary. Your MTA should retry automatically.
• Hard bounce (5xx): Permanent. Suppress the address immediately.

However, soft bounces that persist across multiple retries or multiple campaigns can indicate deeper problems that require action.

Categories of Soft Bounces

Mailbox Full (452 4.2.2)

The recipient’s mailbox has reached its storage quota.

What it means: The address is valid, but the recipient has stopped managing their inbox. This could be a sign of an abandoned account.

Action thresholds:

• First occurrence: Retry as normal
• 2 consecutive campaigns: Flag for monitoring
• 3+ consecutive campaigns: Suppress — this mailbox is functionally abandoned and may eventually become a recycled spam trap

Rate Limiting / Throttling (421 4.7.0)

The receiving server is temporarily refusing connections because you’re sending too fast or sending too much.

What it means: You’ve exceeded the receiving server’s acceptable rate for your IP or domain. This is the provider’s way of saying “slow down.”

Common causes:

• Sending too many messages per connection
• Sending too many messages per minute/hour to one provider
• Sudden volume increase from an IP that usually sends less
• Shared IP where another sender is consuming the rate budget

Action:

• Reduce sending speed to the affected provider
• Implement per-provider throttling in your MTA configuration
• If on a shared IP, contact your ESP about the rate limit
• Spread sending across a longer time window

Temporary System Failure (451 4.3.0)

The receiving server is experiencing an internal issue.

What it means: This is the receiving server’s problem, not yours. Their system is temporarily overloaded, undergoing maintenance, or experiencing an error.

Action:

• Retry automatically (your MTA should handle this)
• Monitor — if the issue persists across multiple hours of retries, the address may be unreachable
• Don’t suppress based on temporary server errors — this is almost always resolved by the retry mechanism

Greylisting (451 4.7.1)

Some receiving servers deliberately reject the first delivery attempt from an unknown sender and expect a retry. Legitimate mail servers retry; spam bots typically don’t.

What it means: The receiving server is using greylisting as a spam filtering technique. Your message will be accepted on the retry.

Action:

• Ensure your MTA retries after the initial rejection
• Standard retry interval (15-30 minutes) is usually sufficient
• First-time deferrals from a new recipient domain often indicate greylisting

DNS/Routing Failures (451 4.4.4)

The sending server couldn’t resolve the recipient domain’s MX records, or the resolved servers were unreachable.

What it means: DNS issue — either the recipient’s domain has a misconfigured MX record, or there’s a temporary DNS resolution problem.

Action:

• Retry (DNS issues are often transient)
• If persistent for a specific domain, the recipient’s DNS may be broken — not your problem to fix, but the address should be suppressed after extended failure

Content/Policy Deferral (421 4.7.0 with policy language)

The receiving server suspects the message might be spam but isn’t certain enough to reject permanently.

What it means: Your message triggered a policy check that resulted in a deferral rather than a rejection. This is a softer form of reputation-based filtering.

Action:

• Monitor the volume of these deferrals
• If they increase, investigate reputation signals (complaint rate, authentication, blocklists)
• A high deferral rate from one provider is a leading indicator of future hard blocks from that provider

The Soft Bounce Decision Framework

Not all soft bounces require the same response. Use this framework:

Immediate Retry (Default MTA Behavior)

Most soft bounces should be retried automatically by your sending infrastructure:

• Retry interval: Start at 15 minutes, increase exponentially (15min → 30min → 1hr → 2hr → 4hr)
• Maximum retry period: 24–72 hours depending on your MTA configuration
• Maximum retry attempts: Most MTAs default to 10–20 retries over the retry period

Campaign-Level Tracking

Track soft bounces at the campaign level to identify patterns:

Address-Level Tracking

Track soft bounces per address across campaigns:

The specific thresholds depend on your sending frequency. If you send daily, 4 consecutive bounces is 4 days. If you send monthly, 4 consecutive bounces is 4 months — a much more significant signal.

Soft Bounces vs. Deferrals

There’s a subtle but important distinction between soft bounces and deferrals:

Soft bounce: The receiving server accepted the connection and responded with a 4xx code during the SMTP transaction. Your MTA has the response code and diagnostic message.

Deferral: The receiving server deferred the message before completing the SMTP transaction — either by refusing the connection, timing out, or issuing a 421 early in the dialogue. The diagnostic information may be less detailed.

Both are temporary, but deferrals at the connection level often indicate IP-level reputation issues, while soft bounces at the DATA level often indicate content or per-message policy issues.

Provider-Specific Soft Bounce Patterns

Gmail

Gmail’s approach to soft bouncing:

• Frequent use of 421 4.7.0 for rate limiting and reputation-based deferrals
• Detailed diagnostic messages that include the reason for deferral
• Generally resolves within a few hours if the issue is temporary
• Persistent deferrals (24+ hours) indicate reputation problems requiring investigation

Microsoft

Microsoft’s patterns:

• Uses 421 4.7.0 with reference codes (e.g., TS03) for different categories of deferral
• More aggressive throttling for new or low-reputation IPs
• May defer for 24+ hours during reputation evaluation
• SNDS data helps correlate deferrals with reputation metrics

Yahoo

Yahoo’s characteristics:

• Very aggressive rate limiting — lower per-IP thresholds than Gmail or Microsoft
• 421 responses often include “temporarily deferred” with complaint or volume language
• Requires careful per-provider throttling to avoid sustained deferrals
• Tends to defer before blocking — persistent soft bounces at Yahoo often precede hard blocks

Monitoring Soft Bounces Operationally

Dashboard Metrics to Track

• Soft bounce rate per campaign (total soft bounces / total sends)
• Soft bounce rate per provider (group by receiving domain)
• Deferral queue size (how many messages are waiting to retry)
• Average retry count before delivery (how many attempts before success)
• Retry exhaustion rate (percentage of soft bounces that never deliver after all retries)

Alert Thresholds

Set alerts at these levels:

• Soft bounce rate > 5% for any single campaign → Investigate
• Deferral queue growing for > 4 hours → Check for provider-specific issues
• Retry exhaustion rate > 2% → Review retry policy and address quality
• Provider-specific soft bounce rate > 10% → Stop sending to that provider, investigate

Investigation Checklist

When soft bounce rates spike:

1. Which provider? Group bounces by receiving domain
2. Which error code? Categorize by SMTP response
3. What changed? Compare to previous campaign metrics
4. IP or domain? Determine if the issue is IP-specific or domain-specific
5. Volume change? Did you send significantly more than usual?
6. Authentication? Did DNS records change or did DKIM signing break?
7. Content? Is the content significantly different from recent campaigns?
8. External factors? Check blocklists, Postmaster Tools, SNDS

Soft bounces are the system telling you something isn’t right — but it’s a warning, not a death sentence. The senders who handle soft bounces well are the ones who suppress persistent failures, respect provider throttling, and use the diagnostic data to improve their practices before soft bounces become hard blocks.