Soft Bounce: What It Means and Why the Textbook Definition Misleads
A soft bounce is a temporary delivery failure: the receiving mail server refused the message with an SMTP 4xx reply, which RFC 5321 defines as a transient error the sender may retry. The address is not declared invalid. On cold lists the usual causes are greylisting, rate limiting and reputation deferrals.
Key takeaways
- The reply code is the definition: 4xx is a soft bounce, 5xx is a hard bounce, and RFC 5321 sets what each one instructs the sending server to do.
- On a cold list the common causes are greylisting, rate limiting and reputation deferrals, all of which are statements about the sender rather than the recipient.
- Your reported rate is partly a property of your sending tool, because each platform picks its own threshold for reclassifying a repeatedly deferred address as permanent.
- A soft bounce is not evidence that an address is bad, so purging on one deferral quietly degrades a list of perfectly valid addresses.
Soft Bounce: What It Means and Why the Textbook Definition Misleads
A soft bounce is a delivery failure that the receiving mail server reports as temporary. The message was accepted for delivery by your own sending system, reached the recipient's mail exchange, and was refused there with a reply the sending server is expected to treat as retryable rather than final. The address is not declared invalid, and the same message may be attempted again.
That is the whole definition, and every part of it that matters is carried by one number in the SMTP conversation.
The reply code is the definition
Mail servers answer each other in three-digit codes, and the first digit sets the category. RFC 5321, the SMTP specification, defines a 4yz reply as a Transient Negative Completion reply: "The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again." It adds that in this category "the SMTP client SHOULD try again."
A soft bounce is a 4xx. A hard bounce is a 5xx, which the same specification calls a Permanent Negative Completion reply and which instructs the sending client that it "SHOULD NOT repeat the exact request." Nothing else in the definition is load-bearing. The mailbox being full, the server being down, the message being oversized: those are causes commonly attached to the term, and they are examples rather than the meaning.
- The address is not declared invalid
- The sending server queues the message and attempts it again
- Reasons are often about the sender rather than the recipient
- Repeated 4xx replies eventually get treated as permanent by the sending platform
- Concentrated by receiving domain, this is a reputation reading
- The recipient or the domain is refused outright
- No further attempt at the same message is expected
- Usually a wrong address, a dead mailbox or a blocked sender
- Belongs out of the list immediately
- Counted against you by mailbox providers as list quality
The practical difference is what your sending platform does next. A 5xx ends the attempt. A 4xx puts the message in a retry queue, and the platform decides how long to keep trying and how many refusals it takes before the address is reclassified. That threshold is a product decision made by whoever built your sending tool, and it varies between tools, which is why the same address can be reported as a soft bounce in one platform and a hard bounce in another.
That variation is worth holding onto, because it means the number in your dashboard is partly a property of your tooling rather than purely a property of the world. Two platforms sending the identical message to the identical list through the identical mailboxes can report materially different soft-bounce rates, simply because one gives up after a shorter window than the other. Before comparing your figure against anyone else's, find out what your platform's conversion rule actually is. Most publish it, and the ones that do not will answer if asked.
Soft bounce, deferral and throttling name overlapping things
Three words circulate for what is broadly one event, and they are not interchangeable.
A deferral is the receiver's action: your message arrived at the recipient's mail exchange and was temporarily refused there. A throttle is usually the sender's own side: your platform or your mailbox provider declined to dispatch the message at all because you exceeded a quota or a rate ceiling, so it never reached the recipient's server. A soft bounce is the reporting label, and most tools apply it to both, which flattens a distinction that matters when you are trying to work out whose limit you hit.
The test is whether anything left your infrastructure. If the message never went out, the constraint is yours and it is answered by your own provider's published limits. If it went out and came back with a 4xx, the constraint belongs to the receiving side and the reply text is where the reason lives.
Where the textbook definition misleads
Search for a definition of this term and you will be given the same three causes: the recipient's mailbox is full, their server is temporarily down, or your message is too large. For a newsletter to an opted-in list, that is a reasonable picture. For cold outbound it is close to useless, because those three causes account for very little of what actually produces a 4xx on a cold list.
The reasons a business mail server temporarily refuses a message from a sender it does not know are mostly reasons about the sender.
- Yes: Greylisting: the receiver refuses an unknown sender once on purpose and accepts the second attempt
- Yes: Rate limiting: the receiver is capping how fast it will take mail from your domain or IP right now
- Yes: Reputation-based deferral: the receiver has doubts about the sender and is stalling rather than refusing
- Depends: Content or attachment inspection deferring the message for a second look
- Depends: A genuinely full mailbox at the recipient's end
- No: The recipient's mail server being down
- No: The message being too large for the receiving system
The first three are statements about your sending, delivered in a form that reads as a statement about the recipient. That is the misleading part, and it changes what a rising soft-bounce number should make you do. Read as a recipient problem it suggests better data. Read correctly it often points at sending volume, at authentication, or at a domain the receiving side has not yet decided to trust.
Greylisting deserves naming properly, because it is the one cause that is working exactly as designed when it produces a soft bounce. A greylisting server records the combination of sending address, recipient address and connecting server, refuses that combination the first time it sees it with a 4xx, and accepts it on a later attempt. The logic is that bulk sending software historically did not bother to try again, whereas a compliant mail server does, so a single temporary refusal separates one from the other at almost no cost to legitimate senders. Modern sending platforms all retry, so greylisting no longer filters much, but it is still widely deployed and it still shows up in your reporting as a soft bounce that later delivered perfectly well.
That is why a soft-bounce count read on its own, on the day of the send, systematically overstates the problem. Some proportion of those messages are sitting in a queue and will arrive. A count taken after the retry window closes is a different and much more useful number, and the gap between the two is worth knowing for your own infrastructure.
Google's own sender guidelines put the mechanism plainly on the volume side: "Send email at a consistent rate. Avoid sending email in bursts," and they warn that as volume increases you should monitor server responses because sending may be rate limited. A rate-limited send shows up in your reporting as soft bounces.
Reading soft bounces without being misled
One number for the whole campaign tells you almost nothing, because the causes above are not distributed evenly across receiving domains. The useful cut is by the receiving side.
- Step 1Split by receiving domain
Group deferrals by the recipient's mail provider rather than reading one campaign-wide figure.
- Step 2Read the reply text, not the category
The server usually says why in the same line. Greylisting, rate limiting and reputation language look nothing alike.
- Step 3Check whether attempts eventually landed
Greylisting resolves itself on a later attempt. A throttle or a reputation stall often does not.
- Step 4Compare against your sending domains
One domain deferring everywhere is a sender problem. Every domain deferring at one provider is that provider's judgment of you.
A pattern concentrated at one receiving provider, on every one of your sending domains, is that provider forming a view. A pattern spread across every receiving provider but confined to one of your sending domains points at that domain: its age, its authentication, its warming, or its history. Warming a domain before you send exists to keep that second pattern from happening at all, and reading the raw reply text is the skill covered in reading MXToolbox like a deliverability engineer.
The one thing worth resisting is treating retry volume as progress. A platform quietly re-attempting thousands of deferred messages can keep a campaign looking active while the receiving provider is holding the line, and the retries themselves add to the volume the provider is objecting to.
What it is worth doing about
Soft bounces have a floor that no amount of list quality removes, because greylisting is a deliberate design and some proportion of any real business list sits behind it. Chasing that floor to zero is not a goal.
What is worth doing is keeping the causes separable. Verification removes addresses that would otherwise produce permanent failures, and clearing those out makes the remaining soft-bounce signal readable rather than buried in noise; the tools that do it are compared in email verification tools, and the rate you should expect once they have run is in cold email bounce rate benchmarks. Sending inside the limits your own provider publishes keeps you out of the rate-limiting class entirely, and those limits are set out in email sending limits by provider.
Volume discipline is the other half. We send one message per campaign, written on one premise and sent once, and a later approach to the same person is a separate campaign built on a different premise. That shape matters here for a mechanical reason rather than a stylistic one: the amount of mail a receiving provider sees from a given sending domain is what sets its rate limiting and its deferral behaviour, so a programme that reaches a person once puts a fraction of the load on that provider's patience compared with one that keeps returning to the same inbox. The soft-bounce rate is downstream of that decision.
There is also a question of what happens to the address itself, and it has a cleaner answer than most people expect. A soft bounce is not evidence that an address is bad. Unless the reply text says otherwise, the mailbox is presumably fine and the refusal was about timing, load or trust. So the address stays in your data as a valid address. Whether that person ever receives anything from you again is a separate decision about a separate campaign with its own premise, made on its own merits, and it has nothing to do with the deferral. Confusing the two is how lists get quietly degraded: addresses that were never invalid get purged because a receiving server was busy on a Tuesday.
The one address class worth removing on a soft bounce is the one where the reply text names the sender rather than the recipient, particularly a block or a reputation refusal that repeats at the same provider across every one of your domains. Those are not addresses to clean. They are a signal to stop sending into that provider until the underlying reason is fixed, because continuing to push generates exactly the volume of refusals that hardens the provider's view.
If deferrals are climbing across every receiving provider at once, the reading is your sending infrastructure rather than your list, and the diagnostic order is set out in the cold email deliverability guide. Where that whole layer is more than a team wants to own, our pay-per-qualified-meeting outbound is the version that keeps it with us.
Verified as of August 2026. Verify current terms with the vendor before relying on them.
Frequently asked questions.
Frequently asked questions- What is the difference between a soft bounce and a hard bounce?
- The SMTP reply code. A soft bounce is a 4xx, which RFC 5321 calls a transient negative completion and expects the sending server to try again. A hard bounce is a 5xx, a permanent negative completion, which instructs the sender not to repeat the request. One means try later, the other means stop.
- Is a soft bounce bad for deliverability?
- Not by itself, since greylisting produces soft bounces on perfectly healthy sending. What matters is the pattern. Deferrals concentrated at one receiving provider across all of your sending domains suggest that provider is forming a negative view of you, and continuing to push volume into it tends to harden that view.
- What soft bounce rate is normal for cold email?
- There is a floor no list quality removes, because greylisting is deliberate and some share of any real business list sits behind it. Measure your own rate after the retry window closes rather than on send day, since messages still queued will often arrive, and compare it against your own history rather than a published average.
- Should I remove soft bounced addresses from my list?
- Generally no. Unless the reply text names a block or a reputation refusal, the mailbox is presumably fine and the refusal was about timing, load or trust. Removing those addresses discards valid data. The exception is a refusal that repeats at one provider across every sending domain, which is a sending problem rather than an address problem.