SMTP 250 OK is not proof of deliverability: 24% bounce rate on verified emails

A developer who pre-verified 50 recipient addresses with plain SMTP handshakes — every one returning 250 OK — watched a quarter of the resulting campaign bounce anyway. The incident is documented in two dev.to posts by the same author published about an hour apart on September 19, and together they form a compact case study in why an accepted envelope is not the same thing as a delivered message.

On July 15 the author queued mail to fifty addresses that had each passed a handshake check. Three hours later, twelve had bounced — a 24% failure rate on recipients the logs had marked as healthy.

What a 250 response actually proves

According to the write-ups, the misunderstanding starts with the scope of the SMTP 250 status code. It confirms that the receiving mail server accepted the RCPT TO command — the envelope — and nothing more. It does not establish that the mailbox exists, that a human reads it, or that the provider will not filter, throttle, or silently discard the message after accepting it. The author notes that free providers such as Gmail are particularly aggressive on this front: mail is accepted at the protocol layer, then handled by anti-spam systems the sender never sees.

What a deeper check found

The author then ran the same list through a commercial validation API (email-validator112 on RapidAPI) that inspects MX behaviour, breach history, role-account flags, and provider identity. The result for [email protected] illustrates the gap. The address returned valid: true, working MX records, and a composite deliverability score of 75 — yet smtp_verified was null, is_role was true with role_type "test", and breach status recorded 579 appearances in breach data.

Two details stand out. The response's stage field said "mx", meaning the validator itself stopped at MX resolution and never ran an SMTP probe — the null is a skipped test, not a failed one. Separately, is_catch_all and is_greylisted were also null, which the author reads as "untested" rather than "safe". A run of indeterminate fields is itself a warning that a bare handshake check has no way to express.

Catch-alls, greylisting and role accounts

Catch-all domains accept every local part, so a fabricated address and a real one look identical in the logs; detecting the pattern requires probing several random local parts and comparing responses, which a single check cannot do. Greylisting answers a first probe with a 4xx temporary deferral that can masquerade as a soft bounce or a timeout. Role accounts such as test@, support@ and admin@ often accept mail that nobody reads, and the author reports that role-style addresses were over-represented among the twelve bounces.

Breach history added another signal. In the author's data, addresses with breach counts above 100 showed higher bounce rates, and heavily breached addresses are more likely to be abandoned, aggressively filtered, or repurposed as spam traps — a direct risk to sender reputation if a campaign lands on one.

A number worth questioning

Even the author treats the 579 figure with suspicion: the API listed only 19 named incidents for the address, and a per-incident count that high for one Gmail address strains credibility. The recommendation is to read it as a directional risk signal rather than a literal total. The two posts also disagree on small details — one frames the 24% failure rate as arriving within 38 minutes while the other says three hours — but they agree on the substance: twelve bounces out of fifty sends on addresses that passed every surface-level test.

Why it matters

For anyone verifying addresses programmatically — signup forms, lead scoring, transactional mail — the lesson is that SMTP was designed for relay, not list hygiene, and 250 OK is used as a validation signal because it is cheap, not because it is correct. A practical pipeline should treat a handshake acceptance as one weak signal among several: syntax, MX behaviour, catch-all probing, greylist handling, role-account detection, provider identity and breach history. Nulls from a validator should be logged as unknowns, not passes, and composite scores need to weight unconfirmed factors heavily enough that an address like [email protected] — reachable-looking, role-flagged, breach-heavy — does not sail through at 75 out of 100. The author has published code on GitHub to reproduce the checks.