This post walks through the pipeline as it ended up: an optional verification before each send, classification of what comes back, a counter for soft bounces, and two circuit breakers that stop a sender before the damage spreads. The backend is Go, with asynq on Redis for the send queue; the code below is trimmed from it.

One queued job per recipient

Pressing Send does not send anything. The sendCampaign mutation runs pre-flight checks, marks the campaign as sending and enqueues a single campaign:dispatch job. That job resolves the audience, drops every suppressed address with a recorded reason, and enqueues one email:send job per recipient, spaced out at the sender's configured rate (ten per second by default).

// Spread the sends over time instead of handing the relay a burst.
processAt := batchStart.Add(time.Duration(enqueuedCount/ratePS) * time.Second)
task := asynq.NewTask("email:send", payload, asynq.Queue("high"))
_, err := client.Enqueue(task, asynq.ProcessAt(processAt))

Because every recipient is its own job, every recipient gets its own outcome: sent, skipped with a reason, bounced or retried. That is what makes the rest of the pipeline possible.

Verify before sending, but read the verifier carefully

A campaign can opt into checking each address with an email verification API just before it is sent. A hard result skips that recipient and suppresses the address; anything else lets the send go ahead.

The first version treated every non-valid answer as a hard bounce. That suppressed live contacts whenever the verifier itself timed out. The fix that followed still checked the status label first, so a result like status "Invalid" with the message "Unable to verify: Server disconnected" was still read as hard. Worse, a live iCloud address with dozens of opens was suppressed because the verifier called it "disposable", an opinion about the address rather than a finding about the mailbox.

The rule that came out of it: read the message before the status. The message says what happened at the mailbox; the status is a lossy bucket that labels a network timeout, a full mailbox and a missing user all as "Invalid".

switch {
// The verifier failed. That says nothing about the address.
case containsAny(msg, "unable to verify", "disconnect", "timeout", "no response"):
	return VerdictInconclusive
// The mailbox exists but cannot take mail right now.
case containsAny(msg, "mailbox full", "over quota", "greylist", "try again"):
	return VerdictSoft
// An opinion about the address, never a reason to suppress it.
case containsAny(msg, "disposable", "role account", "high risk"):
	return VerdictInconclusive
// A genuine non-existence finding.
case containsAny(msg, "no mx", "mailbox not found", "user unknown", "no such"):
	return VerdictHard
}
// Not confident: send, and let a real bounce decide.
return VerdictInconclusive

Only VerdictHard suppresses. Everything uncertain falls through to sending, because a genuinely bad address will produce a real bounce a minute later, and a real bounce is better evidence than any prediction.

Why a verifier's answers deserve that much suspicion is a post of its own: five ways an email verifier lies.

Classify what actually comes back

Real bounces arrive two ways. Some are synchronous: the receiving server rejects the recipient during the SMTP conversation. Others arrive later as events from the relay's webhook. Both go through the same classifier, keyed on the SMTP code and the reason text.

• A 5xx rejection during the send is recorded as a hard bounce and the job returns without an error, so the queue does not retry a permanent failure.
• A 4xx or a connection error is returned as an error, and the queue retries the job with backoff.
• 552 and 452 (mailbox full) are soft, even though 552 starts with a 5.
• Webhooks often carry the enhanced status code, such as 5.2.2, instead of the three-digit reply code. A prefix match on "5" reads that as hard; it is a full mailbox, so it is matched explicitly as soft.

Soft bounces count, they do not kill

One soft bounce means nothing; a mailbox that has been full for weeks probably is not coming back. Each contact carries a counter of consecutive soft bounces. Seven in a row with no delivery in between promotes the next one to a hard bounce, and a single delivered event resets the counter to zero.

A hard bounce suppresses the address for that organisation only, never globally, since one tenant's bad list says nothing about another tenant's customer. It also cancels the contact's active automation flows, rather than letting each queued step fail one by one for the length of the sequence.

Circuit breakers for the sender

Per-address handling cannot protect against a bad list. Two breakers sit above it, using the thresholds mailbox providers themselves enforce:

• Per campaign: once 100 messages have gone out, a bounce rate above 10% or a complaint rate above 0.3% pauses the campaign.
• Per organisation: over a rolling seven-day window, and only after 500 sends, 5% bounces or 0.1% complaints raises a warning, and 10% or 0.3% suspends sending for the organisation.

The minimum volumes matter as much as the rates. Three bounces out of the first twenty sends is 15%, and pausing on that would stop every new customer's first campaign.

Make leaving easy

Every message carries one-click unsubscribe headers (RFC 8058), which the large mailbox providers now require for bulk senders. An unsubscribe that works from the inbox is far cheaper than a spam complaint.

b.WriteString(fmt.Sprintf("List-Unsubscribe: <%s>, <mailto:%s>\r\n", unsubURL, unsubEmail))
b.WriteString("List-Unsubscribe-Post: List-Unsubscribe=One-Click\r\n")

What I would keep

• Suppression is permanent, so only suppress on evidence about the mailbox, never on a guess about the address.
• Read a verifier's message before its status label.
• Do not retry a 5xx; do retry a 4xx; and match enhanced status codes explicitly.
• Count soft bounces and reset the count on delivery.
• Scope suppressions to the tenant, and put rate-based breakers above per-address rules, with a minimum volume before either one fires.

The rest of the platform, from the visual builder to the tracking endpoints, is in the Email Automation Platform case study.

Related: Five ways an email verifier lies, and how we caught them.

Originally published at tuanleanh.com.

I worked on an email verification service (FastAPI, Celery on Redis, MySQL) and on the email platform that calls it before every send. Most of the hard work on the verifier was not the SMTP check itself. It was learning which answers to distrust. These are the five that mattered most, because each one either told a customer to delete a live address or charged them for an answer that was not real.

1. Microsoft 365 says 550 to everyone

Some corporate Microsoft 365 tenants answer 550 Mailbox not found for every recipient when they do not trust the IP that is asking. That reply looks exactly like a real hard bounce, so the customer sees a red Invalid and removes a working address.

The test that exposed it was cheap: ask the same server about a local part invented on the spot. When the reported address, info@ and a random string all get the identical 550, the server is not discriminating, and its answer is worthless. Across production data, domains where every address hard-bounced were far more likely to be hosted on Microsoft 365 than healthy domains, while Google-hosted domains almost never showed the pattern.

So hard bounces from Microsoft 365 and iCloud mail hosts are re-checked from a different network before they are believed. The list of hosts is short on purpose, and every entry has a measurement behind it.

2. Yahoo accepts everything

Yahoo-operated mail hosts accept every recipient during the SMTP conversation, then bounce later. A plain check cannot learn anything there. The upstream checker answered these with a synthetic "default pass", which would have been a valid result for an address that might not exist.

We record those as Unknown and do not charge for them, because no check happened. They are then re-checked by a prober that can get a real answer from Yahoo, and only a real answer is billed.

3. "No MX records" under load is not a verdict

A domain with no MX records cannot receive mail, so "No MX" reads like a final answer. Under load, though, the DNS lookup behind it fails transiently, and the checker reports the failure as missing records. It once told us gmail.com had no MX records, hundreds of times over two months.

The fix is a small retry: "No MX" is re-asked twice before it is accepted. Each retry is another slow round trip, so the count stays low, but it is enough to turn most of these back into real answers.

4. A dropped connection says nothing about the mailbox

Many servers simply close the connection on an IP they dislike. "Server disconnected" is a fact about the asker, not the address. It is stored as Unknown with a reason code (blocked, greylisted, provider refuses verification, and so on) rather than folded into Invalid, and the blocked ones are the only ones worth re-checking from another network. A timeout, by contrast, would time out from anywhere.

The same rule applies one step downstream. The email platform that consumes these results reads the message before the status label, and never suppresses an address on an "unable to verify". That side is in the bounce handling post.

5. A cache that remembers the wrong question

Looking up a domain's MX hosts is slow, so the answer "does this domain match the distrusted-host list?" was cached for seven days. Then iCloud was added to the list. iCloud kept returning its cached "no match" for a week, and every iCloud hard bounce in that week skipped the re-check.

The cache key now carries a fingerprint of the list itself, so changing the list changes every key and old answers are simply never read again. The raw MX hosts are cached separately, because they are true no matter what anyone is matching against them.

# The verdict depends on the suffix list, so the key does too.
fingerprint = hashlib.sha1(",".join(blocking_suffixes()).encode()).hexdigest()[:10]
key = f"mxblock:v2:{fingerprint}:{domain}"

What carries over

• Test a server with an address you just invented. If it answers the same as for the real one, it is not telling you anything.
• Keep "unknown" as a first-class answer, with a reason, instead of rounding it to valid or invalid.
• Separate facts about the asker (blocked, timed out) from facts about the mailbox.
• Only add a provider to a special-case list when a measurement puts it there.
• Put everything a cached answer depends on into its key.

Related: Suppressing bad email addresses without killing live ones.

Originally published at tuanleanh.com.