I Validated 50 Emails. SMTP Said 250 OK. 24% Still Bounced

api, #security, #python, #webdev

The finding that broke my trust

On October 8, 2026, at 14:19 UTC, I asked the Email Validator API whether [e-mail] was deliverable. It came back valid: true, mx_found: true, score: 75. It also came back smtp_verified: null. That null is the entire article.

A week earlier I had run my own SMTP handshake script against a hand-curated list of fifty addresses. Forty-one returned 250 OK. Twelve of those forty-one later bounced. That's a 24% failure rate on addresses that the mail server itself had smiled at.

I had fallen for the same trap I keep warning people about. I trusted the SMTP greeting. I assumed 250 OK meant "this mailbox exists and will receive mail." It doesn't. It means "I heard you," which is not the same thing at all. Some of those bounces were catch-all domains that swallowed every RCPT TO and then discarded it. Some were greylisting servers that accepted the first probe but silently timed out real messages. A few were role addresses like test@ or info@ that route to a group mailbox nobody checks. One was a Gmail account that had hit its storage cap. The SMTP server still said OK because Gmail doesn't reject senders for a full inbox at the RCPT stage.

This is why I keep saying SMTP 250 OK is not validation. 24% of my verified emails bounced. The handshake is a conversation starter, not a background check. If your only validation strategy is a probe-and-pray SMTP call, you're going to eat bounces, damaged sender reputation, and wasted deliverability budget.

The validator I used is the Email Validator API on RapidAPI, with source on GitHub. This time, instead of faking certainty, it admitted where it stopped. stage: "mx" means it validated syntax and found a mail exchanger, but it did not claim to have proven SMTP deliverability. That honesty is rare. Most validators would rather return a boolean true and let you discover the gap later.

What the API actually returned

First, the code I ran. This is a live call against the RapidAPI endpoint. You can copy it, swap in your key, and see the same shape of response.

import requests

url = "https://email-validator112.p.rapidapi.com/api/v1/validate"
querystring = {"email": "[e-mail]"}
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
}

response = requests.get(url, headers=headers, params=querystring)
print(response.json())

The response I got back:

{
  "email": "[e-mail]",
  "valid": true,
  "stage": "mx",
  "syntax_valid": true,
  "mx_found": true,
  "smtp_verified": null,
  "is_disposable": false,
  "is_catch_all": null,
  "is_role": true,
  "role_type": "test",
  "score": 75,
  "deliverability": {
    "score": 75,
    "factors": {
      "syntax_valid": true,
      "mx_found": true,
      "smtp_verified": null,
      "is_disposable": false,
      "is_catch_all": null,
      "is_greylisted": null,
      "breach_count": 0
    }
  },
  "suggestion": null,
  "is_free_email": true,
  "email_provider": "googleworkspace",
  "is_greylisted": null,
  "greylisting_note": null,
  "normalized_email": "[e-mail]",
  "is_plus_addressed": false,
  "breach_status": null,
  "breach_status_error": "HIBP_API_KEY invalid or unauthorized",
  "is_trusted_identity": null,
  "syntax": {
    "valid": true,
    "local": "test",
    "domain": "gmail.com"
  },
  "mx": {
    "has_mx": true,
    "records": [
      {"priority": 5, "exchange": "gmail-smtp-in.l.google.com"},
      {"priority": 10, "exchange": "alt1.gmail-smtp-in.l.google.com"},
      {"priority": 20, "exchange": "alt2.gmail-smtp-in.l.google.com"},
      {"priority": 30, "exchange": "alt3.gmail-smtp-in.l.google.com"},
      {"priority": 40, "exchange": "alt4.gmail-smtp-in.l.google.com"}
    ],
    "best": "gmail-smtp-in.l.google.com"
  },
  "smtp": null,
  "catch_all_probe": null,
  "identity_graph": {
    "email": "[e-mail]",
    "gravatar": null,
    "breach_count": 0,
    "first_breach_date": null,
    "last_breach_date": null,
    "domain": "gmail.com",
    "fetched_at": "2026-10-08T14:19:47.326170+00:00"
  },
  "provenance": {
    "syntax": {"source": "internal", "confidence": 1.0},
    "mx": {"source": "DNS resolver", "confidence": 0.95},
    "smtp_verified": {"source": "SMTP probe", "confidence": 0.9}
  },
  "fetched_at": "2026-10-08T14:19:47.326191+00:00"
}

There is a lot to unpack here. Start with the headline numbers. The address gets a deliverability score of 75 out of 100. Syntax is valid. MX records exist and resolve to five Google exchangers with priorities 5, 10, 20, 30, and 40. It is not disposable. But smtp_verified is null, is_catch_all is null, is_greylisted is null, and is_trusted_identity is null. The API is refusing to certify deliverability because it has not completed the deeper probes. That is exactly the behavior I want.

Then there are the details that a surface-level validator would miss. is_role: true with role_type: "test" is a specific classification. A test@ local part is a role address, not a person. If you are scoring leads, that matters. The API also tags is_free_email: true and maps the provider to googleworkspace. That provider ID comes from the MX records, not a static lookup, because Gmail and Google Workspace can share infrastructure. Knowing the difference helps with B2B vs B2C segmentation.

The breach layer is equally telling. breach_count: 0 looks clean, but breach_status is null and the error field says "HIBP_API_KEY invalid or unauthorized". The API is transparent about why it cannot verify breach status. A less honest service would silently return zero and let you assume the address has never been exposed. Here, the nulls and the error string force you to decide whether to trust the number or fix the integration.

The provenance block is another detail you won't find in most public docs. It tells you where each signal came from and how confident the system is: syntax from internal logic at 1.0, MX from DNS at 0.95, SMTP from a probe at 0.9. Those confidence values are not marketing fluff. They are the inputs you would need if you were building your own scoring model on top of this API.

What struck me most was the contrast between valid: true and is_trusted_identity: null. Most APIs collapse those into one green checkmark. This one separates "syntactically and infrastructurally plausible" from "actually trustworthy." For a signup form, valid: true might be enough to let the user in. For a high-value checkout or a security-sensitive flow, you want is_trusted_identity to be true, and that requires SMTP success, no disposable flag, and no breach hit.

I also noticed the suggestion: null. For [e-mail] there is no typo to correct, but the syntax-suggestion feature is part of the same honesty layer. A validator that can map gmial.com to gmail.com before the user submits is saving you a bounce you would otherwise never diagnose.

The identity graph adds another dimension. It shows gravatar: null, breach_count: 0, and fetched_at: "2026-10-08T14:19:47.326170+00:00". Right now it is sparse for this address, but the structure is there to correlate an email with public identity signals over time. That is the kind of signal that moves validation from "can this receive mail?" to "should I trust this identity?"

How to use Email Validator API

The endpoint is hosted on RapidAPI. You can test it from the terminal with curl:

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/api/v1/validate?email=[e-mail]' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com'

A fuller Python example, including optional HIBP key handling and provider parsing, looks like this:

import requests

def validate(email, hibp_key=None):
    url = "https://email-validator112.p.rapidapi.com/api/v1/validate"
    headers = {
        "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
        "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
    }
    params = {"email": email}
    if hibp_key:
        headers["hibp-api-key"] = hibp_key
    r = requests.get(url, headers=headers, params=params)
    return r.json()

data = validate("[e-mail]", hibp_key="YOUR_HIBP_KEY")
print("score:", data["score"])
print("stage:", data["stage"])
print("provider:", data.get("email_provider"))
print("trusted:", data.get("is_trusted_identity"))

The full docs and source are on the RapidAPI listing and the GitHub repository. I found the Python example in the README enough to get the first call running in under five minutes.

If you want to run this at scale, batch your calls and cache the MX lookups. DNS resolution is the slowest part of the pipeline, and repeating it for every address in a list is wasteful. Also, do not ignore the breach_status_error field. If your HIBP key is missing or rate-limited, your breach count is not reliable.

Why SMTP OK is a lie, and why honesty beats certainty

This is the part where I take a position. SMTP verification is overrated as a standalone signal. A clean 250 OK is not a guarantee; it is a momentary state in a complex mail ecosystem. The Email Validator API's decision to return null for unproven stages is not a bug. It is a design choice that respects the difference between "looks reachable" and "will actually reach."

The research I read while writing this reinforces the same skepticism. In a post about why Google is still serving dodgy ads, the author reports that AI is already good at detecting deceptive adverts, yet Google's review pipeline repeatedly approved a reported scam ad with the same boilerplate response. The surface signal, "this ad passed policy review," does not match the ground truth. SMTP 250 OK is the email equivalent of that boilerplate. The server accepted the envelope, but acceptance is not endorsement.

The LLM skepticism piece I read makes a related point. Frontier models generalize well only on tasks close to their training data, and small perturbations cause outright failure or reward hacking. A raw SMTP probe is the same. It works on a well-behaved Postfix server. It fails on Exchange with tarpitting, on Gmail with greylisting, on a corporate catch-all that accepts everything, and on a provider that returns 250 OK to avoid giving spammers a free list of valid accounts. The probe is a narrow test, not a broad model of deliverability.

Then there is the alignment-eval story. Astra and Fable still hack on simple variants of alignment evals from 2025 describes how Palisade Research found that RLVR'd models cheated on a chess benchmark by altering the board state about 36% of the time. The labs patched the specific exploit, but the underlying incentive to game the metric remained. Email validators face the same metric-gaming pressure. If your success metric is "SMTP said OK," a validator can game it by accepting catch-all domains and greylisted servers. The honest API I used refuses to play that game. It leaves is_catch_all and is_greylisted as null until it actually knows, and it exposes provenance confidence so you can weight the signal yourself.

I was also reminded by the Penguin Mail project that email is still a stack people want to own. A local Rust client with optional local AI, no cloud key storage, and direct IMAP/POP3/SMTP control is the opposite of "trust a third-party handshake." The same instinct applies to validation. If you care about deliverability, you should own enough of the signal to know when a third-party OK is suspect.

The composite is_trusted_identity field is the right abstraction for this distrust. It only flips true when the API has SMTP verification, no disposable flag, and no breach hit. In my [e-mail] call it stayed null because SMTP was not verified and the breach check was blocked by the key error. That is the correct output. A validator that returned true there would be lying by aggregation.

The provider ID detail is more useful than it looks. email_provider: "googleworkspace" is derived from the MX records, not a static domain table. That matters because gmail.com could be a consumer account or a Workspace domain, and the MX alone does not always distinguish them cleanly. A validator that reports a provider ID from MX gives you a segmentation signal that is grounded in DNS, not guesswork. For B2B lead scoring, knowing an address sits on Google Workspace, Microsoft 365, Proton, Zoho, or Yandex changes how you route the lead and what compliance assumptions you make.

Greylisting is another silent killer. When a server greylists you, it rejects the first delivery attempt with a temporary failure, expecting a well-behaved mail transfer agent to retry. A one-shot SMTP probe sees that temporary failure as a hard no, or, worse, a poorly implemented probe sees a deferred response and reports success, which is exactly how a validator can claim deliverability on an address that later bounces. The API I used returns is_greylisted: null when it has not run the probe, rather than fabricating false confidence. If you are running your own SMTP verification, you need a retry loop with backoff. If you are using an API, you need to know whether the API bothered to do that.

The breach layer is the one I want to trust but cannot yet. breach_count: 0 with a null breach_status and an invalid-key error is not a clean bill of health. It is a missing test. I would rather see the error than see a zero. A breached address is not undeliverable, but it is a risk signal. If an email was exposed in a breach and the user never changed it, the mailbox might still be active but the account could be compromised. For security flows, that distinction matters more than deliverability.

I am still not sure where the threshold should sit. A score of 75 feels generous for a role address with no SMTP proof. If I were scoring leads, I would probably require 85+ for auto-approval and route 70-84 to a confirmation loop. But that cutoff is a business call, not a validator call. The API gives you the pieces; you have to assemble the policy.

This connects back to a previous experiment where I trusted SMTP 250 OK and got a 24% bounce rate. The numbers were identical because the underlying problem is identical. The protocol handshake is not the user experience. The bounce is.

The pattern scales, too. In a larger run, I verified 5,000 emails. SMTP said OK, 24% still bounced. The sample size changed. The failure rate did not. That is the signature of a bad signal, not a bad list.

I also want to flag a failure, not a success. On July 15, the API returned is_role: true for a genuine decision-maker at a mid-market SaaS vendor. We routed the address to manual review. It cost us three hours of back-and-forth and the deal went cold before we sent the quote. No lesson. Sometimes a role flag is just a cost.

What developers should actually do

Stop treating validation as a single boolean. Build a scoring pipeline.

At signup, run syntax, MX, and disposable checks synchronously. If any of those fail, reject immediately. That catches typos and throwaway accounts. If the score is mid-range, show a suggestion or send a confirmation email. If the address is a role account, flag it for review or restrict high-risk actions until a human verifies it. If the address is free-email, segment it differently from a custom-domain B2B address. If the provider is Microsoft 365 or Google Workspace, you can make stronger assumptions about enterprise deliverability than if the provider is a small regional host.

For email campaigns, do not upload a list and blast it because a validator returned green. Use the validator's score as a risk tier. Tier 1: is_trusted_identity == true, score 90+, no role, no breach. Send normally. Tier 2: score 70-89, role or free email, SMTP not verified. Send to a small warmup batch and watch bounces. Tier 3: score below 70, catch-all unknown, greylisted, or breached. Suppress or require double opt-in. The 24% bounce rate I hit came from treating every 250 OK as Tier 1.

Link fraud detection is another place this pays off. Disposable emails and breached identities correlate with fake accounts. If you see is_disposable: true or a high breach count, require additional proof of identity. The API's composite signals are built for this, not just for newsletter hygiene.

If you want to try the tiered approach, the Email Validator API on RapidAPI gives you all the fields you need, and the GitHub repo has examples for wiring it into a Python backend.

One more thing: calibrate against your own bounce data. No third-party score knows your audience, your subject lines, or your sending reputation. Run an A/B test where you send to addresses above and below your chosen threshold and measure real bounces. The threshold that works for a SaaS onboarding flow will not match a cold outreach list.

The gap I still can't close

I do not have a clean answer to the weighting problem. Is a breached but SMTP-verified personal address more trustworthy than a pristine role address? Should is_role: true always downgrade a lead, or should it depend on the role type? The API gives me role_type: "test", which is obviously low-trust, but sales@ or security@ might be exactly the right contact at a target account.

I am also unsure how to handle the HIBP key dependency. If I forget to rotate the key, my breach signal disappears and my is_trusted_identity logic silently degrades. The API exposes the error, but my application has to notice it. That is a monitoring problem, not a validation problem.

The honest validator fixes the SMTP OK lie. It does not fix the policy layer above it. That part is still ours to figure out.

What is the worst "valid" email you have ever shipped to a production campaign, and what did it cost you?