Soft bounce

Soft bounce, defined by the reply not the story

A soft bounce is a temporary failure to deliver an email. The receiving mail server responds during the SMTP conversation with a transient error, conventionally a reply code in the 4xx range, and the sending system is expected to try again later. Common causes are a full mailbox, a greylisting deferral, a rate limit, a temporary DNS problem, a TLS negotiation failure or a server that is briefly unavailable. The address may be perfectly valid; the delivery simply cannot complete at that moment.

The definition rests on the reply code, not on a marketing platform’s label. Many platforms classify any non-permanent failure as a soft bounce, which is close enough for reporting but too coarse for action. A mailbox full condition and a policy rejection can both appear as soft bounces in a dashboard while requiring opposite responses. The reliable record is the raw SMTP reply and its enhanced status code, stored alongside the campaign and the recipient.

What a soft bounce is not: it is not a hard bounce, which is a permanent failure and should be suppressed immediately. It is not a block, which is usually a policy decision with a 5xx code. It is not a complaint, which is a recipient action after delivery. And it is not proof that the address is bad. Treating it as proof is how teams delete reachable customers.

The SMTP mechanics behind the delay

SMTP is a conversation. The sending server connects, announces itself, names the sender, names the recipient and offers the message. At each step the receiving server can accept, defer or reject. A 4xx reply at the recipient step means the message is not accepted now but may be accepted later. A 5xx reply means it will not be accepted for this attempt and usually will not be accepted at all. The distinction is protocol-level and older than any marketing platform.

Enhanced status codes add detail after the basic reply. A code beginning 4.2 indicates a mailbox-related transient condition, such as a full mailbox. A code beginning 4.7 indicates a policy or security-related transient condition, such as rate limiting or a reputation check. A code beginning 5.1 usually means an unknown recipient, which is permanent. These prefixes are more useful than the prose because they are stable across languages and vendors.

Greylisting is a special case worth knowing. A server temporarily rejects mail from an unfamiliar sender with a 4xx code and expects a retry after a few minutes. Legitimate senders retry; some spam systems do not. The delay is intentional and the message usually delivers on the second attempt. If your retry schedule is longer than the greylist window but your platform gives up after one attempt, you will misclassify a deliverable address as a soft bounce.

Soft bounce, hard bounce, block and complaint

Four non-delivery or post-delivery events get mixed together in weekly reports. A soft bounce is temporary. A hard bounce is permanent, usually an unknown user or a domain that does not exist. A block is a policy refusal, often a 5xx reply from a gateway that has decided your IP or domain should not pass. A complaint is a recipient marking the message as spam after delivery. Only the first is a retry candidate, and only the last two are reputation emergencies.

The operational difference is what you do next. Soft bounce: retry with a budget, then evaluate. Hard bounce: suppress the address and do not retry. Block: investigate authentication, reputation and content, and pause the affected route. Complaint: honour the unsubscribe immediately, suppress and review the segment that received the message. Applying the soft bounce playbook to a block produces retry storms; applying the hard bounce playbook to a soft bounce deletes good contacts.

Reporting should keep the four categories separate by provider. A single non-delivery rate that mixes them will move when the mix changes and tell you nothing about cause. The number a deliverability lead needs is soft bounces by enhanced status prefix, hard bounces by domain, blocks by provider and complaints per thousand delivered.

A retry policy that helps rather than harms

Retries should be few, spaced and bounded. A workable default is three attempts over roughly a day: the first retry after fifteen to thirty minutes, the second after a few hours, the third the next day. Add jitter so that a campaign to one domain does not retry in lockstep and create a burst. Stop retrying a recipient once the attempt budget is exhausted and record the final reason.

Backoff matters because the cause is often load. If a provider is rate limiting you, immediate retries make the rate limit worse. If a mailbox is full, retrying every five minutes for a week is pointless and looks abusive. If a server is down, a long retry window may deliver the message hours later when it is no longer relevant. The retry policy has to know what the message is: a password reset has a different useful life from a monthly newsletter.

The retry queue also needs isolation. A single domain returning 4xx for every recipient should not consume the worker pool that serves every other domain. Per-domain concurrency limits, circuit breakers and a dead-letter queue keep one bad destination from slowing the whole programme. None of this is exotic; it is the same queue discipline used for any unreliable dependency.

When a soft bounce becomes permanent

Repeated soft bounces are evidence, not proof. A mailbox that has been full for three consecutive campaigns over six weeks is probably dormant or abandoned, and continuing to mail it costs reputation with no return. A domain that returns transient policy errors for every message over a month may be blocking you, which is a different problem. The decision to suppress should depend on the pattern and the cause, not on a single event.

A common rule is three soft bounces across separate sends within thirty days, followed by a suppression or a sunset step. Some teams use a longer window for mailbox full and a shorter one for policy deferrals. Whatever the rule, write it down and apply it consistently. A rule that exists only in an analyst’s head produces a list that changes shape every time someone new runs the query.

Suppression is not deletion. Keep the record, the reason and the date, so that a support agent can explain why a customer is not receiving mail and so that a later re-engagement campaign does not accidentally re-add the address. Under the DPDP Act, a suppression record is also part of the evidence that you honoured a preference, which is a reason to keep a minimal marker even after other data is erased.

The Indian context for transient failures

Indian B2B lists often concentrate on a small number of corporate gateways, and those gateways can be stricter and slower than consumer providers. A campaign to a few hundred enterprise domains may see deferrals that look alarming in percentage terms but affect a handful of recipients. Per-domain reporting prevents a scary rate from a tiny denominator. It also shows whether the deferrals cluster at one gateway, which points to a reputation or authentication conversation rather than a list problem.

Consumer behaviour adds a seasonal shape. Festive campaigns, sale events and end-of-quarter pushes raise volume sharply, and receiving providers respond to sudden volume with rate limits and deferrals. A team that normally sends fifty thousand messages a week and then sends four hundred thousand in three days should expect transient failures even with perfect authentication. Ramping volume, segmenting by engagement and spacing the send are the practical mitigations.

Infrastructure location matters too. If the sending IPs sit outside India, some regional providers may treat the traffic differently, and delivery times shift with the route. That is not a reason to move everything, but it is a reason to measure per provider and per route rather than trusting a global average. The same campaign can look healthy in one market and soft-bounce heavily in another.

Reputation, list hygiene and the cost of ignoring both

Soft bounces are less damaging than hard bounces and complaints, but they are not free. A list that is full of dormant mailboxes produces low engagement, and low engagement is a signal that providers use. The soft bounce rate is therefore an early indicator of a list quality problem that will later show up as spam placement. Watching it is cheaper than fixing the placement.

Hygiene is the response. Remove hard bounces immediately, suppress repeated soft bounces on a schedule, segment by last engagement and stop mailing contacts who have not opened in a defined period. A sunset policy is not a punishment; it is a way to keep the active list active. The contacts who never engage are the ones who generate complaints when you keep pushing.

Volume is the other lever. Sending the same list more often does not create engagement; it creates fatigue and deferrals. A team that sees soft bounces rise after increasing frequency should test the frequency hypothesis before touching the template. The data usually answers the question in two weeks.

Instrumentation: what to store on every failure

Store the raw reply code, the enhanced status code, the receiving domain, the timestamp, the attempt number, the campaign and the recipient identifier. That set answers most questions. The raw code lets you reclassify later when a platform changes its labels. The attempt number separates a first failure from a pattern. The campaign and recipient let you join to engagement and consent.

Aggregate by enhanced status prefix and domain, not by campaign alone. A campaign view tells you that this send had a problem; a domain view tells you where. Alert on changes in the soft bounce rate per domain with a minimum volume threshold, so a tiny domain cannot page someone at midnight. Keep a separate alert for any 5xx block at a major provider, because that is a different severity.

Finally, make the classification visible to the people who act on it. A support agent should see that the address is soft-bouncing, not that it is invalid. A campaign manager should see that the domain is deferring, not that the list is bad. The same data, presented with the right label, prevents the wrong fix.

Worked example: fifty thousand sends, one bad gateway

A sample run: a Pune SaaS company sends fifty thousand onboarding emails over two days. The dashboard reports 1,180 soft bounces, a rate of 2.4 percent, which looks acceptable until the breakdown shows that 940 of them are at one corporate gateway and 820 are the same 4.2.2 mailbox full condition. The remaining soft bounces are spread thinly across consumer domains.

The first retry recovers 610 of the 1,180. The second recovers another 180. After the third attempt, 260 remain undelivered, of which 210 are the same corporate mailboxes that were full on the previous two campaigns. The team suppresses those 210, keeps the rest on a watch list, and opens a conversation with the gateway about the sending domain and volume pattern.

The headline rate barely changed, but the action did. The team stopped retrying dead mailboxes, reduced load on the gateway, and avoided the temptation to rewrite a subject line that was never the problem. The per-domain view turned a vague number into one list cleanup and one infrastructure conversation.

The mistakes that turn a small problem into an outage

The first mistake is suppressing on the first soft bounce, which deletes reachable contacts and quietly shrinks the list. The second is retrying forever, which wastes capacity and can look like an attack to the receiving server. The third is treating every non-delivery as the same category, which sends the team to the wrong fix. The fourth is ignoring the enhanced status code, which is the only field that distinguishes a full mailbox from a policy refusal.

A fifth mistake is invisible: not recording the attempt number and the final reason, so nobody can tell whether a contact was suppressed for a hard bounce or a temporary one. That matters when a customer asks why they stopped receiving mail, and it matters under DPDP when you need to show that a preference was honoured for a stated reason.

The fix is a short policy document with three tables: classification by reply code, retry schedule by message type and suppression thresholds by cause. Review it twice a year and whenever the sending platform changes. A policy that fits on two pages is more likely to be followed than a runbook nobody reads.

• Never suppress on a single soft bounce.
• Cap retries and add jitter to avoid bursts.
• Store the enhanced status code, not just the label.
• Separate soft, hard, block and complaint in reporting.
• Review suppression thresholds twice a year.