Handling Soft Bounces: When to Retry and When to Suppress

Retry a soft bounce within the send, then decide by code. Your ESP will retry a temporary failure automatically, for 8 hours at Mailgun and up to 72 hours at SendGrid. Suppress an address only when the same mailbox-level soft bounce repeats across several separate campaigns. Reputation-related soft bounces are a sender problem, not a list problem.

A soft bounce is a refusal with a 4xx code, or a mailbox-level failure the platform has decided might clear. The difficult part is not the definition, which is covered in the soft bounce glossary entry. It is that platforms disagree about which failures are soft, how long to retry them, and when a soft bounce becomes permanent. This post sets out those rules side by side, from each vendor's own documentation, and ends with a policy you can apply.

For the wider causes of bounces, see why cold emails bounce. For the account-level bounce rate limits that soft bounces can eventually push you over, see bounce rate limits by platform.

What the standard says

RFC 5321 expects a sending server to queue a temporary failure and retry it for days. Section 4.5.4.1 says the retry interval "SHOULD be at least 30 minutes" and that "the give-up time generally needs to be at least 4-5 days". It also notes that failures are usually transient. It favours two attempts in the first hour and then one every two or three hours.

The reply code tells the sender which path to take. A 4yz reply is a "Transient Negative Completion": the action did not happen, but the client "SHOULD try again". A 5yz reply is permanent and the client should not repeat the same request. RFC 3463 adds the enhanced status codes you see in bounce messages. A 4.x.x code is a "persistent transient failure", and a 5.x.x code is a permanent one.

So the protocol answer is simple: retry 4xx, do not retry 5xx. Real platforms deviate from it in both directions.

How each platform handles soft bounces

ESP retry windows are far shorter than the RFC's four to five days, and each platform handles repeats in its own way. Each row below comes from that vendor's documentation, read on 1 October 2026.

Platform	Retry within a send	What happens after	Repeat soft bounces across sends	Source
SendGrid (Twilio)	Up to 72 hours, exponential backoff	Event changes to blocked	Not auto-suppressed; SendGrid leaves the decision to you	Deferrals, classifications
Mailgun	10 min, 15 min, 30 min, 1 h, 2 h, 4 h; 8 hours max	Dropped as permanent failure "Too old"	Not stated	Mailgun help
Amazon SES	"Multiple times" (duration not stated)	Transient bounce notification	Not stated; soft bounces excluded from bounce rate	SES docs
Mailchimp (marketing)	Not stated	Shown as soft bounce in report	7 soft bounces (no activity) or up to 15 (engaged), then cleaned	Mailchimp help
Mailchimp Transactional	Not stated	Address rejected for 24 hours	After expiry, later bounces bring longer rejections	Mailchimp developer docs
Postmark	Not stated	Recorded as SoftBounce or Transient	Auto-deactivation documented for hard bounces and spam complaints only	Bounce API, guide
Constant Contact	Not stated	"Mailbox Full", "Vacation/Auto-Reply", "Other" categories	Advises contacting the person for mailbox full; no action for vacation replies	Constant Contact KB

Three practical points follow.

Mailgun's window is configurable and can be very short. The o:deliver-within API parameter, or the X-Mailgun-Deliver-Within header, accepts anything from 5 minutes to 24 hours. Mailgun's own example: set 15 minutes and a temporarily failed message gets one retry, 10 minutes later. That suits a one-time passcode. For a newsletter it turns ordinary greylisting into lost mail.

SendGrid's "blocked" is sometimes a soft bounce that ran out of time. A message deferred for the whole 72 hours ends as blocked, not bounced, so a mailbox that was full for four days shows up in a different report from a mailbox that does not exist.

Mailchimp's 7-and-15 rule counts soft bounces, not days. On a weekly newsletter, an inactive contact is cleaned after about seven weeks of continuous soft bouncing. On a monthly one, the same contact stays on your list for more than half a year.

Mailbox full is not reliably soft

"Mailbox full" is the textbook example of a soft bounce, and the platforms classify it inconsistently. RFC 3463 says the full-mailbox code X.2.2 "should be used as a persistent transient failure". Gmail splits it into two messages that differ by one word:

452 4.2.2 The recipient's inbox is out of storage space.
552 5.2.2 The recipient's inbox is out of storage space and inactive.

Those two lines are quoted from Google's SMTP error reference. The first is temporary: the owner is active and may clear space. The second is permanent: the inbox is full because nobody is reading it. That is a dead address in practice, even though the mailbox technically exists.

The ESPs then add their own layer. Mailchimp lists "Mailbox is full" as a soft bounce reason. Mailgun lists "Mailbox full" among the permanent failures it does not retry, together with "any 5xx error". Postmark's SoftBounce type covers "mailbox full, account disabled, exceeds quota, out of disk space". Mailchimp even lists "Domain name does not exist" as a possible soft bounce, on the grounds that it "may be a temporary issue".

The lesson: do not build a suppression rule on the word "soft" in your ESP's export. Build it on the enhanced status code, which you can get from the raw bounce message.

Mailbox soft bounces versus sender soft bounces

The most useful split is not hard versus soft. It is whether the temporary failure is about the recipient's mailbox or about you, the sender. They need opposite responses.

Code (Gmail wording)	What it is about	Correct response
452 4.2.2 inbox out of storage	The recipient's mailbox	Retry next send; suppress if it persists
450 4.2.1 receiving email too quickly	That recipient's inbound rate	Retry later; do not suppress
421 4.7.0 try again later	Your IP or domain reputation, or your DNS	Fix the sender side; do not suppress the address
451 4.7.x or other temporary policy rejections	Often greylisting or reputation	Let the MTA retry; investigate if widespread
552 5.2.2 inbox full and inactive	The recipient's mailbox, permanently	Suppress now

A 421 4.7.0 across many recipients at the same provider is not a list hygiene problem. Google also uses the 421 class for a sending IP without a matching PTR record. If you suppress every address that returned it, you delete good contacts and leave the actual fault, your infrastructure, in place. A cluster of 4.7.x deferrals at one mailbox provider is a reason to check authentication and sending reputation, not your list.

A suppression policy you can apply

There is no industry standard for how many soft bounces justify removal; the numbers below are our recommendation, not a published rule. They are set to be stricter than Mailchimp's 7 and less hasty than suppressing on the first bounce.

1. Within a send, let the infrastructure retry. Do not resend a soft-bounced message yourself on top of the ESP's retries. If you control your own MTA, the RFC's minimum of 30 minutes between attempts and four to five days before giving up is the baseline.
2. Classify every soft bounce by enhanced status code, not by the ESP's soft or hard label. Store the raw code with the address.
3. Sender-side codes (4.7.x, rate limits) never count against the address. Log them by receiving domain and alert when one provider spikes.
4. Mailbox-side codes (4.2.2 and similar) count as a strike. Suppress after three strikes in separate sends at least a week apart, with no successful delivery between them. Reset the count on any delivery or reply.
5. Permanent codes hidden inside soft categories, such as 5.2.2 ... inactive or "account disabled", are suppressed immediately.
6. Suppress only for that one address. Do not suppress the whole domain on mailbox-level codes.
7. Re-check before reactivating. If you want to try a suppressed address again months later, run it through a mailbox check first rather than sending to find out.

For cold email the counts are smaller, because a sequence of three or four steps rarely produces three separate sends to a dead mailbox before it ends. In practice, an address that soft-bounces with a mailbox code on step one should not get step two until it has been checked.

The short version

• The RFC expects retries over four to five days. ESPs use shorter windows: 8 hours at Mailgun, 72 hours at SendGrid, and Mailgun lets you go as low as 5 minutes.
• Mailchimp converts soft to hard after 7 soft bounces, or up to 15 for engaged contacts. SendGrid does not suppress repeat soft bounces automatically.
• "Mailbox full" can be temporary (452 4.2.2) or effectively permanent (552 5.2.2 ... inactive). Platforms do not agree on which bucket it belongs in.
• Mailbox-side soft bounces are a list problem. Sender-side ones (4.7.x) are your problem. Suppressing the second kind deletes good contacts and fixes nothing.
• Decide by enhanced status code, count strikes across separate sends, and reset the count on any successful delivery.