Bounce Handling Infrastructure

Bounce handling looks like the most boring part of email — failures come back, you remove the bad addresses, done. It is also one of the easiest parts to get quietly wrong, in ways that remove good contacts, leave dead ones in place, and hide the real reasons your mail is failing. A bounce is not just an address to delete; it is a message from a receiving server about what happened, and reading it correctly is the difference between a clean list and a slowly poisoned one. This page is about bounce handling done as actual infrastructure — parsing, classifying, scoping and suppressing properly — rather than the auto-remove checkbox that passes for it in most setups.

What is a bounce, and how do hard and soft differ?

A bounce is a delivery failure returned by a receiving mail server, and the first and most important split is between permanent and temporary. A hard bounce is a permanent failure, carried by 5xx SMTP codes — the address does not exist, the domain has no mail server, or your domain has been blocked — and it should be suppressed immediately, after a single occurrence, because continuing to mail it actively damages your reputation. A soft bounce is a temporary failure, carried by 4xx codes — a full mailbox, a server timeout, greylisting, a transient rejection — and it may well succeed on a later attempt, so it should be retried and only suppressed if it persists. The practical rule is decisive suppression for confirmed hard bounces and patient, reason-based handling for soft ones, treating a soft-bouncing address as dead only after it fails repeatedly across several sends.

How bad can a bounce problem get?

Worse than the small size of the numbers suggests, because the consequences cascade across your whole sending. Mailbox providers read your bounce rate as a direct signal of list quality, so a high rate tells Gmail, Outlook and Yahoo that you mail invalid addresses — and the penalties escalate predictably from heavier spam filtering to a lower domain reputation to outright throttling. A hard bounce rate above two percent can trigger inbox suppression across your entire sending domain, so even your transactional mail starts landing in spam. The most dangerous pattern is the cascade: an old or unverified list produces a sudden hard-bounce spike, and the provider responds by soft-bouncing your legitimate mail as punishment, a downward spiral that takes weeks of careful sending to reverse. Against that, the benchmark for a well-managed program is a total bounce rate under one percent, which is achievable but only with bounce handling that runs after every send, not occasionally.

Classifying bounces: why the codes can’t be trusted

It is tempting to treat the hard-or-soft label your platform shows as the truth, and that is the first mistake. There is no universal standard for bounce classification: one sending platform labels a particular reply hard while another calls the identical reply soft, receiving servers frequently return ambiguous or non-standard codes, and the enhanced status codes that should disambiguate are often missing or wrong. A generic “hard bounce” flag is therefore a product decision as much as a fact, and acting on it blindly removes good addresses on misreads and misses real failures. Proper classification parses the actual SMTP reply code, the enhanced status code, and the raw bounce text together, then maps the event to a specific reason — invalid user, invalid domain, disabled mailbox, mailbox full, transient, rate limit, policy, or unknown. The cases that do not map cleanly get quarantined for review rather than suppressed on a guess. Reading the reply, not trusting the label, is what keeps the list accurate.

Is every bounce the recipient’s fault?

No, and this is the distinction that separates real bounce handling from naive removal. Not every bounce means the recipient’s address is bad — many bounces are telling you something about your own sending. A rate-limit rejection means you are sending too fast for that provider; a policy rejection or a blocklist-driven 5xx means your IP or domain reputation has a problem; a content rejection points at your message. In all of these, the recipient is fine, and suppressing them would remove a good contact while hiding the actual issue. This is why a proper pipeline decides the scope of every bounce — whether the problem belongs to the recipient, the sending IP, the domain, or the campaign stream — and acts accordingly, suppressing the recipient only when the recipient is genuinely the cause. Separating recipient failures from sender-side rejections is what lets bounce data point at a reputation or authentication problem instead of silently deleting innocent addresses.

How should soft bounces be handled?

With patience and by reason, because a soft bounce mishandled becomes either a lost contact or a self-inflicted penalty. The right response depends on why the bounce happened: greylisting just needs a short delay before a retry, a full mailbox calls for progressively longer backoff, and a rate-limit or throttling soft bounce is best answered by reducing volume rather than retrying harder, since retrying into a throttle makes it worse. The counting also matters more than it seems. For a sender who may mail the same person several times in a day, a soft bounce should be counted by bounce-days rather than raw messages — one recipient with a full mailbox who receives five campaigns on Monday is one soft-bounce day, not five strikes, and pending retries should stay tied to that same recipient-day rather than each becoming a new penalty. Only after an address soft-bounces across several consecutive days, or a mailbox stays full long enough to look abandoned, does it graduate to suppression. Handled this way, soft bounces clean the genuinely dead addresses without discarding the temporarily unreachable ones.

Suppression must be global

A suppression that applies to one list and not the rest is barely a suppression at all. When an address is confirmed as a hard bounce, it has to be removed from active sending everywhere — every list, every segment, every automation and sequence — not just the campaign that surfaced it, because the same dead address sitting on three other lists will keep generating bounces and keep damaging your reputation. The suppression also has to be durable: a globally suppressed address should not be silently re-imported or re-subscribed back into sending, which means the suppression list is authoritative and a re-import cannot quietly override it. This is the central function of bounce infrastructure, and it is exactly what generic per-list bounce flags fail to do — they stop one list from mailing an address while leaving it live on every other. Global, durable suppression is what actually keeps the dead addresses dead.

Catching every bounce: the two paths

A bounce pipeline is only as good as the bounces it actually sees, and a large share of them arrive by a path most setups ignore. Some bounces are in-band — the receiving server rejects during the SMTP conversation, and your sending system records the failure directly. But many bounces are out-of-band: the server accepts the message and then sends an asynchronous delivery-status notification back to your return-path afterward, and because this happens after the connection closed, it never appears in the sending system’s own logs. Operators consistently find these out-of-band DSNs are a large fraction of all bounces, often the larger one. A pipeline that processes only the in-band failures therefore misses much of the problem, leaving dead addresses on lists while the dashboards look clean. Complete bounce handling captures both — the in-band rejections and the out-of-band notifications arriving at the return-path — which is precisely the gap that simple, one-path setups leave open, exactly as it appears in a MailWizz and PowerMTA integration.

The honest truth: a bounce spike is a symptom

The most valuable thing bounce handling can do is tell you when the bounces are not really about the addresses. A sudden rise in bounces is frequently a symptom of something deeper — broken authentication causing rejections, a reputation problem prompting policy bounces, a blocklisting, or simply a stale segment that should never have been mailed. A system that responds by silently deleting the bounced addresses cleans the symptom and buries the cause, so the underlying problem keeps producing bounces while you keep removing contacts. Good bounce infrastructure does the opposite: it surfaces the pattern, distinguishing a wave of invalid-user hard bounces from a wave of policy rejections, so you can see that the real issue is authentication or reputation rather than list quality. The goal, as experienced operators put it, is clean lists without hiding authentication, reputation, or strategy problems behind a generic hard-bounce label. Bounce data, read properly, is diagnostic — and that is most of its value.

Prevention beats handling

The cleanest bounce is the one that never happens, so prevention sits in front of handling. The single most effective measure is pre-send verification — running a list through validation before a major send catches the invalid addresses that would otherwise bounce, and is the difference between a hard bounce rate above two percent and one comfortably under half a percent. Real-time verification at the point of capture stops bad and mistyped addresses from entering in the first place, re-verifying any segment you have not mailed in ninety days catches the decay that accumulates at a few percent a month, and never buying or scraping lists avoids the invalid addresses and spam traps those carry. Role-based addresses, which bounce far more often than personal ones, deserve extra scrutiny. None of this replaces bounce handling — failures still happen on even the cleanest list — but it dramatically reduces the volume the pipeline has to manage, and it keeps your bounce rate in the range where reputation stays healthy.

How we run bounce handling for you

With MCSNET, bounce handling is run as the infrastructure it should be, not a checkbox. We parse every bounce for its SMTP code, enhanced code and raw reply, classify it by reason, and decide its scope — recipient, IP, domain or stream — before acting. Confirmed hard bounces are suppressed immediately and globally across every list and automation, durably, so they cannot be re-imported back into sending; soft bounces are retried by reason over a sensible window and suppressed only when genuinely dead; ambiguous cases are quarantined for review rather than removed on a guess. We capture both the in-band rejections and the out-of-band DSNs that one-path setups miss, and because we run the delivery layer too, we read bounce patterns alongside reputation, feedback loops and monitoring to surface the root cause when a spike is really an authentication or reputation problem. The result is clean lists and honest diagnostics, not silent deletion.

# mcsnet · bounce handling · brand.example (last send)
parsed        12,418 events · code+enhanced+raw
hard recip    198 → suppressed globally  done
soft recip    341 → retry window (greylist/full)
sender-side   57 rate-limit → NOT suppressed  # flagged: gmail throttle
ambiguous     9 → quarantined for review
out-of-band   return-path DSNs captured  both paths
rate          hard 0.4% · total 0.9%  healthy
signal        gmail throttle = sending issue, not list

Why work with us?

Because we treat bounces as information, not just garbage to remove. Anyone can flag a hard bounce; far fewer parse the raw reply, scope it correctly, suppress globally and durably, capture both bounce paths, and tell you when a spike means your authentication broke rather than your addresses went bad. Because we run the delivery infrastructure on our own IPs from Toronto, we see both sides of every bounce and can connect it to the reputation and monitoring data that explains it, and your suppression and contact data stay resident in Canada under PIPEDA. We build the pipeline that keeps your lists clean without hiding the problems a generic auto-remove would bury — which is the difference between a list that is merely smaller and one that is actually healthy.

Who this is for, and who it is not

It is for senders and platforms whose bounce handling has outgrown a checkbox — high-volume operations, ESPs and agencies for whom a poisoned list or a hidden reputation problem is a real cost, and anyone who suspects their current setup is removing good contacts, missing out-of-band bounces, or burying diagnostic signals. It is for white-label operators who need scoped, global suppression across many tenants. It is not, on its own, for a small sender whose ESP’s built-in handling genuinely suffices for a modest, well-verified list — we will say so rather than over-engineer. Bounce handling pairs with the feedback-loop complaint processing it sits beside, the reputation and monitoring it feeds, and the verification that prevents bounces upstream. Run as real infrastructure — parsed, classified, scoped, suppressed globally, and read for what it reveals — bounce handling stops being janitorial and becomes one of the clearest windows you have into the health of your sending.