You can't un-bounce an email

·4 min read

One morning a sending account I run was suspended. Not rate-limited, not warned. Off. A bulk send had gone out to a list of cold-outreach domains, the trailing bounce rate crossed 15%, and AWS SES suspends sending around 10%. The list was the problem, but by the time you see the bounce, the damage is already done. You can’t un-bounce an email.

That suspension turned into a few weeks of rebuilding how the whole pipeline sends. Here is what I actually learned, none of it the stuff the deliverability blogs lead with.

Reputation is enforced with a guillotine, not a warning#

The bounce rate is not a delivery stat. It is a reputation signal, and the provider acts on it unilaterally. There is no escalating series of nudges. You sit under the threshold for a while, one bad batch pushes the trailing average over it, and the account is suspended mid-campaign. The appeal is slow and the burden is entirely on you to prove the lists are clean now.

So the real constraint is not “send carefully.” It is: never let a bad address reach the sender in the first place.

You can only fix it before the send, which is harder than it sounds#

That means verifying every address before you hand it to the mail server. I assumed this was a solved, boring problem. It is not.

The strongest signal is an SMTP probe: connect to the recipient’s mail server, walk through EHLO / MAIL FROM / RCPT TO, and read whether it answers 250 (accepted) or a 5xx (no such mailbox). That is mailbox-level truth. It also has a hard ceiling:

  • Catch-all domains defeat it. A domain configured to accept everything answers 250 for anything@domain, so a “yes” tells you nothing about that specific mailbox.
  • Your probing IP gets throttled. Do this at volume and the big providers greylist or block the IP you are probing from, and your answers degrade to “unknown.”
  • In practice it tops out around 38% confident recall at a few percent false-accept. The rest is genuinely unknowable from outside.

The cheaper screen (syntax, disposable-domain lists, does an MX record exist) is fast and risk-free, but it only tells you the domain can receive mail, never the mailbox. Past the SMTP ceiling, the honest move is to buy verification from a service running warm, reputable IPs rather than build a better prober. Some problems you buy.

The verdict has to be three-valued#

This is the one design decision that matters most, and it is easy to get wrong. A verifier must return one of three things:

  • sendable → send it
  • undeliverable → drop it
  • unknown → do not send in this batch

The trap is collapsing unknown into “send, probably fine.” That single shortcut is what reintroduces the bounces that got you suspended. unknown means retry later or skip, never send. Treat the uncertain bucket as undeliverable-for-now and the bounce rate stays where you want it.

The other half is reliability: a verification request must never hang. Every stage (pacing, the probe connect, the read) is individually time-bounded, and a request that blows its budget returns unknown rather than stalling the whole batch behind one slow mail server.

Clean lists still land in spam, because that is reputation, not authentication#

Here is the part that surprised me. Even with a perfectly scrubbed list and textbook SPF, DKIM, and DMARC all aligned per domain, mail from a cold domain still lands in spam. I watched correctly-signed messages from a brand-new sending subdomain go straight to the junk folder. The authentication was perfect. The reputation was zero.

Auth proves you are who you say you are. It does not make a receiver trust you. Trust is earned by sending consistent, low-complaint volume over time, and you cannot shortcut it. What you can do is stop actively hurting yourself:

  • Rotate across several sending domains so no single one absorbs a cold spike.
  • Pin each recipient to one domain deterministically (a stable hash, not a random pick) so a given person always sees the same sender across a sequence. Consistency is part of reputation.
  • Trickle, do not burst. Space sends at a steady gap per domain instead of dumping the batch. Throughput is just domains / gap: more domains or a smaller gap, your choice, but the shape stays smooth.

This does not fix cold-domain placement on its own. It warms the domains gradually instead of torching them, which is the most you can do from the sending side.

The one-line version#

Email deliverability is a reputation system, and reputation is slow to earn and instant to lose. Everything above is just different angles on that: clean the list before you send, treat uncertainty as a hard stop, authenticate fully but expect it not to be enough, and warm slowly. The send is the easy part. Earning the right to be in the inbox is the work.