Incident: Soft Bounces

A soft bounce is a temporary failure: the receiving server says “not now, try later”. Usually your server tries again and the email gets through. This playbook shows you the common kinds, how retries work, and when a soft bounce is a warning you need to act on.

What a soft bounce is

When your server delivers an email, the receiving server answers with a reply code (a three-digit number). The first digit tells you the kind of answer:

• 4xx: soft bounce. Temporary. Your server keeps the email and retries on its own.
• 5xx: hard bounce or block. Permanent. Your server gives up. If the address doesn’t exist, remove it from your list.

You’ll also see the word deferral: one temporary refusal that your server will retry. Many tools call every deferral a soft bounce. If the retries run out, the email finally bounces.

One soft bounce is normal. Soft bounces that repeat for days, or across several campaigns, point to a deeper problem.

The kinds of soft bounce

Each kind has a typical code. The text after the code usually confirms which one you have.

Mailbox full (452 4.2.2)

The mailbox has run out of space. The address is real, but nobody is clearing it out, so it may be abandoned.

• First time: let your server retry.
• Two campaigns in a row: flag the address.
• Three or more in a row: stop sending to it. Abandoned addresses can later become spam traps (addresses used to catch senders with old lists).

Sending too fast (421 4.7.0)

The receiving server is limiting how much it accepts from you. This is called rate limiting or throttling. Common causes:

• too many emails per connection, or per hour to one provider
• a sudden jump in volume from an IP address (the number that identifies your sending server) that usually sends less
• a shared IP, where another sender uses up the allowance

Send more slowly to that provider. Set per-provider speed limits in your sending server or email service, and spread large sends over more hours. On a shared IP, ask your email service provider (ESP) about the limit.

Their server has a problem (451 4.3.0)

The receiving server is overloaded, under maintenance or broken. Let your server retry: these almost always clear on their own. Don’t remove addresses because of a server error. If it lasts for days, that domain may be unreachable.

Greylisting (451 4.7.1)

Some servers refuse the first attempt from an unknown sender on purpose. Real mail servers retry and many spam programs don’t. The retry is then accepted. Just make sure your server retries. A first-time delay at a new domain is often greylisting.

DNS or routing problems (4.4.x)

Your server couldn’t find the domain’s MX records (the DNS records naming its mail servers), or couldn’t reach those servers. Your own server usually writes this code, because no receiving server answered. Let it retry, since DNS problems are often brief. If one domain fails for days, its DNS is probably broken. Stop sending to it once the retries run out.

Reputation or content delay (421 4.7.0 with policy text)

The server suspects spam but isn’t sure enough to refuse for good, so it delays the email. Count these for each provider. If they grow, check your complaints, authentication and blocklists. Many of these from one provider often come before a full block there.

How retries work

Your server keeps a soft-bounced email in a queue (a waiting list) and tries again, waiting longer after each failure.

• The gaps often start at 15 to 30 minutes and grow: 30 minutes, 1 hour, 2 hours, 4 hours.
• The retry window is how long your server keeps trying. The email standard suggests at least four to five days. Postfix, a common mail server, gives up after 5 days by default. Many email services stop sooner.
• The result: a 250 on any retry means delivered. If the window ends, the email bounces.

You rarely need to change these settings. Do check that retries happen at all, especially if you wrote your own sending code.

When to act

Per campaign

These are rough starting points, not provider rules. Adjust them to your history.

Soft bounce rate	Status	What to do
Under 2%	Normal	Nothing
2–5%	Raised	Look for rate limiting or a provider problem
5–10%	High	Review your sending speed and reputation
Over 10%	Critical	Pause sending and find the cause

Per address

Campaigns in a row	Status	What to do
1	Normal	Send as usual
2	Watch	Flag the address
3	Warning	Send to it less often
4 or more	Suppress	Treat it as a hard bounce

How often you send matters. Four in a row is four days if you send daily, but four months if you send monthly, which is a much stronger sign.

Where the 4xx comes from

The step where the server said “later” hints at the cause. The SMTP log playbook shows each step.

• While connecting, or just after hello: the server is judging your IP. Think IP reputation or speed.
• After your server sends the email: the server has read it. Think content or a policy about that message.

How the big providers do it

• Gmail uses 421-4.7.0 and 421-4.7.28 for rate limits and reputation delays, with text explaining why. Short delays usually clear within hours. Delays lasting a day or more point to a reputation problem. Check Google Postmaster Tools.
• Microsoft uses codes such as 451 4.7.650 (“temporarily rate limited due to IP reputation”). It limits new and low-reputation IPs more strictly. SNDS, Microsoft’s free dashboard for your IPs, helps you link delays to reputation.
• Yahoo uses 421 4.7.0 with a code such as [TSS04] and text about volume or complaints. It often delays before it blocks, so steady delays at Yahoo are a warning.

What to monitor

Track:

• soft bounce rate per campaign and per provider
• queue size: how many emails are waiting to retry
• average tries before delivery
• the share of soft bounces that were never delivered

Alerts to start from, adjusted to your volume:

• Over 5% soft bounces in a campaign: investigate.
• Queue still growing after 4 hours: look for a problem at one provider.
• Over 2% of soft bounces never delivered: review retry settings and list quality.
• Over 10% soft bounces at one provider: pause sending there and investigate.

When soft bounces spike

Work through these questions in order:

1. Which provider? Group bounces by receiving domain.
2. Which code? Group them by reply code.
3. What changed? Compare with previous campaigns.
4. IP or domain? Is one IP or one sending domain affected?
5. Volume? Did you send much more than usual?
6. Authentication? Did a DNS record change, or did DKIM signing break? Check with the DNS lookup.
7. Content? Is this email very different from recent ones?
8. Outside signals? Check blocklists, Postmaster Tools and SNDS.

Checklist

• Make sure your server retries soft bounces automatically.
• Suppress addresses that soft bounce four campaigns in a row, and mailboxes that stay full.
• Never remove an address for a one-off server error or greylisting.
• Set per-provider speed limits and spread large sends out.
• Track soft bounces per campaign and per provider, with alerts.
• Treat steady delays at one provider as an early warning.
• If a soft bounce turns into a 5xx, switch to the block bounce playbook.