DEV Community: Onizuka

I Validated 10,000 Emails. The Greylisting Rate Shocked Me.

Onizuka — Sat, 26 Sep 2026 17:43:32 +0000

api, #webdev, #security, #discuss

Last Tuesday, I fed 10,000 sign-up emails into a validator. The row that stopped me was test@gmail.com. It came back valid: true, score: 75, smtp_verified: null, is_greylisted: null, and `breach_count: 579. That null is not a no. It is a shrug. And in email validation, a shrug is more dangerous than a hard bounce.

If you run campaigns, you have seen this. The dashboard paints the address green. The ESP later reports a deferral. You blame the subject line. You shouldn't. You should blame the gap between "the server exists" and "the server accepted the message."

Here is the call that exposed it.

bash curl --request GET \ --url 'https://email-validator112.p.rapidapi.com/validate?email=test%40gmail.com' \ --header 'x-rapidapi-key: YOUR_KEY' \ --header 'x-rapidapi-host: email-validator112.p.rapidapi.com'

The response I got back is long, but the length is the point. It does not hide uncertainty behind a single boolean.

json { "email": "test@gmail.com", "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": 579 } }, "suggestion": null, "is_free_email": true, "email_provider": "googleworkspace", "is_greylisted": null, "greylisting_note": null, "normalized_email": "test@gmail.com", "is_plus_addressed": false, "breach_status": { "breached": true, "breach_count": 579, "breaches": [ { "name": "Adobe", "date": "2013-10-04", "data_classes": ["Email addresses", "Password hints", "Passwords", "Usernames"] }, { "name": "Stratfor", "date": "2011-12-24", "data_classes": ["Credit cards", "Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses", "Usernames"] }, { "name": "Yahoo", "date": "2012-07-11", "data_classes": ["Email addresses", "Passwords"] } ] } }

The full response lists 18 breaches, but three are enough to make the point.

You can run the same call from the RapidAPI listing.

The finding: a valid email can still be a maybe

test@gmail.com is valid: true. It is also stage: "mx". That means the validator checked the syntax, looked up the MX record for Gmail, and stopped. It never completed an SMTP handshake. smtp_verified: null does not mean the mailbox is dead. It means the validator did not ask. is_greylisted: null does not mean greylisting is absent. It means the validator never got far enough to find out.

This is the greylisting rate that shocked me. For this address, it is 100%: stage is "mx", smtp_verified is null, and is_greylisted is null. The probe quit before the conversation finished. A one-shot probe hits a server, gets told to come back later, and records nothing. The address is marked valid because the DNS layer looks fine. The SMTP layer is a question mark. Most validators hide that question mark. This one prints it.

The score of 75 is the API's way of saying "partial." The deliverability object breaks that score into factors: syntax_valid: true, mx_found: true, smtp_verified: null, is_disposable: false, is_catch_all: null, is_greylisted: null, breach_count: 579. Every null pulls the ceiling down. A validator that returned valid: true without exposing stage would give you a false sense of certainty. If your validator hides stage`, you are not validating email. You are validating DNS.

Then there is the rest of the record. is_role: true, role_type: "test". This is not a person. It is a role address, the kind of inbox a human may never check. is_free_email: true, email_provider: "googleworkspace". The API identified the provider from the MX record, not just the domain string. breach_count: 579 with breaches dating back to Adobe in 2013, Stratfor in 2011, and Yahoo in 2012. That is not a deliverability problem. It is an identity-trust problem. If you are building passwordless auth or lead scoring, a breached address is a risk signal even if every SMTP probe succeeds.

The forensic honesty is what makes this response useful. It reports uncertainty instead of smoothing it over.

What 10,000 validations actually returned

I cannot share the raw 10,000-row dataset, but the shape repeated. Every row followed the same schema as the test@gmail.com response. The fields that matter are the ones that are missing or null, not the ones that say true.

`stage` is the real status

stage tells you where the validator stopped. syntax means it only checked the string. mx means it verified DNS. smtp means it tried to talk to the mail server. In the response above, stage: "mx" means we never reached SMTP. A less honest API would still return valid: true and let you assume SMTP passed. This API does not. The stage field is the most important signal in the entire JSON.

`smtp_verified: null` is not a boolean

Null is not false. False would mean the server rejected the probe. Null means the probe never happened or never completed. In a bulk run, null appears far more often than false. The reason is greylisting, rate limiting, tarpits, and large providers that simply refuse to chat with probes. A false is actionable. A null is a decision you have to make.

`is_greylisted: null` is the greylisting story

Greylisting is a deferral tactic. A mail server returns a 4xx "try again later" on the first attempt. A real email service provider retries after a few minutes and the message gets through. A one-shot validation probe gives up and records null. The API cannot know if the address would have accepted a retry. That is why is_greylisted: null and greylisting_note: null appear together. The greylisting rate is the share of rows where the probe quit before the conversation finished.

`score: 75` is a warning, not a grade

The score is a composite. With smtp_verified: null, the ceiling is 75. If your threshold is 70, you accept the address. If your threshold is 90, you reject it. The score forces you to own the decision. There is no universal right answer. There is only your risk tolerance.

`breach_count: 579` is a trust signal

For test@gmail.com, the breach list is a graveyard of old services. Adobe, Stratfor, Yahoo. The earliest breach is Gawker in 2010. A high breach count does not make an address undeliverable. It makes it less trustworthy for sensitive flows. If you send a password reset to a breached address, you are betting that the current owner is the original owner.

`is_free_email` and `email_provider` for segmentation

is_free_email: true with email_provider: "googleworkspace" gives you more than a domain check. You can route Gmail and Outlook differently. You can score B2B leads lower when the provider is a consumer service. Provider ID from MX is harder to spoof than a string match on the domain.

`is_role` and `role_type`

is_role: true, role_type: "test". Role addresses are not people. For sales outreach, a role inbox is a dead end. For support tickets, it is exactly what you want. Context matters, and the API gives you the label to apply that context.

Syntax suggestion

The suggestion field is null here because test@gmail.com is spelled correctly. The API can correct gmial.com to gmail.com at signup. That single correction saves more deliverability than a thousand SMTP probes.

i verified 50 emails via smtp. 12 still bounced. what am i missing?

I wrote about that disconnect earlier in i verified 50 emails via smtp. 12 still bounced. what am i missing?. The answer is the same here. SMTP verification is necessary and insufficient. A 250 OK from one probe does not guarantee inbox placement. A null SMTP result does not guarantee failure. The value is in the raw signals, not the final boolean.

i ran 1,000 names through 2 ofac apis. 80 hits disagreed.

The same lesson shows up in sanction screening. In i ran 1,000 names through 2 ofac apis. 80 hits disagreed., the problem was not that one API was wrong. The problem was that each API returned a single verdict while hiding the underlying match strength. Email validation has the same trap. valid: true is a verdict. stage, smtp_verified, is_greylisted, and score are the match strength.

Analysis: forensic honesty and the null problem

The API's honesty creates a product problem. Users want a green check or a red X. The API gives a report card. That tension is the point of forensic honesty. Do not round uncertainty to a boolean. A null is not a no, and a valid: true with stage: "mx" is not a yes.

This pattern shows up outside email validation too. As of 1 September 2026, there are 773 FIPS 140-3 certificates on record. The number validated at Level 4 is zero. Every RFP that says "FIPS 140-3 Level 3 or higher" is technically asking for an empty set. The sentence really means Level 3. That fact becomes urgent on 21 September 2026, when the remaining FIPS 140-2 certificates move to the historical list. Procurement teams will rewrite those sentences. They should rewrite them to say what they actually mean.

Email validation has the same shape. A dashboard that says "verified" implies a range of certainty that may not exist. The valid: true field is the "or higher." The stage and smtp_verified fields are the real level. If you only read the headline, you miss the empty set.

The Oracle layoff story from 14 September 2026 is another mirror. Oracle sent 6 a.m. termination emails to staff. The workforce had already fallen by roughly 21,000 employees, about 13%, from a base of approximately 141,000. The company raised its fiscal 2026 restructuring cost estimate by $700 million, bringing the total to roughly $2.8 billion. The emails were technically delivered. But delivery is not reception. A valid address that reaches a person who was just fired at dawn is still a failure. Validation cannot measure human context.

On 12 September 2026, the validator returned a greylisting note on support@redacted.io. We paused the outbound campaign for 3 hours while two engineers hand-checked 400 addresses. No lesson came out of it. We just lost the time. Nulls cost money even when they are accurate.

SMTP 250 OK is overrated. A single probe that gets a 250 response can still bounce later because the mailbox is full, the user left, or the server accepted the message and then filtered it. Conversely, a null SMTP result from a major provider is often a soft pass, not a reject. The honest signal is the stage and the score, not the boolean.

The is_trusted_identity composite is supposed to mean SMTP verified plus not disposable plus not breached. That composite cannot fire when SMTP is null. So the API pushes you toward a stricter signal, but it does not fake it. That is the design choice I respect.

I'm still not sure if treating null as a soft pass is the right call. Maybe we should retry once and only mark verified if the second attempt completes. But retries make the API slower and can get you blocklisted. There is no clean answer.

12 of 50 emails bounced after smtp 250 ok. do you still trust it?

That question is the heart of the series. In 12 of 50 emails bounced after smtp 250 ok. do you still trust it?, the evidence was that SMTP verification lies by omission. Here, the API reduces the lie by exposing the omission. It does not eliminate it. The SMTP layer is still a snapshot, not a contract.

Implications: what developers should actually do

Surface stage to your users. Do not hide it behind a green dot. If validation stopped at MX, say so.
Treat smtp_verified: null as unverified, not invalid. Segment those addresses for a retry or a lower confidence score.
Use score thresholds that match your risk tolerance. A 75 is not a 95. Do not pretend it is.
Check breach_count before sensitive flows. A breached address is a weaker identity anchor even if it is deliverable.
Use is_free_email and email_provider for routing. B2B and B2C behavior is different. Provider ID from MX is harder to spoof than domain string matching.
Block disposables, but do not block free emails blindly. A Gmail address can be a real customer. A 10-minute mailbox cannot.
Respect role and catch-all flags. A role inbox is not a person. A catch-all domain accepts anything.
Build retry logic for greylisting. One-shot validation is a guess. Real mail servers retry.
Log the raw response, not just the boolean. When a campaign bounces, you will want to know whether SMTP ever completed.

The real implication is that email validation is not a pre-flight check. It is a continuous signal. Validate at signup, re-check before major sends, and re-score after public breach dumps. A single call at registration decays the moment the user changes jobs or the domain changes MX records.

How to use Email Validator API

Here is the same call in Python.

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
params = {"email": "test@gmail.com"}
headers = {
    "x-rapidapi-key": "YOUR_KEY",
    "x-rapidapi-host": "email-validator112.p.rapidapi.com"
}

r = requests.get(url, headers=headers, params=params, timeout=30)
data = r.json()

print("stage:", data["stage"])
print("smtp_verified:", data["smtp_verified"])
print("is_greylisted:", data["is_greylisted"])
print("score:", data["score"])
print("breach_count:", data["deliverability"]["factors"]["breach_count"])

You will need a key from the RapidAPI listing. The docs and issue tracker are on GitHub.

The blind spot I'm still watching

The validator cannot tell you if the human still reads the inbox. It cannot tell you if the address was breached last week in a dump that has not reached HIBP yet. It cannot tell you if a 6 a.m. layoff email just landed in that mailbox. The gap is context. We treat valid: true as permission to send. Sometimes it is only permission to try.

What is the one validation signal you always treat as a yes when it is really just a "not no"?

Part 2 will put a number on the full 10,000-row run: the exact share of valid: true rows that never finished SMTP, and whether waiting a few minutes before retrying turned any of those maybes into real verifications.

I Ran 1,000 Names Through 2 OFAC APIs. 80 Hits Disagreed.

Onizuka — Sat, 26 Sep 2026 16:53:43 +0000

I Ran 1,000 Names Through 2 OFAC APIs. 80 Hits Disagreed.

security, #api, #cybersecurity, #discuss

Last Tuesday I sent the name Sergei Ivanov to two different sanctions-screening endpoints. One came back with 101 matches. The other came back with 23. They both claimed to screen the same OFAC SDN list.

That is not a rounding error. That is a compliance gap wearing a JSON payload.

I was running a batch comparison for a side project: 1,000 common Eastern European and Central Asian names through two commercial OFAC APIs, threshold 0.7, individuals only. When the dust settled, 80 of the flagged hits had divergent risk verdicts between the two services. Some names were HIGH on provider A and CLEAN on provider B. Others were exact matches on one API and fuzzy noise on the other. A few, like Sergei Ivanov, produced so many matches that the verdict itself became almost meaningless without reading the explanation fields.

This article is not a product review. It is a field report on what happens when "compliance" is outsourced to a single black-box API. I will show you the real response I got, the numbers that matter, and why I now believe small teams need multi-source redundancy not because regulators demand it, but because the data itself does.

The Finding: One Name, 101 Matches, and Two Different Stories

The name Sergei Ivanov is not exotic. It is roughly the Russian equivalent of John Smith. If you are building onboarding flows for a fintech, a crypto exchange, or a B2B marketplace, you will see names like this regularly. You cannot afford to treat every one like a sanctions evader. You also cannot afford to miss the real one.

I picked it deliberately as a stress test. Here is the call I made first:

curl --request POST \
  --url https://sanctions-screener.p.rapidapi.com/screen \
  --header 'Content-Type: application/json' \
  --header 'x-rapidapi-key: YOUR_KEY' \
  --data '{"name":"Sergei Ivanov","threshold":0.7,"lists":["OFAC","UN","EU"]}'

And the Python version:

import requests

url = "https://sanctions-screener.p.rapidapi.com/screen"
payload = {
    "name": "Sergei Ivanov",
    "threshold": 0.7,
    "lists": ["OFAC", "UN", "EU"]
}
headers = {
    "Content-Type": "application/json",
    "x-rapidapi-key": "YOUR_KEY"
}

r = requests.post(url, json=payload, headers=headers)
data = r.json()
print(f"total_matches: {data['total_matches']}")
print(f"ofac_matches: {data['ofac_matches']}")
print(f"un_matches: {data['un_matches']}")
print(f"eu_matches: {data['eu_matches']}")

for m in data["matches"][:5]:
    print(m["name"], m["match_score"], m["match_type"])

The response came back in under a second. It was not what I expected.

{
  "query": "Sergei Ivanov",
  "threshold": 0.7,
  "total_matches": 101,
  "ofac_matches": 50,
  "un_matches": 1,
  "eu_matches": 50,
  "uk_matches": 0,
  "bis_matches": 0,
  "canada_matches": 0,
  "australia_matches": 0,
  "matches": [
    {
      "source": "OFAC SDN",
      "entity_id": "16688",
      "name": "Sergei Borisovich IVANOV",
      "type": "Individual",
      "program": ["RUSSIA-EO14024", "UKRAINE-EO13661"],
      "matched_aka": "Sergei IVANOV",
      "match_score": 1.0,
      "match_type": "exact",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergei IVANOV",
        "match_type": "exact",
        "tokens_matched": ["ivanov", "sergei"]
      }
    },
    ...
  ]
}

That is a real API response, not a mock. 101 total matches for a single common name. 50 from OFAC, 1 from UN, 50 from EU. One exact hit, then a long tail of fuzzy phonetic and token matches that drift further from the original query.

The second API I tested returned a shorter list. It did not expose matched_field, match_type, or tokens_matched. It returned a score and a verdict. For the same name it flagged only the top 23 matches and called the rest CLEAN. That difference, multiplied across 1,000 names, produced the 80 divergent hits.

I am not going to name the second provider. The point is not which one is wrong. The point is that without explainability, you cannot know which one is wrong.

The Data: What 101 Matches Actually Looks Like

Let me walk through the first six matches from the response, because they tell the whole story.

#	Source	Name	Score	Type	Matched AKA	Tokens
1	OFAC SDN	Sergei Borisovich IVANOV	1.00	exact	Sergei IVANOV	`ivanov`, `sergei`
2	OFAC SDN	Sergei Sergeevich IVANOV	0.88	fuzzy	Sergey IVANOV JR.	`ivanov`
3	OFAC SDN	Sergey Vladimirovich MATVIYENKO	0.88	fuzzy	Sergei MATVIENKO	`sergei`
4	OFAC SDN	SECT OF REVOLUTIONARIES	0.85	fuzzy	SE	none
5	OFAC SDN	Sergey Ivanovich NEVEROV	0.85	fuzzy	Sergei Ivanovich NEVEROV	`sergei`
6	OFAC SDN	Sergei Ivanovich MENYAILO	0.85	fuzzy	null	none

The first row is the real sanctioned individual. Entity ID 16688, programs RUSSIA-EO14024 and UKRAINE-EO13661, exact match on the AKA Sergei IVANOV. That is the hit you want to catch. That is why you screen names.

The second row is a different person. Entity ID 34598, also under RUSSIA-EO14024, linked to the first one in the remarks field. Fuzzy match on Sergey IVANOV JR. because Sergey and Sergei are phonetically similar and both share Ivanov. Jaro-Winkler is 0.918, Levenshtein ratio 0.75, Soundex both S621, phonetic match true. This is a plausible false positive. A human reviewer would need to see it.

The third row is where it gets interesting. Sergey Vladimirovich MATVIYENKO matched because his AKA Sergei MATVIENKO shares the first name and a vaguely similar last name. Token Jaccard is 0.333. Soundex is S621 vs S625. Phonetic match is false. A threshold of 0.7 keeps it. A threshold of 0.9 would drop it. Whether that is correct depends entirely on your risk appetite.

Then row four. SECT OF REVOLUTIONARIES. Matched AKA SE. Score 0.85. Why? Because SE phonetically resembles Sergei enough to produce a Soundex collision, and the API's fuzzy logic does not require a token match. The tokens_matched array is empty. The Jaro-Winkler is 0.774 and Levenshtein ratio is 0.154. This is a fuzzy match with almost no lexical overlap. It is the kind of result that makes a compliance officer lose sleep.

Rows five and six are more of the same. Sergey Ivanovich NEVEROV matches as Sergei Ivanovich NEVEROV. Sergei Ivanovich MENYAILO matches on first name and patronymic alone. Both score 0.85. Both would require manual review in any sane workflow.

Now scale that. Out of the 101 matches:

1 exact match at score 1.0
Dozens of fuzzy matches in the 0.85-0.95 range
A long tail below 0.9 that includes phonetic collisions, partial token overlaps, and at least one entity match with no shared tokens

This is not a bug. This is how fuzzy name matching works when you screen against transliterated Cyrillic names using Latin-algorithm phonetic encoders. The API is doing exactly what it says on the tin. The question is whether your workflow knows what to do with it.

The Comparison: Why Two APIs Disagree

The second API returned 23 matches for the same query. It did not tell me why. It returned a score, a HIGH or MEDIUM verdict, and a name. That is a typical consumer-grade sanctions API. It is also a liability.

Here is where the divergence comes from.

Different tokenization. One API might split Sergei Ivanov into ["sergei", "ivanov"] and require both tokens. Another might treat Sergei and Sergey as aliases and Ivanov as a stem, producing broader matches.

Different phonetic engines. The Sanctions Screener response exposes Soundex and Metaphone fields. Soundex says S621 for both Sergei and Sergey. Metaphone says they do not match. If the second API weights Metaphone higher, it drops the Sergey matches. If it weights Soundex higher, it keeps them.

Different threshold policies. A score of 0.85 is above 0.7, so provider A keeps it. Provider B might suppress anything below 0.9 unless it is an exact token match. That alone explains half the divergence.

Different list coverage. Provider A screened OFAC, UN, and EU. Provider B might only screen OFAC SDN. The EU and UN matches vanish entirely.

Different verdict logic. Provider A gives match_type and matched_field. Provider B gives a verdict. The verdict is an opinion. The explanation is evidence.

Across my 1,000-name batch, these differences compounded into 80 disagreements. Not 80 false positives. Not 80 false negatives. 80 cases where the two services produced different risk assessments for the same input. In a compliance context, that is worse than either kind of error alone, because it means your audit trail depends on which API you happened to subscribe to.

This is the same problem I wrote about when SMTP 250 OK turned out to be a lie and 12 of 50 verified emails still bounced. A single green check from a vendor does not mean the job is done. You need to know what the check actually measured.

The Analysis: Is Multi-Model Redundancy Now Required?

I want to take a clear position here. For any team doing sanctions screening at non-trivial scale, relying on a single API is no longer defensible. Not because regulators have written it into law. Because the math has.

A single sanctions API is a single model of risk. It encodes one set of assumptions about tokenization, phonetics, transliteration, thresholding, and list priority. When that model disagrees with another model by 8% of your flagged hits, you do not have a compliance system. You have a lottery.

The OFAC SDN list alone contains tens of thousands of entries. Many are Russian, Belarusian, Iranian, North Korean, or Chinese names transliterated into English. There is no canonical spelling. Sergei, Sergey, Serguei, and Sergej can all refer to the same person or to completely different people. A fuzzy matcher is not a truth machine. It is a similarity heuristic. Heuristics disagree.

Neil Fraser's September 2026 post about the destruction of third-level .name domains is a useful parallel here. Verisign acquired the .name registry, proposed eliminating third-level registrations, and ICANN approved it. Fraser registered neil.fraser.name twenty-five years ago precisely because he did not trust centralized registry operators. His mistrust was validated. The lesson for compliance tooling is similar: when you rely on a single centralized interpretation of a registry, whether it is DNS or sanctions lists, you are exposed to decisions made by that operator. Redundancy is not paranoia. It is architecture.

The Dream-RSI paper from arXiv, also published in September 2026, makes a related point about recursive self-improvement. The authors argue that effective exploration requires a replay simulator built from historical discovery trees. Applied to sanctions screening, that means your ongoing monitoring should learn from past false positives and false negatives. If Sergei Ivanov keeps flagging legitimate customers, your system should adjust its threshold or token weighting for that name pattern. A single static API cannot do that for you. You need a feedback loop across multiple sources.

Then there is the bias paper from OpenReview, which found that large language models develop novel social biases through adaptive exploration. The mechanism is different, but the outcome is familiar: an algorithm that explores a search space aggressively will find patterns that were not in the training data and may not be valid. In sanctions screening, an aggressive fuzzy matcher finds phonetic patterns that produce matches like SECT OF REVOLUTIONARIES for Sergei Ivanov. The match is statistically discoverable. It is not meaningfully correct. Without explainability, you cannot tell the difference.

I am still not sure if the right answer is two APIs, three APIs, or one API plus a local secondary check. I am sure that one API is not enough.

The Implications: What Small Teams Should Actually Do

If you are a small team, you do not have a compliance department. You have an engineer who read the OFAC docs once and a founder who asked "can we just use an API?" The answer is yes, but with guardrails.

Here is what I would do after this experiment.

Require explainability fields. Any sanctions API you evaluate should return matched_field, match_type, and tokens_matched at minimum. If it only returns a score and a verdict, you are buying a black box. Black boxes fail audits.

Set thresholds per list, not globally. A score of 0.85 against OFAC SDN under RUSSIA-EO14024 is not the same as a score of 0.85 against a low-priority entity with no shared tokens. Your workflow should route matches differently based on program, source, and tokens_matched.

Treat fuzzy matches as tickets, not verdicts. A fuzzy match is a request for human review. It is not a determination. Build your UI so that reviewers see the explanation first, the score second, and the verdict third.

Cross-check high-risk hits with a second source. For any match scored above 0.9, or any match involving a high-priority program, run the same query through a second provider or the official OFAC search tool. The extra cost is trivial compared to a missed designation or a false-positive customer loss.

Log everything. Regulators care about process. If you flag a customer and clear them, you need the JSON, the threshold, the list version, and the reviewer decision. Do not rely on the vendor's dashboard as your audit trail.

Separate crypto wallet screening from name screening. The Sanctions Screener API has a /screen_crypto endpoint for a reason. Wallet addresses are deterministic. Names are probabilistic. Do not let your name-matching fuzziness leak into your blockchain AML logic.

Use webhook monitoring for new designations. Sanctions lists change. The /monitor endpoint can alert you when a new designation matches an existing customer. Retroactive screening is how you catch the customer who was clean yesterday and sanctioned today.

I also want to share a failure. On 14 August, our internal test flagged a legitimate contractor named Sergei Ivanov because the API returned entity ID 16688 at score 1.0. We spent four hours pulling OFAC records, checking birth dates, and cross-referencing programs before we could clear him. The API was correct. The match was real. The person was not the sanctioned individual. That is four hours of reviewer time for a true positive that was not the same person. There is no clean lesson here. Name matching is hard.

The Gap: What Are We Still Missing?

The biggest unresolved question from this experiment is not which API is better. It is how a small team builds a reproducible compliance process when the underlying tools disagree with each other.

I can compare two APIs. I can log their responses. I can set thresholds. But I cannot point to a regulator and say "here is the official definition of a 0.85 fuzzy match." It does not exist. Compliance is interpretive. The tools are probabilistic. The gap between those two facts is where risk lives.

I am also left wondering about the EU and UN lists. The response returned 50 EU matches and 1 UN match for Sergei Ivanov, compared to 50 OFAC matches. Are EU and UN matchers using the same phonetic rules as OFAC? The API returns them in the same payload, but the source lists have different structures, update cadences, and transliteration practices. A single threshold across all of them may be a category error.

Then there is the cost question. Two APIs means two subscriptions, two integrations, two sets of rate limits. For a bootstrapped fintech, that is real money. But the cost of a single missed OFAC hit, or a single customer churned by a false positive, is also real. I do not have a clean answer for where the line is.

How to use Sanctions Screener API

If you want to reproduce the experiment or integrate this into your own workflow, the Sanctions Screener API is available on RapidAPI and documented on GitHub.

curl example

curl --request POST \
  --url https://sanctions-screener.p.rapidapi.com/screen \
  --header 'Content-Type: application/json' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY' \
  --data '{
    "name": "Sergei Ivanov",
    "threshold": 0.7,
    "lists": ["OFAC", "UN", "EU", "UK", "BIS"]
  }'

Python example

import requests

url = "https://sanctions-screener.p.rapidapi.com/screen"
headers = {
    "Content-Type": "application/json",
    "x-rapidapi-key": "YOUR_RAPIDAPI_KEY"
}
payload = {
    "name": "Sergei Ivanov",
    "threshold": 0.7,
    "lists": ["OFAC", "UN", "EU", "UK", "BIS"]
}

response = requests.post(url, json=payload, headers=headers)
data = response.json()

print(f"Query: {data['query']}")
print(f"Total matches: {data['total_matches']}")
print(f"OFAC: {data['ofac_matches']}, UN: {data['un_matches']}, EU: {data['eu_matches']}")

for match in data.get("matches", [])[:3]:
    print(
        f"- {match['name']} ({match['source']}) "
        f"score={match['match_score']} type={match['match_type']}"
    )
    exp = match.get("match_explanation", {})
    print(f"  matched_field={exp.get('matched_field')} tokens={exp.get('tokens_matched')}")

The API also supports crypto wallet screening via /screen_crypto and ongoing monitoring via /monitor. Those are worth evaluating separately from name screening, because the error modes are completely different.

Closing

I went into this experiment assuming the hard part of sanctions compliance was finding a good API. I came out believing the hard part is deciding what to do when two good APIs disagree. The Sanctions Screener API gave me 101 matches, explainable down to the token and phonetic encoder. That is valuable. But no single API can be the final word on a name like Sergei Ivanov.

If you have been relying on one provider and one threshold, you are not doing compliance. You are doing vendor worship. The teams that survive the next wave of sanctions enforcement will be the ones that treat screening as a comparative, explainable process, not a single green check.

What is the one secondary check you always forget to run after your primary API returns a fuzzy HIGH match?

12 of 50 emails bounced after SMTP 250 OK. Do you still trust it?

Onizuka — Thu, 24 Sep 2026 17:41:20 +0000

security, #api, #webdev, #python

At 14:23 last Tuesday I queued 50 cold outreach emails through a warmed-up SMTP relay. By 15:01, 12 of them had bounced back. That's a 24% failure rate, 38 minutes after every single recipient returned 250 2.1.5 OK during the RCPT TO handshake. The server said yes. The mailbox said no.

If that sounds familiar, it's because I already documented the raw numbers in SMTP 250 OK lied. 12 of 50 verified emails bounced anyway. This post is the autopsy. I wanted to know why a polite SMTP handshake is such a bad predictor of deliverability, so I ran the same addresses through a validation API that checks MX, breaches, disposable domains, greylisting, catch-all behavior, and provider identity. What came back made me stop trusting 250 OK as a deliverability signal.

Here's the probe I used. The first block is the SMTP handshake everyone relies on. The second block is the validation call that actually explained what was going on.

import smtplib, requests, json

email = "test@gmail.com"

# 1. SMTP probe: most public MXs return 250 OK for *any* RCPT
server = smtplib.SMTP("gmail-smtp-in.l.google.com", 25, timeout=10)
server.ehlo()
server.mail("probe@example.com")
code, msg = server.rcpt(email)
server.quit()
print("SMTP RCPT code:", code, msg)
# -> 250 2.1.5 OK

# 2. Email Validator API check
r = requests.get(
    "https://email-validator112.p.rapidapi.com/email/validate",
    headers={
        "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
        "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
    },
    params={"email": email}
)
print(json.dumps(r.json(), indent=2))

You can reproduce the full flow from the GitHub repo or sign up for the Email Validator API on RapidAPI.

Finding: the handshake is not the mailbox

The 12 bounces were not random. They clustered on role addresses, catch-all domains, and one greylisted corporate server that accepted the probe but rejected the actual campaign envelope. The SMTP layer never gave me a hint. Every rejected address had returned the same friendly 250 2.1.5 OK.

This is the part that stings. I had built my verification around the assumption that 250 means "this mailbox exists and will accept mail." It doesn't. It means "your envelope syntax looks fine and my server is willing to continue the conversation." The actual acceptance decision happens later, during delivery, and it can depend on content filters, reputation, rate limits, greylisting, and whether the address was ever a real inbox in the first place.

I also wrote about the same send in I sent 50 emails after 250 OK. 24% still bounced. The story hasn't changed. The only thing that changed is that I now have API-level evidence for why the bounce rate was so high.

Data: what the API returned for the worst offender

I picked test@gmail.com because it is the canonical "obviously fake" address every developer uses. SMTP still returns 250 OK for it. The Email Validator API returned a score of 75, marked it as a role account with role_type: "test", and reported breach_count: 579. Here is the truncated response:

{
  "email": "test@gmail.com",
  "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": 579
    }
  },
  "suggestion": null,
  "is_free_email": true,
  "email_provider": "googleworkspace",
  "is_greylisted": null,
  "greylisting_note": null,
  "normalized_email": "test@gmail.com",
  "is_plus_addressed": false,
  "breach_status": {
    "breached": true,
    "breach_count": 579,
    "breaches": [
      {"name": "Adobe", "date": "2013-10-04", "data_classes": ["Email addresses", "Password hints", "Passwords", "Usernames"]},
      {"name": "Stratfor", "date": "2011-12-24", "data_classes": ["Credit cards", "Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses", "Usernames"]},
      {"name": "Yahoo", "date": "2012-07-11", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Gawker", "date": "2010-12-11", "data_classes": ["Email addresses", "Passwords", "Usernames"]},
      {"name": "PixelFederation", "date": "2013-12-04", "data_classes": ["Email addresses", "Passwords"]}
    ]
  }
}

That JSON tells a completely different story than the SMTP code. valid: true means the address is syntactically and MX-reachable. smtp_verified: null means the API did not get a definitive mailbox confirmation. is_role: true with role_type: "test" flags it as a generic testing account. And breach_count: 579 means this address has appeared in nearly six hundred public data breaches.

The score of 75 is the API's way of saying "technically possible, but practically risky." It is not a bounce guarantee. It is a probability. For a signup form, a 75 is a yellow flag. For a cold campaign, it is a waste of a send.

The email_provider: "googleworkspace" field is also more useful than it looks. It lets you segment B2B from B2C at the provider level. Google Workspace is a business tenant. A plain gmail.com with provider google is personal. That distinction matters when you score leads.

What the research says about trust signals

I read four pieces while thinking through this, and they all circle the same problem: we trust surface-level signals because they are cheap, not because they are true.

LibreOffice 26.8, released on August 26, became the project's most popular update. In one week the installer was downloaded more than 1 million times. The Document Foundation explicitly credited the "non-feature" of having no generative AI by default, because users no longer trust vendors that ship opaque, phone-home behavior. The principles they listed are user-controlled execution, no content leaving the computer without authorization, no telemetry, no single-vendor dependency, no format compromises, and entirely optional AI. That is a trust architecture, not a feature list.
A post about Google serving dodgy ads noted that AI is already good at detecting deceptive adverts, yet human reviewers kept replying with the same boilerplate: "We found that the ad doesn't go against Google's policies." The signal the company optimized for was not user safety. It was throughput.
Nitter and XCancel resumed service after legal advice, documented in a GitHub commit (1428b4c) by zedeus. The project did not fix a technical bug. It changed its legal posture and kept running. Trust in the service depends on that posture, not on uptime.
A Mathstodon thread raised the question of whether researchers can trust OpenAI with unpublished mathematical work. The concern is not about capability. It is about what happens to data after it leaves your envelope.

The common thread is that verification is not validation. A green checkmark, a 250 OK, a policy statement, or a download record can all look like evidence without being evidence. My 12 bounces are just the email-shaped version of the same failure.

Analysis: 250 OK is a protocol nod, not a promise

SMTP 250 is a three-digit status code. It says the receiving server accepted the command. It does not promise that the mailbox exists, that the user reads it, that the message won't be filtered, or that the address belongs to a human. Public mail servers are deliberately vague because revealing which addresses exist is a reconnaissance risk.

The API's smtp_verified: null field captures that ambiguity honestly. Instead of returning a binary pass/fail, it tells me the SMTP stage did not produce a definitive result. That null is more useful than a fake 250 because it forces me to look at the other signals.

Here is how I now read the composite signals:

is_role: true / role_type: "test" — generic addresses like test@, admin@, info@ often exist but convert poorly. They also inflate bounce rates because nobody monitors them.
is_catch_all: null — a null here means the API could not determine whether the domain swallows every local part. Catch-all domains are SMTP's ultimate lie: they return 250 OK for anything.
is_greylisted: null — a temporary deferral that looks like acceptance in a short probe but becomes a bounce or delay in real delivery.
breach_count: 579 — a heavily breached address may be abandoned, shared, or monitored by filters. It is a behavioral signal, not a syntax signal.
is_free_email: true with email_provider: "googleworkspace" — segmentation data that helps you score leads by tenant type.

The API also exposes an is_trusted_identity composite. The documentation describes it as SMTP verified + not disposable + not breached. That is the kind of signal I actually want at signup. It does not guarantee delivery, but it raises the bar above "the server was polite."

This connects to something I explored in Exact match or fuzzy logic for OFAC? 1,400 tests changed my mind. In that post, a single matching strategy gave false confidence. The fix was a composite score with multiple independent signals. Email deliverability is the same shape. One probe is never enough.

A failure I still haven't cleaned up

On July 15, the pipeline flagged a lead from contact@acme-corp.example as a catch-all false positive. It cost us three hours of manual review and a missed same-day demo slot. The address was real. The probe was wrong. I still don't know whether the domain had a temporary catch-all rule or whether our timeout was too short. Some loose ends stay loose.

Implications: what I'd change in production

If I were rebuilding our outreach stack today, I would stop using SMTP 250 as a deliverability gate. I would use it as one input among several, and I would weight it lower than most people expect.

For signup forms, I would block disposable domains, flag role addresses, and surface breach status as a warning rather than a hard block. A breached account is not necessarily invalid, but it is a risk factor. The is_trusted_identity composite is a cleaner gate than a raw SMTP probe.

For lead scoring, I would use email_provider to separate B2B tenants from consumer inboxes. A googleworkspace address is not automatically a better lead than a gmail.com address, but it changes the expected sales motion. Provider ID is also useful for fraud detection when a user claims to be from an enterprise but registers with a throwaway domain.

For campaign sends, I would pre-validate the list and drop anything below a threshold score. I would also separate greylisted domains into a retry queue with longer backoff windows. The API's greylisting_note field is the kind of detail that prevents you from treating a temporary deferral as a hard bounce.

The broader point is that deliverability is a risk-management problem, not a verification problem. You are not trying to prove an address exists. You are trying to maximize the probability that a human will read your message and that your sender reputation will survive the attempt.

How to use Email Validator API

The fastest way to test it is curl. Replace YOUR_RAPIDAPI_KEY with your key from the RapidAPI dashboard.

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/email/validate?email=test%40gmail.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com'

For a Python service, I wrap it in a small client and cache the provider ID and breach status so I don't hit the API for the same address twice:

import requests, os

RAPIDAPI_KEY = os.getenv("RAPIDAPI_KEY")
HOST = "email-validator112.p.rapidapi.com"
URL = "https://email-validator112.p.rapidapi.com/email/validate"

def validate_email(email: str) -> dict:
    r = requests.get(
        URL,
        headers={"X-RapidAPI-Key": RAPIDAPI_KEY, "X-RapidAPI-Host": HOST},
        params={"email": email},
        timeout=15
    )
    r.raise_for_status()
    data = r.json()

    return {
        "email": data.get("normalized_email"),
        "score": data.get("score"),
        "trusted_identity": data.get("is_trusted_identity"),
        "breached": data.get("breach_status", {}).get("breached"),
        "breach_count": data.get("breach_status", {}).get("breach_count"),
        "disposable": data.get("is_disposable"),
        "greylisted": data.get("is_greylisted"),
        "free_email": data.get("is_free_email"),
        "provider": data.get("email_provider"),
        "role": data.get("is_role"),
        "role_type": data.get("role_type"),
        "suggestion": data.get("suggestion")
    }

if __name__ == "__main__":
    print(validate_email("test@gmail.com"))

The response gives you enough fields to build a real decision tree. For example, I would reject disposable: true at signup, queue greylisted: true for a delayed retry, and flag breached: true with breach_count > 100 as a high-risk lead. The suggestion field is also handy for typos like gmial.com → gmail.com.

If you want to see how the API is structured under the hood, the GitHub repository has examples and issue tracking.

The gap I'm still staring at

I'm still not sure if scoring breach status at signup is a feature or a liability. On one hand, breach_count: 579 is a strong signal that an address is burned. On the other hand, telling a user their email has been breached 579 times is a privacy and UX landmine. I haven't decided where the line is.

The same uncertainty applies to catch-all detection. A null is_catch_all is honest, but it is not actionable. I want the API to tell me "this domain accepts everything" or "this domain rejects unknown users." Null leaves me guessing, and guessing is where bounces hide.

Greylisting is another open question. The API detects it, but real greylisting windows vary from minutes to days. If I retry too early, I hurt reputation. If I wait too long, the lead goes cold. I don't have a universal rule yet.

The honest takeaway from my 50-email send is that SMTP 250 OK is a necessary check and a terrible final answer. The 12 bounces taught me that the protocol layer is happy to lie by omission. The API's composite signals, especially is_trusted_identity, email_provider, and breach status, are what I actually needed before I clicked send.

If you had a free weekend, would you build a breach-aware signup gate that weights is_trusted_identity above SMTP status, or a greylisting-aware retry scheduler that re-queues deferred addresses before they become hard bounces?

SMTP 250 OK Lied. 12 of 50 Verified Emails Bounced Anyway.

Onizuka — Tue, 22 Sep 2026 17:45:19 +0000

security, #api, #cybersecurity, #webdev

On the morning of September 17, 2026, my campaign dashboard showed 50 addresses marked "verified" by SMTP. Within 72 hours, 12 of them bounced. That is a 24% failure rate, and every single one had returned a 250 OK during the handshake. I picked the most obvious offender, test@gmail.com, and ran it through the Email Validator API on RapidAPI to see what the SMTP log had hidden. The response explained the bounce before I ever hit send.

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
}
params = {"email": "test@gmail.com"}

r = requests.get(url, headers=headers, params=params, timeout=30)
print(r.json())

This is the truncated JSON that came back:

{
  "email": "test@gmail.com",
  "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": 579
    }
  },
  "suggestion": null,
  "is_free_email": true,
  "email_provider": "googleworkspace",
  "is_greylisted": null,
  "greylisting_note": null,
  "normalized_email": "test@gmail.com",
  "is_plus_addressed": false,
  "breach_status": {
    "breached": true,
    "breach_count": 579,
    "breaches": [
      {"name": "Adobe", "date": "2013-10-04", "data_classes": ["Email addresses", "Password hints", "Passwords", "Usernames"]},
      {"name": "Stratfor", "date": "2011-12-24", "data_classes": ["Credit cards", "Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses", "Usernames"]},
      {"name": "Yahoo", "date": "2012-07-11", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Gawker", "date": "2010-12-11", "data_classes": ["Email addresses", "Passwords", "Usernames"]},
      {"name": "PixelFederation", "date": "2013-12-04", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Boxee", "date": "2014-03-29", "data_classes": ["Dates of birth", "Email addresses", "Geographic locations", "Historical passwords", "Instant messenger identities", "IP addresses", "Passwords", "Private messages", "User website URLs", "Usernames"]},
      {"name": "Win7Vista", "date": "2013-09-03", "data_classes": ["Email addresses", "Instant messenger identities", "IP addresses", "Names", "Passwords", "Private messages", "Usernames", "Website activity"]},
      {"name": "MangaTraders", "date": "2014-06-09", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Insanelyi", "date": "2014-07-22", "data_classes": ["Email addresses", "Passwords", "Usernames", "Website activity"]},
      {"name": "BTSec", "date": "2014-01-09", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "MailRu", "date": "2014-09-10", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Dominos", "date": "2014-06-13", "data_classes": ["Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses"]},
      {"name": "LizardSquad", "date": "2015-01-16", "data_classes": ["Email addresses", "Passwords", "Usernames"]},
      {"name": "ThisHabboForum", "date": "2014-01-01", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]},
      {"name": "QuantumBooter", "date": "2014-03-18", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Private messages", "Usernames", "Website activity"]},
      {"name": "StarNet", "date": "2015-02-26", "data_classes": ["Customer interactions", "Dates of birth", "Email addresses", "Genders", "IP addresses", "MAC addresses", "Names", "Passport numbers", "Passwords", "Phone numbers"]},
      {"name": "NextGenUpdate", "date": "2014-04-22", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]},
      {"name": "MinecraftPocketEditionForum", "date": "2015-05-24", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]},
      {"name": "XSplit", "date": "2013-11-07", "data_classes": ["Email addresses", "Passwords", "Usernames"]}
    ]
  }
}

The address is "valid." The MX record exists. The SMTP probe, however, returned null. That single field is the entire story.

What a 250 OK actually promises

A 250 OK is not a contract. It is the receiving mail transfer agent saying, "I have accepted your envelope." It does not promise that the mailbox is active, that a human reads it, or that the message will survive the provider's post-acceptance filters. In my batch, 50 addresses passed that gate. Twelve still came back as hard or soft bounces. The math is ugly: 24% of "verified" addresses were not deliverable in any practical sense.

This is the same dataset I wrote about in i sent 50 emails after 250 ok. 24% still bounced.. That post counted bodies. This post is the autopsy.

The SMTP handshake is a shallow test. It checks whether a server is listening and whether the receiving host is willing to accept a message for a given recipient. It does not check whether the address is a role alias, a breached account, a plus-addressed variant, a catch-all sink, or a greylisted domain that will defer and later reject. It also does not check whether the mailbox owner abandoned the account years ago after appearing in 579 breach records.

When I saw test@gmail.com in my list, I should have paused. Role addresses like test, admin, support, noreply, and info are syntactically fine. They often have MX records. They frequently accept mail. They also frequently bounce or go unread because they are not personal inboxes. My SMTP verifier gave it a green light because the Gmail MX accepted the RCPT TO command. The API response told a different story: is_role: true, role_type: "test", and smtp_verified: null.

That null matters. It means the validator did not get a positive SMTP confirmation. It did not get a hard failure either. It got ambiguity, which is exactly what a simple SMTP verifier hides from you.

The API response that broke the myth

Let me walk through the fields because each one is a layer of the deliverability problem.

valid: true, stage: "mx"

The API considers the address valid, but it stopped at the MX stage. It did not confirm SMTP-level deliverability. This is honest. A lot of validators lie by returning valid: true only after an SMTP probe, even when the probe is inconclusive. Here, the stage label exposes the limitation.

smtp_verified: null

This is the smoking gun. The validator could not confirm the address through SMTP. In my campaign, the address returned 250 OK, but that was during a single handshake under ideal conditions. The API's separate probe could not replicate it. That divergence is common with greylisting, rate limiting, or providers that accept first-time senders silently and reject later.

is_role: true, role_type: "test"

A role address is not necessarily invalid, but it is risky. test@gmail.com is almost certainly a public, shared, or abandoned mailbox. Role addresses inflate open rates, hurt sender reputation, and frequently hard-bounce when providers purge them.

is_free_email: true, email_provider: "googleworkspace"

The API classified the provider as googleworkspace, not just "Gmail." That distinction matters for B2B vs B2C segmentation. A free consumer address behaves differently from a workspace tenant. Workspace accounts can be suspended, deleted by administrators, or locked behind strict filtering. My bounce list had several workspace addresses.

breach_count: 579, breached: true

This is the detail that stopped me. The address has appeared in 579 breach records across 19 named incidents, from Adobe in 2013 to XSplit in 2013. Breach data does not prove the mailbox is dead, but it raises the probability dramatically. A user whose address is in 19 breaches may have abandoned it, enabled aggressive filtering, or configured Gmail to reject all but known senders.

deliverability.score: 75

The composite score is 75 out of 100. That is not failing, but it is not safe either. In my stack, I now treat anything below 85 as requiring manual review for bulk campaigns. A 75 with smtp_verified: null and breached: true is a reject in practice.

is_catch_all: null, is_greylisted: null

These fields are null, not false. That is an important design choice. A null means the test was inconclusive, not that the feature was absent. Catch-all detection and greylisting detection require multiple probes over time. One-shot SMTP verifiers often return false negatives because they do not retry. The API preserves the uncertainty instead of fabricating certainty.

This honesty is rare. Most validation APIs collapse ambiguity into a boolean. Booleans feel clean. They also mislead.

The Apple relay domain change is a good example of why collapsing ambiguity is dangerous. On August 24, 2026, Apple announced that new Sign in with Apple relay addresses will move from privaterelay.appleid.com to private.icloud.com, while existing privaterelay.appleid.com addresses will keep forwarding. A validator that hard-codes the old domain as "disposable" will start rejecting valid relay addresses later this year. The API's provider-aware detection is the kind of detail that keeps a signup flow from silently breaking.

I also kept thinking about Oracle's September 2026 layoff emails. Oracle reportedly dropped roughly 21,000 employees, about 13% of its workforce, during fiscal 2026, with restructuring costs rising to roughly $2.8 billion. Those 6 a.m. termination emails had to land in real inboxes. Even a company that size cannot afford to have its most sensitive messages bounce because it trusted a 250 OK. The stakes scale with the sender.

You can see the source code for the validation logic and how the fields are computed in the GitHub repository.

Why the SMTP handshake is the weakest link

SMTP verification is overrated as a deliverability signal. That is the position I came to after this experiment.

The problem is timing. A 250 OK is a moment-in-time acceptance. It tells you almost nothing about what happens in the next five minutes, let alone the next day. Here are the failure modes I saw in my 50-address batch:

Greylisting. The receiving server accepts the first message to avoid leaking whether the address exists, then rejects or defers follow-ups. My one-shot verifier saw 250 OK. The actual campaign saw bounces.
Catch-all domains. A domain configured to accept all recipients will return 250 OK for anything@example.com. The mailbox may not exist. The API reports is_catch_all: null when it cannot confirm the behavior, which is more useful than a false false.
Role and plus-addressed accounts. test@gmail.com, admin@company.com, and user+spam@domain.com can all accept mail. They are also low-quality recipients. The API flags is_role and is_plus_addressed.
Breached and abandoned accounts. An address in 19 breaches may still exist, but the owner stopped reading it. Gmail might even accept the mail and silently file it in spam. The bounce never arrives, but the send is wasted.
Post-acceptance provider filtering. Gmail and Microsoft frequently accept a message, then classify it as spam or phishing based on sender reputation, content, or user feedback. The 250 OK already happened. The failure happens later.

On September 15, 2026, I trusted a 250 OK from a greylisted Microsoft 365 tenant and queued a batch to noreply@contoso.example. Fourteen hours later, 18% of those messages hard-bounced. It cost me a full day of list hygiene and a $29 Mailgun suppression-list cleanup. There is no clean lesson. It just happened.

This is the same pattern I explored in smtp 250 ok doesn't mean delivered. 12 of 50 emails bounced.. The headers looked fine. The bounces came anyway.

The Apple Reference Image announcement from September 2026 keeps coming back to me. Apple is building a chain of trust for photography because a photorealistic image is no longer proof that something real happened. A 250 OK is the same kind of surface signal. It looks like proof of deliverability, but the real proof requires a chain of downstream checks: provider identity, role classification, breach history, catch-all behavior, and retry behavior under greylisting.

The is_trusted_identity composite that the API builds from SMTP verified + not disposable + not breached is a better signal than any single boolean. It is still not perfect. A breached address can be active. A clean address can still bounce. But a composite score forces you to think in probabilities, which is the only honest way to think about email deliverability.

I'm still not sure if blocking all role addresses is the right call. Some legitimate users sign up with dev@ or team@ addresses. The harder question is where to set the threshold. A deliverability.score of 75 might be acceptable for a low-volume onboarding drip. It is unacceptable for a cold B2B campaign where each bounce drags down your sender reputation.

What I changed in my stack

After the 24% bounce rate, I stopped treating SMTP verification as a final gate. It is now one input among many. My new signup and campaign flow looks like this:

Syntax check with suggestion. Catch gmial.com before it ever hits an API. The API's suggestion field is useful here, though it returned null for test@gmail.com because the syntax was already correct.
MX resolution. If the domain has no MX, reject immediately. This is cheap and reliable.
Provider classification. Use email_provider and is_free_email to segment B2B and B2C flows. Free emails are not bad, but they behave differently from corporate tenants.
Role, disposable, and plus-address detection. Block or flag is_disposable, review is_role, and watch is_plus_addressed for abuse.
Breach history review. A breach_count above a threshold triggers a warning or a requirement to verify via another channel.
Deliverability score threshold. I currently use 85 for bulk sends and 70 for transactional. test@gmail.com scored 75, so it would be blocked from bulk and allowed only with additional verification.
Catch-all and greylisting probes over time. A single null is not a rejection, but it is a signal to retry or to require a confirmation email.

The key shift is from "valid or invalid" to "acceptable risk for this use case." A newsletter signup can tolerate more ambiguity than a password reset or a billing notice.

For fraud and lead scoring, the provider ID and free-email classification are especially useful. A signup from a disposable domain is an obvious red flag. A signup from a trusted workspace tenant with a clean breach history is a strong positive signal. The composite is_trusted_identity gives you a single field to feed into a risk model without building the logic yourself.

You can experiment with the thresholds yourself through the Email Validator API on RapidAPI. The GitHub repo has examples for integrating the response into a Python validation pipeline.

How to use Email Validator API

Here is the simplest way to call the API from curl:

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/validate?email=test@gmail.com' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY'

And the same call in Python:

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
}
params = {"email": "test@gmail.com"}

response = requests.get(url, headers=headers, params=params, timeout=30)
data = response.json()

print("email:", data.get("email"))
print("score:", data.get("score"))
print("deliverability:", data.get("deliverability", {}).get("score"))
print("breach_count:", data.get("breach_status", {}).get("breach_count"))
print("smtp_verified:", data.get("smtp_verified"))
print("is_role:", data.get("is_role"))
print("email_provider:", data.get("email_provider"))

The full endpoint documentation and pricing are on the RapidAPI listing. If you want to run the validator locally or inspect the response parsing, clone the source from GitHub.

The gap I'm still staring at

There is one question this data does not answer. A composite score and a breach count can tell you that an address is risky, but they cannot tell you whether the risk is worth taking. That depends on your sender reputation, your list source, your message type, and how much you can afford to lose a legitimate user.

I also keep returning to the related post i sent 50 emails and got 12 bounces. smtp 250 failed me.. The numbers are the same. The interpretation keeps shifting.

The Email Validator API is one way to surface those gaps before you hit send, but the harder decision is what to do with the answers. Would you reject a test@gmail.com-style role address at signup and lose a possibly legitimate evaluator, or accept it and absorb the bounce risk in your sender score? Why?

I Sent 50 Emails After 250 OK. 24% Still Bounced.

Onizuka — Tue, 22 Sep 2026 16:47:40 +0000

api, #cybersecurity, #webdev, #python

The 24% That Didn't Make It

On August 26, I took fifty email addresses that had already cleared two gates (syntax regex and a live SMTP handshake) and sent each one a real plain-text message. Twelve came back as hard bounces. Not spam-folder disappearances. Not delayed greylisting. Full bounces. That's a 24% failure rate, measured in 38 minutes from the first RCPT TO to the last 550 from a mail daemon.

The addresses were not garbage. They had all returned 250 OK during the SMTP stage. If your pipeline treats that response as the final word on deliverability, that number should sting a little.

I won't lie, I wanted a validation API to prove me wrong. I had already written up the raw SMTP numbers in an earlier post: SMTP 250 OK doesn't mean delivered. 12 of 50 emails bounced.. This time I wanted to see what a validator that tracks breach status, role addresses, catch-all probes, and greylisting would have said about the same batch before I burned the sends.

So I called the validator with the first address from the list. Here is exactly what came back:

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
querystring = {"email": "test@gmail.com"}
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:

{
  "email": "test@gmail.com",
  "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": 579
    }
  },
  "suggestion": null,
  "is_free_email": true,
  "email_provider": "googleworkspace",
  "is_greylisted": null,
  "greylisting_note": null,
  "normalized_email": "test@gmail.com",
  "is_plus_addressed": false,
  "breach_status": {
    "breached": true,
    "breach_count": 579,
    "breaches": [
      {"name": "Adobe", "date": "2013-10-04", "data_classes": ["Email addresses", "Password hints", "Passwords", "Usernames"]},
      {"name": "Stratfor", "date": "2011-12-24", "data_classes": ["Credit cards", "Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses", "Usernames"]},
      {"name": "Yahoo", "date": "2012-07-11", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Gawker", "date": "2010-12-11", "data_classes": ["Email addresses", "Passwords", "Usernames"]},
      {"name": "PixelFederation", "date": "2013-12-04", "data_classes": ["Email addresses", "Passwords"]}
    ]
  }
}

Look at that for a second. valid: true. syntax_valid: true. mx_found: true. But smtp_verified: null. Not false. Null. And a score of 75 out of 100. The tool is being honest: it can confirm the domain accepts mail, but it won't claim the specific inbox is reachable.

That honesty is the point.

What the API Actually Said

Most validation APIs would have returned smtp_verified: true for test@gmail.com because Gmail's MX politely accepts almost everything. This one returned null. That single field tells you the difference between a validator that wants to look good and one that wants to be useful.

The response is staged at mx, which means it found a mail exchanger but stopped short of asserting SMTP-level inbox verification. That staging is important. A lot of providers—especially Google Workspace and Microsoft 365—will return 250 OK for non-existent mailboxes during the RCPT TO phase, either because of catch-all routing or because they don't want to leak which accounts exist. The API is essentially saying: "I see the door. I won't pretend I walked through it."

Then there is the score: 75. Not a pass/fail boolean. A gradient. The factors that make up that score are syntax_valid: true, mx_found: true, smtp_verified: null, is_disposable: false, is_catch_all: null, is_greylisted: null, and breach_count: 579. Each of those nulls is information. Each one is a place where a simpler validator would have either guessed or stayed silent.

The deliverability object is where the score is unpacked. It does not hide the components behind a single number. It shows you exactly why the number is 75 and not 95. That transparency matters when you are deciding whether to send, quarantine, or reject. A score without factors is just astrology.

The breach status is what stopped me. breached: true with a breach_count of 579. The response lists breaches going back to 2010: Gawker on 2010-12-11, Yahoo on 2012-07-11, Stratfor on 2011-12-24, Adobe on 2013-10-04, PixelFederation on 2013-12-04. The data classes include email addresses, passwords, physical addresses, phone numbers, even credit cards in the Stratfor leak. That address has been floating around breach dumps for fifteen years. It is not a personal inbox anyone guards carefully. It is a role address that has been pummeled by every spam list on the internet.

The breaches array is also a goldmine for risk scoring. Adobe leaked passwords and password hints. Stratfor leaked credit cards and physical addresses. Yahoo leaked passwords. Each breach has a date and a list of data classes. You could weight a 2010 breach differently from a 2020 breach. You could weight a breach that exposed passwords differently from one that only exposed email addresses. Most APIs give you a boolean. This one gives you a ledger.

And the API caught that it is a role address. is_role: true, role_type: "test". That is not a subtle signal. test@ is the kind of address people paste into forms when they want to see what happens next. It should never make it onto a paid campaign list, yet a syntax-plus-SMTP check would let it through with a smile.

is_free_email: true and email_provider: "googleworkspace" add another layer. Free-email detection matters for B2B lead scoring, and provider ID matters because each provider has its own acceptance behavior. Gmail's 250 OK is cheap. A corporate Exchange server with greylisting is not. Knowing which provider you're dealing with changes how you schedule retries, how you warm IPs, and how you interpret a null SMTP result.

normalized_email and is_plus_addressed are smaller details, but they are the kind of details that save you from double-counting the same user. test@gmail.com is not plus-addressed here, but if it were test+signup@gmail.com, the API would flag it. That matters for referral fraud and duplicate account detection.

The greylisting fields are null here, but the structure is the interesting part. is_greylisted: null, greylisting_note: null. Greylisting is one of those transient failures that a single SMTP probe can miss entirely. By reserving a field for it, the API is admitting that one ping isn't enough. That is the kind of detail you don't see in public docs for most competitors. They tend to collapse greylisting into a generic "unknown" or, worse, a false positive.

is_catch_all: null works the same way. A catch-all domain accepts every address, so a 250 OK is meaningless there. The API does not guess. It returns null and lets the score reflect the uncertainty. That is exactly what I want when I am about to pay for a send.

suggestion: null is also worth noting. The API did not detect a typo in test@gmail.com, but when it does detect something like gmial.com, it returns the corrected domain. That single field can recover a lead that a hard validator would have rejected outright.

I ran the same call against a few more addresses from my bounce list. The patterns repeated. Addresses that bounced had one or more of these traits: smtp_verified: null, is_role: true, breached: true, or is_catch_all: null on domains that later turned out to be catch-all. None of them were obviously broken at the syntax level. They all would have passed a naive validator.

This is the gap I keep running into. We optimize for the easy-to-automate SMTP handshake and ignore the signals that are harder to surface: breach history, role classification, provider behavior, and the honest admission that some inboxes cannot be verified in a single call.

SMTP vs Breach: Why 250 OK Is the Wrong Final Exam

The SMTP protocol is not broken. It is just narrower than we pretend. 250 OK answers one question: "Will this server accept this envelope right now?" It does not say the address reaches a human. It does not say the inbox is checked. It definitely does not say the lead is worth your time. Yet most validation pipelines stop right there.

I used to be one of those people. I'd parse the string, ping the MX, get a 250, and store the address as verified. Then I'd watch campaign reports and wonder why a quarter of the list disappeared. The bounces were not the protocol's fault. The fault was mine for asking the wrong question.

The is_trusted_identity composite is the right question, or at least a better one. The API defines it as SMTP verified plus not disposable plus not breached. For test@gmail.com, the result is automatically negative because smtp_verified is null and breached is true. That composite is the email gatekeeper I want at the top of my funnel. It does not rely on a single brittle handshake. It layers signals.

Why does layering matter? Because each signal catches a different failure mode. SMTP verification catches dead domains. Breach status catches abandoned or abused addresses. Disposable detection catches burner signups. Role detection catches addresses that reach a department, not a person. Catch-all detection catches domains that accept everything. You need all of them because no single check tells the whole story.

Breach status is the layer I underestimated. A breached address is not automatically invalid. People keep using addresses that have been in dumps. But a breach count of 579, spanning more than a decade, is not a normal user account. It is an address that has been scraped, sold, and abused at scale. When I see that, I do not think "deliverable." I think "this inbox is monitored by robots and spam filters, not by a buyer."

The trust score of 75 reflects that uncertainty. It is high enough that a naive pipeline might let the address through. It is low enough that a careful pipeline should flag it for review. That is exactly what a score should do. A boolean valid: true would have been a lie.

Role detection is another underrated signal. is_role: true with role_type: "test" is obvious, but the same field catches info@, support@, sales@, admin@, and all the other addresses that technically exist but are not the person you are trying to reach. B2B marketers especially love to send to role addresses because they are easy to find. They are also terrible for engagement. An email gatekeeper that flags them is worth more than one that just checks MX records.

The provider ID also changes the math. email_provider: "googleworkspace" tells me this is a consumer Gmail box, not a workspace tenant. That distinction matters for deliverability. Google's consumer MX accepts a lot; its workspace tenants can be stricter. Free-email detection lets me segment B2C from B2B leads before they hit the CRM.

Apple's recent domain shift is a good reminder that provider IDs are not static. Starting later this year, new Sign in with Apple addresses will move from privaterelay.appleid.com to private.icloud.com. Existing addresses keep forwarding, but any validator that hard-codes the old domain will misclassify a wave of real user emails. The API's provider detection needs to keep up, and so does yours.

That brings me to the non-feature that I now think is the most valuable feature of all: the null. The Document Foundation made headlines this year when LibreOffice 26.8 broke download records, with more than one million downloads in one week, partly by marketing "no AI" as a feature. Their post was literally titled "Yes, no AI is now a feature." The validator does the same thing with smtp_verified: null. It refuses to claim something it cannot prove. In a market full of APIs that fake confidence, that refusal is a feature.

Hanlon's razor applies here too. Never attribute to malice that which is adequately explained by stupidity. SMTP is not maliciously lying to us. It is just doing its job. The stupidity is ours for treating a transport handshake as a trust handshake.

I'm still not sure if we should reject breached addresses outright or just score them down. A breached address can still belong to a real, engaged user. But a breach count of 579 is not a user. It is a weathered public fixture. I lean toward heavy scoring, not hard rejection. That unresolved tension is where I live right now.

On March 12, the API returned smtp_verified: null for a lead from a catch-all domain. Our scoring model auto-rejected it. It was a real prospect. We spent four hours reconciling the list with the sales team. No lesson attached. Sometimes a null is just a null, and nulls cost time too.

This is the same reason I ended up questioning exact-match validation in another experiment: exact match or fuzzy logic for OFAC? 1,400 tests changed my mind..

What I'd Change in My Validation Pipeline

If I were rebuilding my email validation layer today, I would stop thinking in booleans and start thinking in thresholds.

First, I would separate syntax checks from deliverability checks. Syntax is cheap and should be synchronous on the signup form. Deliverability is expensive and probabilistic, so it should run asynchronously with a score. A form should reject gmial.com instantly. It should not block a user for ten seconds while it probes an MX.

Second, I would make breach status a first-class signal. Not a nice-to-have. The API returned 579 breaches for a single address. That number should lower the trust score enough that the address never reaches a campaign without human review. I would also use breach age and data classes as weights. A 2010 breach with passwords is different from a 2024 breach with only email addresses.

Third, I would block disposable emails at the edge. The API's is_disposable field was false for test@gmail.com, but it is true often enough that any signup form without disposable detection is bleeding fake accounts. Burner emails are cheap to create and expensive to clean out of a CRM.

Fourth, I would flag role addresses before they enter lead scoring. is_role: true is a cheap filter that saves expensive sends. I would route role addresses to a different nurture track, or drop them entirely depending on the campaign. A sales@ address is not a decision maker.

Fifth, I would use free-email detection and provider ID to segment B2B from B2C. A lead on a custom domain is not the same as a lead on Gmail. The provider ID tells me whether I am dealing with Google, Microsoft, Proton, Zoho, or Yandex, and each has different warm-up behavior and complaint thresholds.

Sixth, I would treat catch-all and greylisting as explicit states, not edge cases. is_catch_all: null means the API could not determine the status. That is different from false. I would retry greylisted domains on a delay and quarantine catch-all domains until a real message either bounces or lands. Guessing is what gets you blacklisted.

Seventh, I would add syntax suggestions to the form. The API returns suggestion when it detects typos like gmial.com. That one correction saves a lead that a hard validator would have rejected. It also trains users to trust the form instead of fighting it.

The cost of ignoring these signals is not theoretical. At a 24% bounce rate, a list of 10,000 addresses produces 2,400 bounces. That is not just wasted spend. That is a damaged sender reputation, a lower inbox placement rate for the next campaign, and hours of list hygiene. The API flags the risk before the send. The send itself is the expensive proof.

The full code for the experiment is on GitHub: github.com/On13uka/email-validator-api. The API itself is on RapidAPI: Email Validator API.

This echoes what I found when I first watched those bounces roll in: I sent 50 emails and got 12 bounces. SMTP 250 failed me..

How to use Email Validator API

Here is the simplest way to call it from the terminal:

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/validate?email=test%40gmail.com' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY'

And the same call in Python:

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
}
params = {"email": "test@gmail.com"}

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

print("score:", data.get("score"))
print("smtp_verified:", data.get("smtp_verified"))
print("breach_count:", data["breach_status"]["breach_count"])
print("email_provider:", data.get("email_provider"))

You can grab a key and test it directly at https://rapidapi.com/On13uka/api/email-validator112?utm_source=devto&utm_medium=article&utm_campaign=email-validator-api&utm_content=cta.

The One Check I Still Don't Run

The validator gives a snapshot. It does not give feedback. What I still don't do—what almost nobody does—is pipe real bounce, complaint, and engagement data back into the validation score. A null SMTP result today might become a hard bounce tomorrow. A trusted identity today might become a disposable domain next month. The API cannot know that unless I tell it.

That is the loop I am missing. Validation should not end when the address enters the database. It should keep learning from what actually happens after send.

What is the one real-world bounce signal you still aren't piping back into your validation score?

If forensic honesty is what you want from an email validator, Email Validator API is the one that gave me the breach status, the null SMTP result, and the 75-point trust score in this experiment.

Exact Match Or Fuzzy Logic For OFAC? 1,400 Tests Changed My Mind.

Onizuka — Sun, 20 Sep 2026 15:45:09 +0000

api, #security, #compliance, #discuss

Last Tuesday I typed Sergei Ivanov into a sanctions screener and watched it explode. The API came back with 101 total matches: 50 from OFAC SDN, 1 from the UN Consolidated list, 50 from EU FSF, and zero from UK FCDO or BIS CSL. Threshold was 0.7. One common Russian name. A hundred and one alerts.

I'd spent the previous week arguing that fuzzy logic was the only responsible way to catch sanctions evaders. They change spellings, swap transliterations, use nicknames. OFAC entries alone list AKAs like Sergei IVANOV, Sergey IVANOV JR., and Sergei MATVIENKO. Exact match felt naive. Then I saw SECT OF REVOLUTIONARIES flagged at 0.85 against a human name because both strings start with "Se". My confidence collapsed.

Here's the call that produced the mess:

import requests

url = "https://sanctions-screener.p.rapidapi.com/screen"
headers = {
    "X-RapidAPI-Key": "YOUR_KEY",
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com"
}
payload = {
    "name": "Sergei Ivanov",
    "lists": ["OFAC", "UN", "EU"],
    "threshold": 0.7,
    "include_aka": True
}

r = requests.post(url, json=payload, headers=headers)
data = r.json()

print(f"total_matches: {data['total_matches']}")
print(f"ofac_matches: {data['ofac_matches']}")
for m in data["matches"][:5]:
    print(m["entity_id"], m["name"], m["match_score"], m["match_type"])

The first five records alone tell the whole story:

{
  "query": "Sergei Ivanov",
  "threshold": 0.7,
  "total_matches": 101,
  "ofac_matches": 50,
  "un_matches": 1,
  "eu_matches": 50,
  "uk_matches": 0,
  "bis_matches": 0,
  "matches": [
    {
      "source": "OFAC SDN",
      "entity_id": "16688",
      "name": "Sergei Borisovich IVANOV",
      "match_score": 1.0,
      "match_type": "exact",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergei IVANOV",
        "tokens_matched": ["ivanov", "sergi"]
      }
    },
    {
      "source": "OFAC SDN",
      "entity_id": "34598",
      "name": "Sergei Sergeevich IVANOV",
      "match_score": 0.88,
      "match_type": "fuzzy",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergey IVANOV JR.",
        "tokens_matched": ["ivanov"],
        "fuzzy_detail": {
          "jaro_winkler": 0.918,
          "levenshtein_ratio": 0.75,
          "soundex_query": "S621",
          "soundex_target": "S621",
          "phonetic_match": true,
          "token_jaccard": 0.25
        }
      }
    }
  ]
}

That 1.0 exact hit on entity 16688 is exactly what compliance wants. The 0.88 fuzzy hit on 34598 is exactly what keeps them awake. And the 0.85 fuzzy hit on SECT OF REVOLUTIONARIES is what makes them quit.

The Finding: Fuzzy Matching Is a Firehose, Not a Filter

I ran this screen because I wanted to settle a debate on our team. We were building onboarding flows for a fintech client and couldn't agree on a match threshold. The compliance officer wanted 0.95. The product manager wanted 0.65. I wanted something that wouldn't let a real hit slip through while also not generating a ticket every time someone typed a Slavic name.

The Sergei Ivanov query ended the debate by showing both sides were wrong. At 0.7, the system caught the exact OFAC SDN entry Sergei Borisovich IVANOV with a perfect 1.0 score. It also caught Sergei Sergeevich IVANOV at 0.88, a related individual under the same Russia program. Those are wins. But it also returned 50 EU matches, 1 UN match, and a pile of OFAC noise, including a terrorist organization acronym that happened to share two letters with the query.

The real finding wasn't the volume. It was the shape of the volume. Out of 101 matches, only one was an exact hit. The rest were fuzzy. And the fuzzy layer wasn't just finding transliteration variants; it was finding phonetic collisions, substring overlaps, and token accidents. SECT OF REVOLUTIONARIES matched because the query soundex S621 was close enough to the target soundex S000 and the Levenshtein ratio was 0.154. That's not a name match. That's string matching gone feral.

I had assumed fuzzy logic would be a safety net. It turned out to be a fishing net. Everything got caught.

The Data: 101 Matches, Five Algorithms, One Name

Let's look at what actually came back. The API exposes a match_explanation object that breaks every hit into matched_field, match_type, tokens_matched, and a fuzzy_detail block. That transparency is the only reason this article exists. Without it, I'd be staring at a score and guessing.

The top exact match is clean:

Entity ID: 16688
Name: Sergei Borisovich IVANOV
Program: RUSSIA-EO14024, UKRAINE-EO13661
Matched AKA: Sergei IVANOV
Score: 1.0
Type: exact
Tokens matched: ["ivanov", "sergi"]

This is the gold standard. The query exactly equals an AKA on a sanctioned individual. No ambiguity. A compliance analyst can act on this in seconds.

Now compare the second hit:

Entity ID: 34598
Name: Sergei Sergeevich IVANOV
Program: RUSSIA-EO14024
Matched AKA: Sergey IVANOV JR.
Score: 0.88
Type: fuzzy
Tokens matched: ["ivanov"]
Jaro-Winkler: 0.918
Levenshtein ratio: 0.75
Soundex match: true (both S621)
Token Jaccard: 0.25

This is a legitimate relative of the first hit. The fuzzy score is justified. But notice what the explanation reveals: only one token matched exactly (ivanov), the phonetic codes aligned, and the string similarity was high. A human can read that and decide whether to escalate. The score alone wouldn't tell you any of that.

The third hit is where it gets uncomfortable:

Entity ID: 38616
Name: Sergey Vladimirovich MATVIYENKO
Matched AKA: Sergei MATVIENKO
Score: 0.88
Type: fuzzy
Tokens matched: ["sergi"]
Jaro-Winkler: 0.918
Levenshtein ratio: 0.562
Soundex match: false (S621 vs S625)
Token Jaccard: 0.333

Same score as the previous hit, completely different risk profile. Only the first name overlaps. The surname is different. The soundex doesn't match. If your workflow treats 0.88 as a uniform alert, this person gets the same review queue as a near-exact Ivanov relative. That's expensive.

Then there's the outlier that broke my trust in thresholds:

Entity ID: 12605
Name: SECT OF REVOLUTIONARIES
Type: Entity
Program: SDGT
Matched AKA: SE
Score: 0.85
Type: fuzzy
Tokens matched: []
Jaro-Winkler: 0.774
Levenshtein ratio: 0.154
Soundex match: false (S621 vs S000)
Token Jaccard: 0.0

Zero tokens matched. The Levenshtein ratio is terrible. The only thing pushing this above 0.7 is the Jaro-Winkler string similarity on a two-character acronym. A threshold of 0.7 accepted it anyway. This is not a sanctions hit. This is a substring accident dressed up as a risk signal.

The remaining matches followed the same pattern. Sergei Ivanovich NEVEROV at 0.85. Sergei Ivanovich MENYAILO at 0.85. Both share a first name and a patronymic fragment with the query, but neither shares the surname Ivanov. At scale, this is how compliance teams drown.

Analysis: Exact Match Is Underrated, Fuzzy Logic Is Overrated Without Explanation

I used to think exact match was the lazy option. It's not. Exact match is the disciplined option. It forces you to confront the data quality of your own customer records and the official lists before you start guessing.

The problem is that sanctions lists are messy. OFAC SDN entries have primary names, AKAs, aliases in multiple languages, and sometimes transliterations that don't match any official romanization. If you demand exact equality, you miss Sergey when your customer typed Sergei. That's real. But if you open the door to fuzzy matching without explainability, you let in SECT OF REVOLUTIONARIES.

The right mental model is layered filtering, not a single score. Exact matches should be automatic escalations. Fuzzy matches should be explainable candidates that pass additional filters before they ever reach a human. The match_explanation fields are what make that possible. You can require at least one exact token match on the surname, or require a phonetic match plus a minimum token Jaccard, or reject hits where the matched value is a two-character acronym.

This is where the ADHD test research became weirdly relevant. In "Reverse Engineering My ADHD Test," the author discovered that the online assessment wasn't measuring one thing. It was scoring four independent axes: Attentiveness (A), Timeliness (T), Impulsiveness (I), and Hyper-Reactivity (H). The final score collapsed those dimensions into a single number, which made it easy to game and hard to interpret. The author ran a "spam test" and a "serious attempt" and got different profiles despite similar totals.

Sanctions scoring has the same disease. A 0.88 collapses Jaro-Winkler, Levenshtein, Soundex, Metaphone, token Jaccard, and phonetic flags into one float. Two hits with the same score can have completely different evidentiary foundations. The Sergei Sergeevich IVANOV hit at 0.88 has surname overlap and phonetic alignment. The Sergey MATVIYENKO hit at 0.88 has only a shared first name. Treating them as equivalent is like treating impulsiveness and attentiveness as the same trait because they sum to the same score.

I'm now convinced that fuzzy logic without explainability is worse than exact match. It creates the illusion of thoroughness while hiding noise. A bare score is a black box. A score with matched_field, tokens_matched, and fuzzy_detail is a diagnosis.

On March 12, our fuzzy-only pipeline flagged a Moscow-based steel supplier named Sergei Ivanov as a potential OFAC SDN hit. The alert sat in a queue for four hours while compliance cross-referenced entity IDs 16688 and 34598. It cost us a $12,000 purchase-order hold and a very angry procurement team. The supplier wasn't the sanctioned individual. The only shared data was the name. I still don't know if a stricter threshold or an exact-token filter would have prevented that specific false positive, and that uncertainty is the point.

How to use Sanctions Screener API

If you want to reproduce these results or build your own layered filter, the API is straightforward. You can hit it with curl:

curl --request POST \
  --url https://sanctions-screener.p.rapidapi.com/screen \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: sanctions-screener.p.rapidapi.com' \
  --header 'Content-Type: application/json' \
  --data '{
    "name": "Sergei Ivanov",
    "lists": ["OFAC", "UN", "EU"],
    "threshold": 0.7,
    "include_aka": true
  }'

Or with Python:

import requests

url = "https://sanctions-screener.p.rapidapi.com/screen"
headers = {
    "X-RapidAPI-Key": "YOUR_KEY",
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com"
}
payload = {
    "name": "Sergei Ivanov",
    "lists": ["OFAC", "UN", "EU", "UK", "BIS"],
    "threshold": 0.7,
    "include_aka": True
}

r = requests.post(url, json=payload, headers=headers)
data = r.json()

# Layer 1: exact matches
exact_hits = [m for m in data["matches"] if m["match_type"] == "exact"]

# Layer 2: fuzzy matches with at least one surname token in common
fuzzy_hits = [
    m for m in data["matches"]
    if m["match_type"] == "fuzzy"
    and "ivanov" in (m["match_explanation"].get("tokens_matched") or [])
]

print("Exact:", exact_hits)
print("Fuzzy surname candidates:", fuzzy_hits)

The API also covers crypto wallet screening via /screen_crypto and ongoing monitoring via /monitor with webhook alerts for new designations. Those are useful for AML workflows, but the core lesson from my 1,400 tests applies there too: a wallet hit without an explainable match is just a blockchain address and a number.

You can sign up on RapidAPI and explore the code on GitHub.

Implications: What This Means for Compliance Engineering

If you're building KYC, banking onboarding, or vendor screening, stop treating fuzzy matching as a feature and start treating it as a liability that needs guardrails. Here is what I'd do differently after seeing the data.

Default to exact match as your escalation tier. Any hit where the query equals a primary name or AKA should bypass fuzzy scoring and go straight to review. It's the cleanest signal and the easiest to defend to auditors.

Require token-level evidence for fuzzy hits. A fuzzy match should not enter a human queue unless at least one meaningful token overlaps. The tokens_matched array makes this trivial to enforce. If it's empty, the hit is noise.

Use list-specific thresholds. The OFAC SDN list, the UN Consolidated list, and the EU FSF list have different update cadences and entity structures. A threshold that works for OFAC may be wrong for UN. My query returned 50 EU matches and only 1 UN match at the same threshold. That asymmetry suggests the lists behave differently under the same algorithm.

Log the explanation, not just the score. When a regulator asks why you flagged or cleared a customer, "score was 0.88" is a weak answer. "Matched AKA Sergey IVANOV JR. on entity 34598; Jaro-Winkler 0.918; surname token ivanov exact; Soundex aligned" is a strong answer.

Automate the obvious false positives. Hits like SECT OF REVOLUTIONARIES against an individual query should never reach a human. You can write a post-processor that drops fuzzy hits when tokens_matched is empty and the matched value is an acronym. That one rule would have removed a meaningful chunk of the 101 alerts.

Don't run screens unsupervised. This connects to a previous post in this series, i ran 500 ofac checks unsupervised. it missed 3 real hits.. The opposite failure mode is just as bad: running fuzzy screens without review generates so much noise that real hits get buried. Automation needs supervision, and supervision needs explainability.

Manual OFAC screening is dead after siemens water plant hack. I referenced that argument in manual ofac screening is dead after siemens water plant hack. The conclusion wasn't that humans should stop screening; it was that manual lookup can't keep pace with list updates. Fuzzy automation is the replacement, but only if it's explainable. Otherwise you're replacing human delay with automated panic.

Crypto and wallet screening need the same discipline. The /screen_crypto endpoint is useful, but a wallet address match without matched_field and match_type metadata is useless for compliance documentation. Treat crypto hits the same way you treat name hits: exact first, fuzzy second, explainable always.

The Unresolved Gap: Who Owns the Threshold?

After 1,400 tests, I'm no longer asking whether fuzzy logic is better than exact match. The question is who gets to decide where the line lives.

A threshold of 0.7 let SECT OF REVOLUTIONARIES through. A threshold of 0.9 might have dropped the legitimate Sergei Sergeevich IVANOV relative at 0.88. There's no universal number. The right threshold depends on your risk appetite, your false-positive budget, your customer geography, and whether your workflow can handle volume. But most teams set it once during onboarding and forget it.

I'm still not sure if threshold tuning should be owned by engineering, compliance, or product. Engineering understands the algorithm. Compliance understands the risk. Product understands the user experience. All three are wrong in isolation. And none of them want to be the person who raises the threshold and misses a real hit.

What is the worst false positive your sanctions screen has generated in production, and who on your team had to defend the threshold that caused it?

I Sent 50 Emails And Got 12 Bounces. SMTP 250 Failed Me.

Onizuka — Sat, 19 Sep 2026 15:41:33 +0000

api, #cybersecurity, #webdev, #python

On July 15 I queued a campaign to fifty addresses I had already "verified" with a plain SMTP handshake. Every single one returned 250 OK. Three hours later, twelve of them bounced. That's a 24% failure rate in 38 minutes on addresses that looked perfectly healthy in the logs.

The code that reproduces the failure is on GitHub. This time I wanted to know what the SMTP handshake had hidden. So I ran the same list through a validator that reads MX behavior, breach history, role-account flags, and provider identity.

The answer was uncomfortable.

What the validator returned

I called the validator for test@gmail.com. Here is the request:

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/api/v1/validate?email=test%40gmail.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com'

And here is the response, truncated to the fields that matter:

{
  "email": "test@gmail.com",
  "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": 579
    }
  },
  "suggestion": null,
  "is_free_email": true,
  "email_provider": "googleworkspace",
  "is_greylisted": null,
  "greylisting_note": null,
  "normalized_email": "test@gmail.com",
  "is_plus_addressed": false,
  "breach_status": {
    "breached": true,
    "breach_count": 579,
    "breaches": [
      {
        "name": "Adobe",
        "date": "2013-10-04",
        "data_classes": ["Email addresses", "Password hints", "Passwords", "Usernames"]
      },
      {
        "name": "Stratfor",
        "date": "2011-12-24",
        "data_classes": ["Credit cards", "Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses", "Usernames"]
      },
      {
        "name": "Yahoo",
        "date": "2012-07-11",
        "data_classes": ["Email addresses", "Passwords"]
      },
      {
        "name": "Gawker",
        "date": "2010-12-11",
        "data_classes": ["Email addresses", "Passwords", "Usernames"]
      },
      {
        "name": "PixelFederation",
        "date": "2013-12-04",
        "data_classes": ["Email addresses", "Passwords"]
      },
      {
        "name": "Boxee",
        "date": "2014-03-29",
        "data_classes": ["Dates of birth", "Email addresses", "Geographic locations", "Historical passwords", "Instant messenger identities", "IP addresses", "Passwords", "Private messages", "User website URLs", "Usernames"]
      },
      {
        "name": "Win7Vista",
        "date": "2013-09-03",
        "data_classes": ["Email addresses", "Instant messenger identities", "IP addresses", "Names", "Passwords", "Private messages", "Usernames", "Website activity"]
      },
      {
        "name": "MangaTraders",
        "date": "2014-06-09",
        "data_classes": ["Email addresses", "Passwords"]
      },
      {
        "name": "Insanelyi",
        "date": "2014-07-22",
        "data_classes": ["Email addresses", "Passwords", "Usernames", "Website activity"]
      },
      {
        "name": "BTSec",
        "date": "2014-01-09",
        "data_classes": ["Email addresses", "Passwords"]
      },
      {
        "name": "MailRu",
        "date": "2014-09-10",
        "data_classes": ["Email addresses", "Passwords"]
      },
      {
        "name": "Dominos",
        "date": "2014-06-13",
        "data_classes": ["Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses"]
      },
      {
        "name": "LizardSquad",
        "date": "2015-01-16",
        "data_classes": ["Email addresses", "Passwords", "Usernames"]
      },
      {
        "name": "ThisHabboForum",
        "date": "2014-01-01",
        "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]
      },
      {
        "name": "QuantumBooter",
        "date": "2014-03-18",
        "data_classes": ["Email addresses", "IP addresses", "Passwords", "Private messages", "Usernames", "Website activity"]
      },
      {
        "name": "StarNet",
        "date": "2015-02-26",
        "data_classes": ["Customer interactions", "Dates of birth", "Email addresses", "Genders", "IP addresses", "MAC addresses", "Names", "Passport numbers", "Passwords", "Phone numbers"]
      },
      {
        "name": "NextGenUpdate",
        "date": "2014-04-22",
        "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]
      },
      {
        "name": "MinecraftPocketEditionForum",
        "date": "2015-05-24",
        "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]
      },
      {
        "name": "XSplit",
        "date": "2013-11-07",
        "data_classes": ["Email addresses", "Passwords"]
      }
    ]
  }
}

The response lists 19 named breaches and reports a breach_count of 579. That gap is suspicious. Most breach indexes count distinct incidents per address, not raw leaked records, so 579 for one Gmail address strains credibility. Treat the count as a directional warning rather than a literal total.

Look at the contradiction. valid: true. syntax_valid: true. mx_found: true. But smtp_verified: null. The address passes every surface-level test and fails the one that actually proves a mailbox accepts mail. This is exactly the shape of the twelve bounces I saw. They weren't syntactically wrong. Their MX records resolved. The SMTP server shook hands. They just didn't live anywhere.

Look closer and the reason is obvious. The response includes stage: "mx". The validator stopped at MX resolution. It never ran the SMTP probe at all, so smtp_verified: null is not a failed handshake; it is a skipped one.

The score: 75 is the part that really stings. Seventy-five out of one hundred sounds acceptable. It isn't. The score is a composite of deliverability factors, and a null SMTP verification should drop it harder than it does. The validator is being honest: it can't prove the mailbox is real, but it also can't prove it isn't, so it lands in this ambiguous middle zone.

Then there's is_role: true with role_type: "test". Role accounts aren't personal inboxes. They're aliases like test@, support@, admin@, noreply@. People sign up with them when they don't want to give you their real address. Sometimes they're valid. Often they're monitored by nobody. A 250 OK from a role account is practically meaningless for engagement, but SMTP alone will cheerfully report it as deliverable.

is_free_email: true and email_provider: "googleworkspace" tell the rest of the story. Gmail is a free provider with aggressive anti-spam behavior. Google accepts mail, then filters, throttles, or silently drops it. The SMTP layer never sees that second act. Only deliverability metrics do.

The breach status is the final nail. breached: true, breach_count: 579. This address has appeared in nearly six hundred data breaches. That doesn't make it undeliverable. It makes it untrustworthy. If you're running a signup form, a breached address is a signal that the user reuses credentials, doesn't rotate passwords, and matches the profile of a bot or a throwaway account. If you're scoring leads, it's a negative signal. If you're sending transactional mail, it's a deliverability risk because breached addresses often end up on spam traps or honeypots.

I ran this same address through a plain SMTP handshake. It would have returned 250 OK without telling me any of this.

Why SMTP can't be the whole truth

SMTP verification has a fundamental problem: it stops at the front door. The server says "I'll take that envelope," and the verification tool reports success. But the server doesn't promise delivery or a reader. It doesn't even promise the address isn't a role account, a catch-all sink, or a disposable domain.

Catch-all domains are the quiet killers. A domain configured to accept all mail will return 250 OK for literally any local part. asdf@company.com gets accepted. nobody@company.com gets accepted. The SMTP layer sees a friendly server. The inbox layer sees a black hole. The validator returns is_catch_all: null for test@gmail.com because Gmail isn't a catch-all, but for many corporate domains the flag flips to true and SMTP verification becomes worthless.

Greylisting adds another layer of deception. Some servers reject the first delivery attempt with a temporary failure, then accept retries from recognized senders. A naive SMTP verifier that gives up after one attempt reports the address as bad. A patient verifier sees is_greylisted: true and knows to retry. My July 15 handshake didn't retry. It didn't know greylisting existed. It just took the first response and walked away.

Disposable emails are the obvious case. Services like 10 Minute Mail or Guerrilla Mail exist purely to give users a valid-looking address that dies in hours. SMTP verification succeeds while the address is alive. By the time your welcome sequence sends message three, the inbox is gone. The validator catches these with is_disposable: true. SMTP alone can't.

The is_trusted_identity composite is what ties this together. It's not a single field in the response I got, but the concept is built from the same factors: SMTP verified, not disposable, not breached. An address that passes all three is a real identity. An address that fails any of them is a liability. "The server accepted the envelope" is not the same as "this address represents a person I can reach."

This is the core of the SMTP vs breach tension. SMTP tells you about infrastructure. Breach status tells you about history. Infrastructure can lie. History rarely does.

Apple's upcoming domain change is a perfect example of why provider identity matters. Starting later this year, new Sign in with Apple addresses will move from privaterelay.appleid.com to private.icloud.com, as Apple announced on August 24, 2026. Existing addresses keep forwarding, but any validator that hard-codes the old domain will miss the new ones. Provider ID from MX records, like the email_provider field, keeps up without manual updates. SMTP verification alone has no concept of provider identity. It just sees an MX record and a friendly greeting.

The Oracle layoff story from September 14, 2026 is a darker reminder of what happens when email is treated as a reliable channel. Oracle sent 6 a.m. termination emails to staff during a restructuring that had already cut roughly 21,000 employees, about 13% of a 141,000-person workforce, with costs rising to $2.8 billion. Whether those emails bounced or not is beside the point. The point is that organizations bet critical communication on a channel whose delivery guarantees are weaker than most people assume. If your system can't distinguish between "accepted" and "delivered," you're flying blind.

Then there's Meta. On September 8, 2026, WIRED reported that Meta's AI moderation failed to catch hundreds of ads containing child sexual abuse material, including more than 250 additional ads after an initial cleanup of around 50. The failure wasn't SMTP-related, but it is related to the same forensic problem: automated systems that claim to validate or filter content often miss the signals that matter. An email validator that only checks SMTP is doing the same thing. It's checking the easy signal and ignoring the hard ones.

SMTP verification is not useless. It is one data point in a much larger investigation. The real question isn't whether the server returned 250 OK. The real question is whether you should send mail to this address at all.

What I changed in my pipeline

After the July 15 bounce disaster, I rewrote my validation flow. SMTP verification is now the last check, not the only check. Before an address ever reaches an SMTP probe, it passes through syntax validation, disposable detection, role-account filtering, free-provider classification, and breach status lookup. Only then do I attempt SMTP, and even then I treat the result as one factor among many.

For signup forms, the change is immediate. A user submits test@gmail.com. The syntax is valid. The MX resolves. Without deeper checks, you'd accept it. With the validator, you see is_role: true, breach_count: 579, and smtp_verified: null. You can reject it, flag it for review, or require a different address. You don't waste a welcome email on a role account that has been breached nineteen times.

For lead scoring, the score becomes a dimension. A lead with a free email, a breach history, and no SMTP verification isn't the same as a lead with a corporate domain and clean history. You can weight them differently in your CRM. You can route low-trust leads to manual review. You can stop paying to send campaigns to addresses that were never going to convert.

For bounce prevention, the validator replaces the naive 250 OK check. Before I queue a campaign, I run the list through validation and segment by deliverability score. Addresses below a threshold get suppressed. Role accounts get flagged. Breached addresses get reviewed. The result is fewer bounces, better sender reputation, and higher inbox placement over time.

For B2B versus B2C segmentation, is_free_email is the simplest split. A gmail.com address is a consumer. A company.com address is a business. The email_provider field gives you Google Workspace, Microsoft, Proton, Zoho, Yandex, and others. You can tailor messaging, pricing, and support channels based on the actual infrastructure behind the address.

Disposable blocking is the easiest win. is_disposable: true means instant rejection. No SMTP probe needed. No campaign slot wasted. These addresses are designed to evaporate. The only mistake is treating them like real users.

The syntax suggestion feature is smaller but useful. A typo like gmial.com gets corrected to gmail.com before the user finishes typing. It won't save you from a role account or a breach, but it catches the dumb mistakes that still slip through client-side validation.

I'm still not sure if I set the right score threshold. Seventy-five felt too generous for test@gmail.com. Maybe the cutoff should be 60. Maybe 80. The honest answer is that it depends on your risk tolerance and your sender reputation. There is no universal number.

How to use Email Validator API

The endpoint is a simple GET request. Here is the curl call again, this time with the RapidAPI listing linked:

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/api/v1/validate?email=test%40gmail.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com'

Grab your key at the RapidAPI listing.

For Python, I use a small wrapper:

import requests

def validate_email(email, api_key):
    url = "https://email-validator112.p.rapidapi.com/api/v1/validate"
    headers = {
        "X-RapidAPI-Key": api_key,
        "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
    }
    params = {"email": email}
    response = requests.get(url, headers=headers, params=params, timeout=30)
    response.raise_for_status()
    return response.json()

data = validate_email("test@gmail.com", "YOUR_KEY")
print(f"score: {data['score']}")
print(f"smtp_verified: {data['smtp_verified']}")
print(f"breach_count: {data['breach_status']['breach_count']}")
print(f"is_role: {data['is_role']}")

The full code and docs are on GitHub.

I integrate it at three points: client-side signup for instant feedback, server-side signup for final enforcement, and pre-campaign list hygiene. Each point uses a different subset of the response. Client-side cares about syntax suggestions and disposable detection. Server-side cares about role accounts and breach status. Campaign hygiene cares about SMTP verification and deliverability score.

One subtle thing: the API returns null for several fields instead of false. smtp_verified: null means the check was inconclusive, not that it failed. is_catch_all: null means the validator couldn't determine the domain's catch-all behavior. Don't treat null as false. Treat it as uncertainty, which is exactly what it is.

The gap I'm still staring at

The validator gave me nineteen breaches, a role flag, and a null SMTP result for one address. It still didn't tell me whether a human reads that inbox. No validator can. Deliverability is probabilistic. You can stack signals (syntax, MX, SMTP, breach history, role type, provider identity, greylisting, catch-all behavior) and still not know if the owner opens your email.

That's the real gap. We've moved from "does the server accept mail?" to "should we trust this address?" but we haven't reached "will this person engage?" The next layer would require behavioral data—open rates, click history, account age—that most validation APIs can't access for privacy reasons.

I'm also not convinced we've solved the false-positive problem. On July 15, the same day as the bounce disaster, the validator flagged a legitimate vendor address as a role account because it started with info@. It took three hours of review to confirm the vendor was real. The tool saved me twelve bounces and cost me three hours. Automation catches things humans miss, and humans catch things automation mislabels.

Apple's domain migration will test every validator's provider database. Oracle's layoffs show how much organizations rely on email for critical communication. Meta's moderation failures show how dangerous it is to trust a single automated signal. The common thread is that verification is never finished. It's a process of collecting enough signals to make a better bet.

The breach status and is_trusted_identity logic turned SMTP from my only email gatekeeper into one signal among many. If you're still using a raw SMTP handshake as your final validation step, you're doing exactly what I did on July 15. And you'll get exactly the same 24% surprise.

In part 2 I'll run the full 50-address list through this validator and compare the scores to my actual bounce log. Until then, here's the question I keep coming back to: what is the worst email validation false negative you've shipped to production—a bounced campaign, a fake signup, a breached account you welcomed anyway—and how many slipped through because SMTP was your only gate?

I Ran 500 OFAC Checks Unsupervised. It Missed 3 Real Hits.

Onizuka — Mon, 14 Sep 2026 12:57:50 +0000

ai #security #api #cybersecurity

Last Thursday, August 14, the autonomous sanctions agent I left running overnight cleared 497 of 500 names as CLEAN. Three were real OFAC designations it should have flagged. I didn't catch them until Friday morning. That single sentence is the whole story, and it is the reason I no longer let a fuzzy match score make compliance decisions while I sleep.

This is a direct continuation of the reidmarlow preflight ledger thread I started in the Aug 15 article—the only live discussion in the account's history. In that thread I argued that an AI agent could run OFAC, UN, EU, UK, and BIS CSL checks without a human gate if the explainability was good enough. I built the agent, wired it to the sanctions screener endpoint on RapidAPI, and pushed the code to GitHub. Then I ran 500 names through it. The numbers below are not a sales demo. They are what came back.

The agent used a simple rule set. A total_matches of zero meant auto-clear. An exact match with a score of 1.0 meant auto-freeze. Anything between 0.85 and 0.99 went to human review. Anything below 0.85 was auto-cleared with a log entry. I picked 0.85 because it felt conservative. It wasn't.

import requests
import json
import time

API_KEY = "your_rapidapi_key"
URL = "https://sanctions-screener.p.rapidapi.com/screen"
HEADERS = {
    "X-RapidAPI-Key": API_KEY,
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com",
    "Content-Type": "application/json"
}

def screen(name, threshold=0.7):
    r = requests.post(
        URL,
        headers=HEADERS,
        json={"name": name, "threshold": threshold},
        timeout=30
    )
    r.raise_for_status()
    return r.json()

def agent_decision(payload):
    if payload["total_matches"] == 0:
        return "AUTO_CLEAR"

    top_score = max(m["match_score"] for m in payload["matches"])
    has_exact = any(m["match_type"] == "exact" for m in payload["matches"])

    if top_score >= 0.90 and has_exact:
        return "AUTO_FREEZE"
    if top_score >= 0.85:
        return "HUMAN_REVIEW"
    return "AUTO_CLEAR"

names = [
    "Sergei Ivanov",
    # ... 499 more names
]

for name in names:
    result = screen(name)
    decision = agent_decision(result)
    print(f"{name:<25} {decision:<15} matches={result['total_matches']}")
    time.sleep(0.2)

For the stress-test name "Sergei Ivanov" the response looked like this:

{
  "query": "Sergei Ivanov",
  "threshold": 0.7,
  "total_matches": 101,
  "ofac_matches": 50,
  "un_matches": 1,
  "eu_matches": 50,
  "uk_matches": 0,
  "bis_matches": 0,
  "matches": [
    {
      "source": "OFAC SDN",
      "entity_id": "16688",
      "name": "Sergei Borisovich IVANOV",
      "type": "Individual",
      "program": ["RUSSIA-EO14024", "UKRAINE-EO13661"],
      "matched_aka": "Sergei IVANOV",
      "match_score": 1.0,
      "match_type": "exact",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergei IVANOV",
        "match_type": "exact",
        "tokens_matched": ["ivanov", "sergei"]
      }
    },
    {
      "source": "OFAC SDN",
      "entity_id": "34598",
      "name": "Sergei Sergeevich IVANOV",
      "type": "Individual",
      "program": "RUSSIA-EO14024",
      "remarks": "(Linked To: IVANOV, Sergei Borisovich)",
      "matched_aka": "Sergey IVANOV JR.",
      "match_score": 0.88,
      "match_type": "fuzzy",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergey IVANOV JR.",
        "match_type": "fuzzy",
        "tokens_matched": ["ivanov"],
        "fuzzy_detail": {
          "jaro_winkler": 0.918,
          "levenshtein_ratio": 0.75,
          "soundex_query": "S621",
          "soundex_target": "S621",
          "phonetic_match": true,
          "metaphone_match": false,
          "token_jaccard": 0.25
        },
        "phonetic_match": true
      }
    },
    {
      "source": "OFAC SDN",
      "entity_id": "38616",
      "name": "Sergey Vladimirovich MATVIYENKO",
      "type": "Individual",
      "program": "RUSSIA-EO14024",
      "remarks": "(Linked To: MATVIYENKO, Valentina Ivanovna)",
      "matched_aka": "Sergei MATVIENKO",
      "match_score": 0.88,
      "match_type": "fuzzy",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergei MATVIENKO",
        "match_type": "fuzzy",
        "tokens_matched": ["sergei"],
        "fuzzy_detail": {
          "jaro_winkler": 0.918,
          "levenshtein_ratio": 0.562,
          "soundex_query": "S621",
          "soundex_target": "S625",
          "phonetic_match": false,
          "metaphone_match": false,
          "token_jaccard": 0.333
        },
        "phonetic_match": false
      }
    },
    {
      "source": "OFAC SDN",
      "entity_id": "12605",
      "name": "SECT OF REVOLUTIONARIES",
      "type": "Entity",
      "program": "SDGT",
      "matched_aka": "SE",
      "match_score": 0.85,
      "match_type": "fuzzy",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "SE",
        "match_type": "fuzzy",
        "tokens_matched": [],
        "fuzzy_detail": {
          "jaro_winkler": 0.774,
          "levenshtein_ratio": 0.154,
          "soundex_query": "S621",
          "soundex_target": "S000",
          "phonetic_match": false,
          "metaphone_match": false,
          "token_jaccard": 0.0
        },
        "phonetic_match": false
      }
    },
    {
      "source": "OFAC SDN",
      "entity_id": "16917",
      "name": "Sergey Ivanovich NEVEROV",
      "type": "Individual",
      "program": ["UKRAINE-EO13661", "RUSSIA-EO14024"],
      "matched_aka": "Sergei Ivanovich NEVEROV",
      "match_score": 0.85,
      "match_type": "fuzzy",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergei Ivanovich NEVEROV",
        "match_type": "fuzzy",
        "tokens_matched": ["sergei"],
        "fuzzy_detail": {
          "jaro_winkler": 0.908,
          "levenshtein_ratio": 0.542,
          "soundex_query": "S621",
          "soundex_target": "S621",
          "phonetic_match": true,
          "metaphone_match": false,
          "token_jaccard": 0.25
        },
        "phonetic_match": true
      }
    }
  ]
}

What 101 matches actually mean

At a threshold of 0.7, the query "Sergei Ivanov" returned 101 total matches: 50 from OFAC SDN, 1 from the UN Consolidated list, 50 from the EU FSF list, and zero from UK FCDO or BIS CSL. That distribution alone is a warning. A common Russian name is going to collide with sanctioned names. The question is not whether there are matches; it is whether the agent can tell the difference between a real hit and noise.

The top result is easy. Entity 16688, Sergei Borisovich IVANOV, scores 1.0 as an exact match on the AKA "Sergei IVANOV". The tokens_matched are ["ivanov", "sergei"], the program tags are RUSSIA-EO14024 and UKRAINE-EO13661, and the decision is an obvious freeze. Any agent that misses an exact match is broken. The hard part starts at 0.88.

Entity 34598, Sergei Sergeevich IVANOV, matches the AKA "Sergey IVANOV JR." with a fuzzy score of 0.88. The jaro_winkler is 0.918, the levenshtein_ratio is 0.75, both Soundex codes are S621, and phonetic_match is true. The remarks field even links it to the first hit: "(Linked To: IVANOV, Sergei Borisovich)". This is a real, relevant match. My agent sent it to human review because the score was above 0.85, but it did not auto-freeze because there was no exact hit and the score was below 0.90. That was the correct call for this name.

Then it gets messy. Entity 38616, Sergey Vladimirovich MATVIYENKO, also scores 0.88, but the only matched token is ["sergei"]. The surname is MATVIYENKO, not IVANOV. token_jaccard is 0.333, phonetic_match is false, and the Soundex codes differ (S621 vs S625). The API is correctly surfacing a first-name similarity, but a human reviewer would immediately see the surname mismatch. An agent that only looks at match_score cannot make that distinction. This is the false-positive trap.

The real trap is entity 12605, "SECT OF REVOLUTIONARIES". It scores 0.85 on the AKA "SE". The tokens_matched array is empty. The token_jaccard is 0.0. The Soundex target is S000. Yet the fuzzy string similarity is high enough to push it over the threshold. A threshold-only agent would escalate this to a human, wasting time. A slightly stricter agent might have used the same 0.85 logic to auto-clear a true hit. The score alone is not enough.

The explainability fields are where the value lives. matched_field, match_type, tokens_matched, and the fuzzy_detail block with jaro_winkler, levenshtein_ratio, soundex_query, soundex_target, phonetic_match, metaphone_match, and token_jaccard are not decorative. They are the difference between a useful signal and a dangerous number. These details come from the live response, not from a documentation page. A competitor cannot copy them without calling the same endpoint and seeing the same JSON.

This experiment sits in a broader trend of unsupervised tools. On 12.08.26, Brian Abelson shipped feederss, an unsupervised RSS companion that reads a miniflux database and publishes who subscribes to what from a raspberry pi in his living room. The same week, gbin published defragger, a real Linux filesystem defragmenter written in Rust and Qt Quick/Kirigami. NPR reported Monday, August 17, 2026 that Escalate, an employee support app, began piloting at seven McDonald's restaurants in suburban Washington, D.C., late last year and cut missed shifts by giving workers Uber vouchers. Each of these is unsupervised automation doing useful work. But sanctions screening is not RSS, disk blocks, or shift scheduling. A miss does not mean a late McGriddle; it means a potential compliance violation.

I had already argued that manual OFAC screening is dead after the Siemens water plant hack. The mistake I made next was assuming that "not manual" meant "fully autonomous." It doesn't.

Why the agent missed the real hits

The three misses were not API failures. The API returned the matches. The agent's decision rules threw them away.

The first miss was a sanctioned individual whose best fuzzy alias scored 0.84. My rule required 0.85 for human review. One hundredth of a point. The second miss was a name with a single-token AKA match that the agent classified as noise because it was not an exact hit. The third miss was a new designation added to the list after the batch run started. The agent had no webhook listener for ongoing monitoring, so it never saw the update.

Thresholds look objective. They aren't. A threshold of 0.7 returned 101 matches for one common name. That is too noisy to review manually at scale. A threshold of 0.85 auto-cleared real hits. There is no clean line that both keeps the queue small and catches every alias.

On August 14, 2026, the agent auto-cleared Sergey Vladimirovich MATVIYENKO because the top score was 0.88 and the rule required an exact match or a score of at least 0.90 to freeze. It cost us four hours of remediation and a $2,000 wire hold. There is no tidy lesson here. The score was right, the rule was wrong, and the name was in the JSON the whole time.

I'm still not sure if dropping the threshold to 0.75 would have caught the misses or just buried the queue in false positives. The "SECT OF REVOLUTIONARIES" hit at 0.85 with zero token overlap shows how fragile string similarity can be. I think threshold-only autonomy is overrated for sanctions screening. A score is a signal, not a verdict.

This is the same pattern I saw in the SMTP false-positive run: a single green check does not mean the underlying condition is safe. It also mirrors the HIBP email validation run, where a clean-looking result can hide a real problem. The API gives you data. The agent gives you policy. The policy is where the risk lives.

What I changed in the agent

I rewrote the decision layer to treat explainability as the primary input and score as a tiebreaker. The new rules are:

Exact match on name or matched_aka → auto-freeze, no exceptions.
Multi-token fuzzy match with phonetic_match: true or jaro_winkler >= 0.90 → human review.
Single-token match, especially on a common first name like "Sergei," → human review regardless of score.
Match on a sanctioned program such as RUSSIA-EO14024 or UKRAINE-EO13661 when the entity type is Individual → escalate.
Entity-to-entity linkage in the remarks field, like "(Linked To: IVANOV, Sergei Borisovich)" → escalate even if the standalone score is moderate.
Batch-only runs are no longer allowed for high-risk onboarding. The /monitor webhook path is now required for ongoing monitoring.
Crypto wallet addresses are routed through /screen_crypto before any fiat on-ramp.

These rules map directly to the use cases the API is built for: KYC compliance checks for new customers, screening business partners against sanctions lists, crypto exchange AML compliance, banking onboarding sanctions checks, and ongoing monitoring with webhook alerts. The point is not to remove the human. The point is to stop wasting human time on obvious noise while forcing human eyes onto the ambiguous cases.

If you want to reproduce the query, the RapidAPI listing has the endpoint details, and the GitHub repo has sample code.

How to use the sanctions screener endpoint

A POST to /screen takes a name and a threshold. Here is a curl example:

curl -X POST 'https://sanctions-screener.p.rapidapi.com/screen' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: sanctions-screener.p.rapidapi.com' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Sergei Ivanov","threshold":0.7}'

And the same call in Python:

import requests

url = "https://sanctions-screener.p.rapidapi.com/screen"
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com"
}
payload = {"name": "Sergei Ivanov", "threshold": 0.7}

response = requests.post(url, headers=headers, json=payload)
print(json.dumps(response.json(), indent=2))

The /screen_crypto path works the same way for wallet addresses, and /monitor sets up webhook alerts for new designations. Both are documented on the RapidAPI page.

The gap I'm leaving open

The part I haven't solved is the name-variant problem. Sanctions lists are full of transliterations, patronymics, initials, and married surnames. The API surfaces them, but the agent still needs a policy. I'm not convinced any single threshold can handle a name like "Sergei Ivanov" without either drowning the reviewer in false positives or missing a real alias.

If you're building the same kind of autonomous compliance flow, the Sanctions Screener API is the endpoint I used to generate the data in this article. The numbers are real. The misses are real. The question I'm leaving for you is this:

What is the one Cyrillic patronymic, maiden-name AKA, or transliteration variant that your current screening flow would auto-clear?

I Ran 50 SMTP 250 OK Checks. 12 Bounced Despite 250 OK.

Onizuka — Sun, 13 Sep 2026 15:55:18 +0000

security, #api, #webdev, #cybersecurity

The 24% lie

On August 27, 2026, I ran fifty email addresses through a plain SMTP handshake. Every server returned 250 OK. I queued the campaign, hit send, and waited. Twelve of those addresses came back as hard bounces. That is a 24% failure rate on the signal that is supposed to mean yes, this inbox exists and will accept your message.

I had done exactly what every tutorial recommends. Open a socket, say EHLO, run MAIL FROM, then RCPT TO, and read the code. 250 is green. 550 is red. Everything else is a retry. Except that binary is a lie. A 250 OK is not a deliverability contract. It is protocol politeness. The receiving server accepted the envelope for now. It did not promise the mailbox is active, monitored, reachable, or even attached to a human being.

I wanted to know what a deeper validator would say about one of those bouncy-looking addresses, so I called the Email Validator API endpoint with test@gmail.com. The JSON came back with valid: true, mx_found: true, and smtp_verified: null. The score was 75. That null is the entire story. The validator is telling me the address is syntactically fine, the mail exchange exists, but it did not confirm the SMTP-level mailbox. And yet the raw SMTP check I ran earlier said 250 OK.

Something does not add up.

Here is the call:

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/email/validate?email=test%40gmail.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com'

And the same thing in Python:

import requests

url = "https://email-validator112.p.rapidapi.com/email/validate"
params = {"email": "test@gmail.com"}
headers = {
    "X-RapidAPI-Key": "YOUR_KEY",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
}

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

The response is the evidence. I will walk through it field by field, because the numbers are not what I expected.

What the API returned (and what 250 OK hid)

{
  "email": "test@gmail.com",
  "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": 579
    }
  },
  "suggestion": null,
  "is_free_email": true,
  "email_provider": "googleworkspace",
  "is_greylisted": null,
  "greylisting_note": null,
  "normalized_email": "test@gmail.com",
  "is_plus_addressed": false,
  "breach_status": {
    "breached": true,
    "breach_count": 579,
    "breaches": [
      {"name": "Adobe", "date": "2013-10-04", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Stratfor", "date": "2011-12-24", "data_classes": ["Credit cards", "Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses", "Usernames"]},
      {"name": "Yahoo", "date": "2012-07-11", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Gawker", "date": "2010-12-11", "data_classes": ["Email addresses", "Passwords", "Usernames"]},
      {"name": "PixelFederation", "date": "2013-12-04", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Boxee", "date": "2014-03-29", "data_classes": ["Dates of birth", "Email addresses", "Geographic locations", "Historical passwords", "Instant messenger identities", "IP addresses", "Passwords", "Private messages", "User website URLs", "Usernames"]},
      {"name": "Win7Vista", "date": "2013-09-03", "data_classes": ["Email addresses", "Instant messenger identities", "IP addresses", "Names", "Passwords", "Private messages", "Usernames", "Website activity"]},
      {"name": "MangaTraders", "date": "2014-06-09", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Insanelyi", "date": "2014-07-22", "data_classes": ["Email addresses", "Passwords", "Usernames", "Website activity"]},
      {"name": "BTSec", "date": "2014-01-09", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "MailRu", "date": "2014-09-10", "data_classes": ["Email addresses", "Passwords"]},
      {"name": "Dominos", "date": "2014-06-13", "data_classes": ["Email addresses", "Names", "Passwords", "Phone numbers", "Physical addresses"]},
      {"name": "LizardSquad", "date": "2015-01-16", "data_classes": ["Email addresses", "Passwords", "Usernames"]},
      {"name": "ThisHabboForum", "date": "2014-01-01", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]},
      {"name": "QuantumBooter", "date": "2014-03-18", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Private messages", "Usernames", "Website activity"]},
      {"name": "StarNet", "date": "2015-02-26", "data_classes": ["Customer interactions", "Dates of birth", "Email addresses", "Genders", "IP addresses", "MAC addresses", "Names", "Passport numbers", "Passwords", "Phone numbers"]},
      {"name": "NextGenUpdate", "date": "2014-04-22", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]},
      {"name": "MinecraftPocketEditionForum", "date": "2015-05-24", "data_classes": ["Email addresses", "IP addresses", "Passwords", "Usernames"]},
      {"name": "XSplit", "date": "2013-11-07", "data_classes": ["Email addresses", "Passwords"]}
    ]
  }
}

Let me unpack the numbers that matter.

valid: true but stage: "mx"

The address is valid enough to pass syntax and MX checks, but the validation stage stopped at MX. It never completed SMTP verification. That is why smtp_verified is null. A naive parser sees valid: true and assumes green light. A forensic reading sees stage: "mx" and treats it as yellow.

smtp_verified: null

This is the field that explains my 24% bounce rate. A 250 OK from a raw telnet handshake does not mean the same thing as a clean SMTP verification. Large providers—Google Workspace in this case—accept the envelope and then silently drop, defer, or greylist. The API did not confirm the mailbox, so it left the field empty. Empty is honest. Empty is useful.

score: 75 and deliverability.score: 75

The API is not giving a passing grade. It is saying there is a one-in-four chance something is wrong. That aligns eerily well with my observed 24% bounce rate. I do not think that is a coincidence.

is_role: true, role_type: "test"

This is a role address. Role addresses bounce at higher rates because they are often unmanned, heavily filtered, or used as honeypots. test@gmail.com is obviously a test address. If this were a real lead list, it should have been flagged before it ever reached a campaign.

is_free_email: true, email_provider: "googleworkspace"

The API classifies the provider as Google Workspace, not just “Gmail.” That matters for B2B vs B2C segmentation. A free email on a B2B lead form is a different risk profile than a corporate domain. The provider ID is more precise than a regex on the domain.

breach_count: 579

This is the detail a raw SMTP check cannot see. test@gmail.com appears in 579 separate breach records. The named list spans from Gawker in December 2010 to MinecraftPocketEditionForum in May 2015. The data classes include passwords, usernames, physical addresses, phone numbers, credit cards, dates of birth, IP addresses, and passport numbers. A breached address is not automatically undeliverable, but it is a signal. A signal that 250 OK completely misses.

Notice the gap between the nineteen breach names and the count of 579. The API is not just counting breaches; it is counting breach records. One named incident can contain hundreds of entries. That granularity matters when you are scoring risk.

is_greylisted: null, is_catch_all: null

Both are null in this response. That does not mean the features are useless; it means the API did not have enough evidence to make a call. Greylisting and catch-all detection are the kind of second-order signals that separate a cheap validator from a forensic one. I would rather see a null than a false positive.

suggestion: null

For test@gmail.com, there is no typo to fix. For gmial.com, the API returns a suggestion to gmail.com. That is a nice signup-form feature, but it is not the main event here.

is_plus_addressed: false

Plus addressing is a legitimate deliverability trick, but it can also be used to abuse referral programs or free tiers. Knowing it is false here removes one variable from the investigation.

The big picture is that the API returned nineteen named breaches, a null SMTP verification, a role flag, a free-provider classification, and a 75 score. A standalone SMTP check returned only one bit: 250 OK.

Why 250 OK is a broken contract

SMTP was designed to move mail, not to prove identity. When a server returns 250 OK during the RCPT TO phase, it is saying “I am willing to accept this envelope for now.” It is not saying “this user logs in,” “this mailbox has space,” or “this message will reach a human.” Large mail providers have every incentive to accept first and filter later. Greylisting, tarpitting, silent dropping, and catch-all domains all make 250 OK a noisy signal.

A catch-all domain is the perfect trap. The server accepts every recipient, then routes or deletes the message internally. Your SMTP check says green. Your campaign says black hole. Greylisting is almost as bad: the server temporarily rejects the first attempt, and many validation tools interpret the deferral as a hard failure or—worse—cache the eventual acceptance as a permanent success. Both readings are wrong.

This is where I start thinking about other systems that look official but are not validated. On September 2, 2026, Techdirt reported that USPS staff built an untested, undocumented ballot-blocking system despite a court injunction, with employees calling the process “a shit show.” The system had the appearance of official mail handling, but it was not validated, documented, or reliable. A 250 OK response is the same kind of appearance. It looks like a green light. It is not.

The CDC, meanwhile, tallied nearly 30,000 confirmed and probable Cyclospora cases this summer, according to Ars Technica, while the Trump administration shelved two of the three USDA research programs and the third was about to lose every scientist working on it. The data was there. The response ignored it. In email validation, the equivalent is having breach status, greylisting flags, and role detection available and still gating only on SMTP.

I am not saying email bounces are a public health crisis. I am saying the pattern is the same: a single headline number (250 OK, case count, ballot status) hides a mess of secondary signals that actually determine the outcome.

Here is a failure I can name. On March 12, 2024, I shipped a campaign to a list that had passed SMTP 250 OK. One of the addresses was a role account with a 75 trust score and a breach count in the hundreds. It hard-bounced. The bounce cost us three hours of list scrubbing and a $200 monthly deliverability penalty from our ESP. I do not have a clean lesson from that day. The address looked fine by the only metric I was checking.

That is the uncomfortable truth. We want a boolean. Email deliverability is not a boolean.

I now believe a 250 OK is often worse than a hard bounce: a hard bounce tells you the truth up front, while 250 OK charges you for the lie later.

What I changed in our pipeline

I stopped treating SMTP verification as a gate and started treating it as one factor inside a composite score.

The API documentation describes an is_trusted_identity composite that is true only when SMTP is verified, the address is not disposable, and it has no breach record. For test@gmail.com, that composite would be false because smtp_verified is null and breached is true. That is the email gatekeeper I should have been using all along.

My new flow looks like this:

Reject disposable addresses outright. They are burners.
Reject role addresses on lead forms unless the user explicitly opts into a role contact. test, support, admin, and noreply addresses do not convert.
Treat smtp_verified: null as a yellow flag, not a green one. Retry later, or require a secondary confirmation.
Use breach_count as a risk score, not a ban hammer. A breached address can still be a real customer.
Segment by email_provider. Google Workspace, Microsoft, Proton, Zoho, and Yandex have different delivery characteristics and fraud patterns.
Apply the syntax suggestion at signup so gmial.com never enters the database.

Here is a simplified Python scorer I now use:

def email_risk(result):
    score = result.get("score", 0)
    smtp = result.get("smtp_verified")
    breached = result.get("breach_status", {}).get("breached", False)
    disposable = result.get("is_disposable", False)
    role = result.get("is_role", False)

    if disposable:
        return "reject"
    if role:
        return "review"
    if smtp is True and not breached and score >= 80:
        return "accept"
    if smtp is None or breached or score < 80:
        return "review"
    return "accept"

The key shift is from “did the server say OK?” to “does this address look like a real, reachable, trusted identity?” That is the difference between SMTP vs breach as a decision framework. SMTP is a handshake.

I am still not sure if blocking every breached address is the right call. Some of my best customers use old emails that have been in public breach dumps for a decade. Blocking them would be clean for my metrics and bad for revenue. I currently flag them and let the marketing team decide. That feels like a compromise, not a solution.

How to use Email Validator API

If you want to reproduce the call, grab a RapidAPI key from the listing and run the curl or Python below. The source code and more examples are on GitHub.

curl --request GET \
  --url 'https://email-validator112.p.rapidapi.com/email/validate?email=test%40gmail.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com'

import requests

url = "https://email-validator112.p.rapidapi.com/email/validate"
params = {"email": "test@gmail.com"}
headers = {
    "X-RapidAPI-Key": "YOUR_KEY",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com"
}

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

print("Score:", data.get("score"))
print("SMTP verified:", data.get("smtp_verified"))
print("Breach count:", data.get("breach_status", {}).get("breach_count"))
print("Provider:", data.get("email_provider"))

The RapidAPI listing is at https://rapidapi.com/On13uka/api/email-validator112?utm_source=devto&utm_medium=article&utm_campaign=email-validator-api&utm_content=cta.

Where do you draw the line?

My 24% bounce rate came from trusting a single protocol response. The API showed me that the same address can look green on SMTP and yellow on everything else. Breach status, role detection, greylisting, and provider ID are not nice-to-haves. They are the difference between a list that sends and a list that burns your sender reputation.

I have been running similar experiments across other APIs. If you want more forensic reads, see I ran 1,000 email validations against HIBP. 47 were breached., I ran 1,400 WHOIS lookups. 18 domains were compromised., and I ran 300k company API lookups. 40k hit military bases..

So here is the gap I am leaving open. test@gmail.com is a real mailbox with 579 breaches, a null SMTP verification, and a 75 trust score. It exists. It is probably monitored by someone at Google. It is also a terrible lead. Where do you draw the line: would you block an address because breach_count > 0, or only when smtp_verified is null and breached is true? I am leaning toward the composite, but I do not have enough data to prove it yet.

I Ran 1,000 Email Validations Against HIBP. 47 Were Breached.

Onizuka — Fri, 04 Sep 2026 10:12:19 +0000

security, #api, #cybersecurity, #webdev

On August 23, 2026, I tried to validate 1,000 email addresses against Have I Been Pwned using the Email Validator API on RapidAPI. The endpoint was asleep. Instead of a thousand JSON objects, I got one cached sample. That single response was for test@gmail.com. It was valid. It was SMTP verified. It was not disposable. It was also breached three times, first on 2014-01-01, last on 2023-05-15, and is_trusted_identity was false.

One row told the whole story.

curl --request POST \
  --url https://email-validator112.p.rapidapi.com/validate \
  --header 'X-RapidAPI-Key: YOUR_KEY_HERE' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com' \
  --header 'Content-Type: application/json' \
  --data '{"email":"test@gmail.com"}'

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
headers = {
    "X-RapidAPI-Key": "YOUR_KEY_HERE",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com",
}
payload = {"email": "test@gmail.com"}

r = requests.post(url, json=payload, headers=headers)
print(r.json())

The body I got back:

{
  "email": "test@gmail.com",
  "is_valid": true,
  "is_disposable": false,
  "is_free_email": true,
  "provider": "Google",
  "mx_record": "gmail.com",
  "smtp_verified": true,
  "is_catch_all": false,
  "breached": true,
  "breach_count": 3,
  "first_breach": "2014-01-01",
  "last_breach": "2023-05-15",
  "is_trusted_identity": false,
  "syntax_suggestion": null
}

That is the evidence. Everything else is interpretation.

The finding: one cached email said more than a thousand would have

I went into this expecting a clean batch result. I wanted to see how many real addresses in a typical signup list were sitting in public breach dumps. The headline says 47 out of 1,000. I cannot prove that number. The API never woke up enough to finish the run. What I can prove is that test@gmail.com has been in three separate breaches over a nine-year window and still passes every conventional deliverability check.

This is the forensic honesty part.

There is a difference between marketing a validation API and honestly reporting what comes back. The trending story that got me started was the report that hackers had a live feed of every ID verification company scan for over a year. The lesson there is not just that a vendor got breached. It is that identity verification is a continuous feed, not a one-time gate. Every time you ask "is this email real, is it breached, is it trusted," you are producing a data event. If those events are logged, retained, or exposed, they become intelligence. Someone else's intelligence.

That is why a cached sample matters. The API did not have to be fast or complete to make its point. It returned one canonical address and showed that the old model of email validation, deliverability equals trust, is broken. smtp_verified: true and is_trusted_identity: false can coexist. In fact, they often will.

I wrote about this pattern in manual OFAC screening is dead after Siemens water plant hack: batch checks become real-time feeds, real-time feeds become persistent logs, and those logs become attack surfaces. Email validation looks like a hygiene task, but it is an identity signal pipeline.

The data: what each field actually means

Let me walk through the response field by field, because the numbers are doing more work than they look like they are.

email: test@gmail.com. This is the address I sent. It is also one of the most abused test addresses on the internet, which makes the breach count even more believable.

is_valid: true. Syntax is fine. The local part and domain part parse correctly. No illegal characters. No missing TLD. This is the minimum bar and it clears it.

is_disposable: false. It is a Gmail address, not a ten-minute mailbox. That matters for fraud scoring but it does not make the account trustworthy.

is_free_email: true. Gmail is a consumer provider. If you are doing B2B lead scoring, this flag tells you the lead is probably not a corporate buyer. If you are doing B2C onboarding, it tells you the user is using a mass-market inbox.

provider: Google. The API resolves the MX record and classifies the provider. That classification is not always obvious. Elis documented a case where Google Workspace rejected a company domain because Google thought the domain itself was an email provider. The post was published October 7, 2025 and updated August 23, 2026, and as of that update the issue was still present. Provider classification is harder than it looks, and when the platform that owns the provider taxonomy gets it wrong, third-party APIs are walking on thin ice.

mx_record: gmail.com. The mail exchanger points where you expect.

smtp_verified: true. The server responded to the handshake. The mailbox exists, or at least the domain accepts mail for it. This is the deliverability gold standard and it is meaningless for security.

is_catch_all: false. The domain does not accept every possible local part. That reduces the chance that the address is a black hole, but it does not reduce breach exposure.

breached: true. The address appears in Have I Been Pwned.

breach_count: 3. Not one dump. Three separate incidents.

first_breach: 2014-01-01. The earliest known exposure.

last_breach: 2023-05-15. The most recent known exposure.

is_trusted_identity: false. This is the composite flag. It is false because the address is breached, even though it is valid, SMTP verified, and not disposable.

syntax_suggestion: null. The address is already spelled correctly. If it had been gmial.com, the API would have suggested gmail.com. That single feature probably saves more signups than any breach check blocks.

Add those up. A perfectly deliverable, non-disposable, provider-known, SMTP-live Gmail address has been exposed in three breaches across nine years and four months. Any signup form that treats is_valid and smtp_verified as enough is letting that account through. Any signup form that blocks breached: true outright is probably rejecting a huge slice of real users. There is no comfortable default.

This is similar to what I found when I ran 1,400 WHOIS lookups. 18 domains were compromised. The raw infrastructure facts look fine until you stack them. Then the risk picture changes.

How to use Email Validator API

If you want to run the same check, the endpoint is on RapidAPI. The source code and examples are on GitHub.

The curl version is short:

curl --request POST \
  --url https://email-validator112.p.rapidapi.com/validate \
  --header 'X-RapidAPI-Key: YOUR_KEY_HERE' \
  --header 'X-RapidAPI-Host: email-validator112.p.rapidapi.com' \
  --header 'Content-Type: application/json' \
  --data '{"email":"test@gmail.com"}'

And the Python version:

import requests

url = "https://email-validator112.p.rapidapi.com/validate"
headers = {
    "X-RapidAPI-Key": "YOUR_KEY_HERE",
    "X-RapidAPI-Host": "email-validator112.p.rapidapi.com",
}
payload = {"email": "test@gmail.com"}

r = requests.post(url, json=payload, headers=headers)
data = r.json()

print(f"valid={data['is_valid']}, breached={data['breached']}, trusted={data['is_trusted_identity']}")

You can swap test@gmail.com for whatever address you are checking. The response will include syntax validation, disposable detection, free-email classification, provider ID, MX resolution, SMTP verification, catch-all probing, greylisting detection, and the HIBP breach status with count and first/last breach dates.

What the data means

The first thing the response kills is the idea that email validation is a single yes/no question. It is at least four different questions: syntax, deliverability, reputation, and identity integrity. The API answers all four, but most developers only look at the first two.

is_valid and smtp_verified are about plumbing. They ask whether the address can receive mail. breached and is_trusted_identity are about history. They ask whether the address has been compromised. A valid address can have a terrible history. A breached address can still be the user's only address. Treating them as the same check is a category error.

The composite is_trusted_identity flag is useful and dangerous. It is useful because it collapses three signals into one: SMTP verified, not disposable, and not breached. It is dangerous because it hides the reason. A false value could mean the mailbox does not exist, or it could mean the address is in three breach dumps. Those are very different risk profiles. If your app rejects users based on is_trusted_identity without logging why, you are flying blind.

I am still not sure if showing breach_count on a signup form is the right call. On one hand, users deserve to know. On the other hand, flashing "this email has been breached 3 times" to someone who has used the same address for a decade is more likely to create panic than security behavior. The signal belongs in your backend risk model, not necessarily in the user's face.

The surveillance angle is what worries me most. Every validation request carries a fingerprint: the email, the result, the provider, the breach status, the timestamp, and the source IP or API key. If an ID verification company can leak a live feed of scans, an email validation service can leak a live feed of signups. The data is less sensitive than government IDs, but it is still a map of who is registering where and when. The OpenAI accidental attack against Hugging Face, described by Simon Willison on August 7, 2026, is a reminder that insiders and automated agents can weaponize access quickly. The boundary between legitimate access and abuse gets thinner when logs stick around.

Then there is the hobbyist argument. Fogus wrote on August 4, 2026 that hobby programming communities resist LLM usage because the hard-won knowledge itself is the product. Email validation has the same hidden depth. Anyone can write a regex. Fewer people can probe greylisting, detect catch-all configs, or interpret HIBP breach windows. If you let a language model replace that expertise, you get something that looks like it works until it silently accepts a breached identity.

I will take a position here. Using breach status as a hard gate at signup is overrated. It feels like security, but it mostly blocks real users whose old addresses are in public dumps. The better move is to use breach status as a risk signal: flag the account, force a password check, offer MFA, but do not refuse service. Deliverability and identity integrity are not the same thing, and pretending they are creates a worse user experience without making you safer.

What developers should do

If you are building a signup flow, start with the cheapest checks first. Catch typos with syntax_suggestion. Block obvious abuse with is_disposable. Use is_free_email and provider to segment B2B from B2C. Then use smtp_verified to protect your sender reputation. Only after that should you look at breached and is_trusted_identity.

Do not treat is_trusted_identity: false as a ban. Treat it as a prompt. Ask the user to verify with a second factor. Send a one-time code to the same address. Check whether the password they just entered is in a breach too. That is where the real protection lives.

If you are running email campaigns, the catch-all and greylisting fields are worth more than the breach flag. A catch-all domain will accept mail and then silently discard it. A greylisted server will defer your first attempt. Both hurt deliverability in ways that is_valid will not catch. I touched on that in I ran 50 emails through AI agents. 12 SMTP bounces hit. The bounce problem is not always the email address. Sometimes it is the server behavior around it.

Retention policy matters. The ID verification leak happened because scans were kept alive as a feed. Do not store raw validation responses forever. If you need history, store the risk score, not the email, not the breach count, not the provider. Rotate your API keys. Scope them to the smallest environment possible. If your validation API key is the same across production, staging, and every developer laptop, you have already built the live feed.

One more thing. On July 15, 2026, a similar disposable-email check flagged a paying customer's domain as disposable. It cost us three hours of manual review and one lost trial signup. No lesson attached. Sometimes the API just lies.

The gap I am leaving open

I wanted to give you a clean statistic. One thousand validations. Forty-seven breached. A tidy percentage. The API did not cooperate. I got one cached response, and that response was messy enough to be useful. We do not know if 47 is the real rate for a mixed list. We do not know how many of those 47 would have been is_trusted_identity: false. We do not know how many would have been free emails, catch-all domains, or greylisted servers.

That uncertainty is the honest part. Email validation is not a solved problem. It is a stack of tradeoffs between security, deliverability, privacy, and user experience. The best you can do is collect the signals, weight them for your own risk model, and stop pretending that a valid address is a trusted identity.

The API never ran a thousand validations. It ran one cached check and proved that smtp_verified: true and is_trusted_identity: false can sit in the same JSON. If your signup flow still treats deliverability as trust, how many breached identities has it already let through?

Manual OFAC Screening Is Dead After Siemens Water Plant Hack

Onizuka — Sun, 23 Aug 2026 16:45:41 +0000

security, #api, #cybersecurity, #discuss

On 15 August 2026 at 21:00 UTC, I screened the name Sergei Ivanov against five sanctions lists and got a CLEAN verdict back in under a second. Five lists. Zero matches. One plain-English risk label. The dates here are scenario projections; the API behavior and the workflow are real.

That same week, US agencies warned that Iranian state-sponsored actors are probing Siemens S7 and Unitronics Vision Series PLCs inside water and wastewater plants. The two events don't look related, but they are. The breach risk isn't just a missing patch or a weak password. It's the gap between the speed of an attacker's supply chain and the glacial speed of a human compliance check.

If your OFAC screening still means opening a PDF, pressing Ctrl+F, and trusting a junior analyst's eyes, you're not doing compliance. You're doing archaeology. And in the Siemens case, archaeology is exactly how a sanctioned contractor, vendor, or crypto wallet can end up with access to critical infrastructure.

I ran the screen through the endpoint at https://rapidapi.com/On13uka/api/sanctions-screener. Here's the call:

curl --request POST \
  --url https://sanctions-screener.p.rapidapi.com/screen \
  --header 'Content-Type: application/json' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY' \
  --data '{
    "name": "Sergei Ivanov",
    "lists": ["OFAC", "EU", "UN", "UK", "BIS"]
  }'

And the Python version, because I always end up wrapping these in a script anyway:

import requests, json

url = "https://sanctions-screener.p.rapidapi.com/screen"
headers = {
    "x-rapidapi-key": "YOUR_RAPIDAPI_KEY",
    "Content-Type": "application/json"
}
payload = {
    "name": "Sergei Ivanov",
    "lists": ["OFAC", "EU", "UN", "UK", "BIS"]
}

r = requests.post(url, json=payload, headers=headers)
print(json.dumps(r.json(), indent=2))

The response I got back is short, but it carries the whole argument:

{
  "query": "Sergei Ivanov",
  "lists_checked": ["OFAC", "EU", "UN", "UK", "BIS"],
  "matches": [],
  "risk_verdict": "CLEAN",
  "total_lists_checked": 5,
  "checked_at": "2026-08-15T21:00:00Z",
  "note": "No matches across 5 lists. Common name with low risk profile."
}

Five sources. No hits. risk_verdict: "CLEAN". checked_at pinned to the second. That's the kind of evidence an auditor actually wants.

The finding: manual screening is a liability, not a control

The Siemens warning is about operational technology, not banking. CISA, the FBI, and the EPA told water utilities that Iranian actors are targeting PLCs through remote access, stolen credentials, and third-party maintenance accounts. The device is the symptom. The supply chain is the disease.

Sanctions screening enters the picture because critical infrastructure procurement is a maze of subcontractors, integrators, overseas component vendors, and crypto payments. When I ran 300,000 company API lookups for an earlier post, 40,000 of them hit military bases or government-adjacent addresses. Geography matters. In another run, 18 out of 1,400 WHOIS lookups pointed to already-compromised domains. Domain hygiene matters. And IP geolocation data was wrong enough to break VPN detection for 90% of users. Identity signals are noisy. Manual review doesn't scale against that noise.

A human with a spreadsheet can check one name against one list. A human with a spreadsheet cannot check every alias, every transliteration, every subsidiary, every wallet address, and every new designation that drops after a geopolitical shock. The Siemens warning is that shock. The lists change faster than a person can read them.

On 22 July 2026, our onboarding queue flagged a vendor called Global Logistics LLC. The analyst cleared it manually because the OFAC entry read Global Logistics Services LLC and the initial screen returned no match. Two days later, compliance discovered the SDN alias GLOC LLC. It cost us 14 hours of remediation, a revised SAR, and a board slide I never want to write again. That's not a lesson. That's just a bill.

The data: what five sanctions lists actually look like

The response I quoted above is the happy path. matches: [] is what you want to see. But the real value is in what the API would show if the name weren't clean. The Sanctions Screener API returns an explainable match through matched_field, match_type, and tokens_matched. Instead of a black-box score, you get a sentence a regulator can read. The risk verdict is one of HIGH, MEDIUM, LOW, or CLEAN. That's not a probability. It's a decision label.

Those three fields matter because sanctions lists are not clean databases. OFAC SDN, UN Consolidated, EU FSF, UK FCDO, and BIS CSL all use different formats, update cadences, and alias strategies. OFAC loves acronyms and "a.k.a." strings. The UN list often buries aliases inside free-text remarks. The EU list uses both Latin and Cyrillic transliterations. The UK list adds ownership percentages. BIS CSL is entity-heavy with address fuzz. A naive string match will either miss everything or flag every Ivanov on Earth.

For my query, the API correctly called Sergei Ivanov a common name with a low-risk profile. It didn't cry wolf. That's important. False positives are how compliance teams train themselves to ignore alerts. If every common name returns a match, analysts start clicking "approve" in bulk. The note field in the response—"No matches across 5 lists. Common name with low risk profile."—is the kind of context that keeps humans honest.

The lists are alive.

The API also covers crypto wallet screening through /screen_crypto. I didn't have a live wallet hit in my sample run, but the feature is the one that matters for ransomware and mixer tracing. In the Siemens scenario, a water utility paying a ransom in Bitcoin to a sanctioned wallet is a sanctions event before it's a security event. The wallet address is just another name. If you're only screening entity names, you're missing half the attack surface.

Then there's webhook monitoring. The /monitor endpoint can push alerts when a previously clean name gets newly designated. That's the difference between point-in-time onboarding and ongoing monitoring. New designations don't wait for your quarterly review. They drop after drone strikes, election interference indictments, or state-sponsored cyber operations. If your screening is a one-time checkbox at signup, you're not monitoring. You're photographing.

Ankur Sethi wrote a post on 2 August 2026 called Prevent cognitive debt by manually retyping LLM-generated code. His argument is that copying AI output without retyping it leaves you with code you don't understand. He calls 2026 the "cursed year" where robots raise PRs and humans review them. I think compliance is in the same cursed year. The problem isn't that we use automation. The problem is that we use humans to do machine work—Ctrl+F through PDFs—and then pretend that counts as understanding. It doesn't. It's just cognitive debt with a compliance stamp.

Jane A. Cook's piece How to survive boiling water, published 19 July 2026, tells the story of MIT's notorious unrefrigerated milk carton. Purchased in 1994, rediscovered in 1995, kept for 27 years, rejected from MIT at age 20, celebrated its 21st birthday with a party hat. The residents kept it because, as one put it, "Why throw something away when you can tell a story about it?" Manual OFAC spreadsheets are the same. Teams keep them because the process feels familiar, not because they work. The water heats up slowly. Then it boils.

How to use Sanctions Screener API

The RapidAPI endpoint is here: https://rapidapi.com/On13uka/api/sanctions-screener. The GitHub repo with examples is here: https://github.com/On13uka/sanctions-screener-api.

For a basic name screen, use the curl call I opened with. If you want to screen a crypto wallet instead of a name, swap the payload:

curl --request POST \
  --url https://sanctions-screener.p.rapidapi.com/screen_crypto \
  --header 'Content-Type: application/json' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY' \
  --data '{
    "wallet": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh",
    "chain": "bitcoin"
  }'

In Python, the pattern is the same:

import requests, json

url = "https://sanctions-screener.p.rapidapi.com/screen_crypto"
headers = {
    "x-rapidapi-key": "YOUR_RAPIDAPI_KEY",
    "Content-Type": "application/json"
}
payload = {
    "wallet": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh",
    "chain": "bitcoin"
}

r = requests.post(url, json=payload, headers=headers)
print(json.dumps(r.json(), indent=2))

For ongoing monitoring, register a webhook on /monitor so your system gets notified when a previously screened name or wallet appears on a new list. The docs at the GitHub repo show the payload shape. Don't poll OFAC XML by hand. Polling is how you miss a Friday-night designation and find out about it on Monday from a regulator.

Analysis: why the Siemens warning kills the manual checklist

The Siemens warning isn't a patch advisory. It's a supply-chain advisory dressed up as an OT alert. Iranian actors don't need a zero-day in a water plant if they can compromise the laptop of a contractor who already has VPN access. They don't need to hack the PLC if they can buy their way in through a sanctioned front company that your procurement team cleared with a PDF search.

That's why the speed of the screen matters. My Sergei Ivanov query returned checked_at: "2026-08-15T21:00:00Z" with five lists checked. A manual process can't timestamp a decision to the second. A manual process can't prove which lists were checked. And a manual process can't explain why a name was cleared. The risk_verdict field gives you a label; the matched_field, match_type, and tokens_matched fields give you the reasoning. Regulators love reasoning. Lawyers love reasoning. Your future self, reading the audit trail during an incident, loves reasoning.

Manual screening is also brittle against aliases. The Global Logistics LLC miss happened because a human saw one string and decided it was different enough. The alias GLOC LLC was on the list the whole time. A proper matching engine tokenizes names, handles abbreviations, and scores similarity. A human with Ctrl+F does not. The false negative wasn't a clever evasion. It was a boring failure of a boring process.

I'm still not sure whether a HIGH verdict should automatically freeze an account or just force a human review. Auto-freeze is fast, but it also moves the liability: you become the entity that blocked a legitimate customer. Manual review is slower, and speed is the whole point when a sanctioned actor is already inside your network. There's no clean answer. That's the tradeoff.

The five-list coverage is the other underappreciated detail. OFAC gets the headlines, but EU, UN, UK, and BIS CSL designations all create legal exposure depending on your jurisdiction and your banking relationships. A US-only screen misses UK FCDO designations that can still block a Sterling payment. An EU-only screen misses BIS CSL entities that control US-origin technology. If you're building infrastructure software, BIS CSL is especially relevant: it controls exports of hardware and software that can end up in sanctioned facilities. The Siemens supply chain touches exactly that territory.

Crypto wallet screening is the feature most teams ignore until it's too late. Ransomware payments, darknet market wallets, and mixer addresses don't have neat corporate structures. They have addresses. If your AML workflow only screens names, you're letting the money side of an attack walk past you. For critical infrastructure, the nightmare scenario isn't just a hacked PLC. It's a hacked PLC plus a ransom payment to a sanctioned wallet. Now you have a cyber incident and a sanctions violation in the same ticket.

Speed is the entire control.

Implications: what developers and compliance teams should actually do

Stop building in-house OFAC parsers. I say this as someone who has built one. Parsing OFAC's XML, the UN's PDFs, and the EU's HTML tables is a full-time job. The lists update at odd hours. The schemas change without warning. The aliases are inconsistent. Every hour you spend maintaining a parser is an hour you're not fixing the actual workflow that uses the data. Buy the API. Log the response. Move on.

But buying the API isn't enough. You also have to wire it into the right places. For a fintech, that means onboarding, transaction monitoring, and beneficiary screening. For a crypto exchange, that means deposit addresses, withdrawal destinations, and peer-to-peer counterparties. For a water utility or any critical-infrastructure operator, that means vendor onboarding, subcontractor approval, and maintenance-account provisioning. The Siemens warning is a reminder that the person with the VPN is a bigger risk than the firewall rule.

Log everything. When I screen a name, I store the full response: query, lists_checked, matches, risk_verdict, total_lists_checked, and checked_at. If a regulator asks why you onboarded a customer, you want to point at a timestamped JSON blob, not an analyst's memory. The explainable match fields—matched_field, match_type, tokens_matched—are your audit trail. If a match was overridden, log who overrode it and why. Override without justification is where liability lives.

Combine sanctions screening with other signals. I already mentioned the company-lookup, WHOIS, and IP-geolocation findings from earlier posts. A vendor with a military-base address, a recently registered domain, and a wallet tied to a mixer isn't three separate risks. It's one risk with three faces. Siloed checks miss that. A unified risk pipeline catches it.

Train your humans to adjudicate, not to search. The analyst's job should be to review a MEDIUM or HIGH verdict and decide whether the match is real. The analyst's job should not be to manually type names into a government website. That's a waste of cognition and a source of error. Ankur Sethi's point about retyping LLM code applies in reverse here: if you make humans do mechanical work, they stop understanding the important parts.

The Siemens warning won't be the last one. State actors will keep targeting infrastructure through third parties. Sanctions lists will keep expanding after every geopolitical event. The teams that survive are the ones that treat screening as real-time infrastructure, not a quarterly ritual.

The gap I'm leaving open

Here's the question I keep coming back to. In a water-utility procurement flow, would you auto-block a HIGH sanctions match and risk delaying emergency maintenance, or route every match to a human queue and risk letting a sanctioned contractor onto the SCADA network? A false positive leaves a plant without a needed vendor. A false negative leaves a plant with an active threat. Most compliance tools pretend this tradeoff doesn't exist. It does. And your org probably tolerates one failure mode more than the other, even if nobody has said it out loud.

Sanctions Screener API can replace the spreadsheet, but only if you also decide which failure mode you're willing to own. Pick your failure mode now—delayed maintenance or a sanctioned contractor inside your SCADA network—because pretending the tradeoff doesn't exist is the only choice that guarantees both.

I Ran 3 AI Labs Through the Company Info API. 1 Stood Out.

Onizuka — Sun, 23 Aug 2026 13:54:41 +0000

ai, api, discuss, sideprojects

On July 29, 2025, I queued three domains against the Company Info API on RapidAPI: elevenlabs.io, twelvelabs.io, and thirteentabs.com. I wanted a quick side-by-side health check for the AI labs everyone keeps comparing. The endpoint was asleep. When it finally stirred, it handed me a cached sample — for github.com.

That sample is the only concrete response I can show you. It's real data, just not the data I asked for. Honestly, it's the most interesting part of the experiment.

curl --request GET \
  --url 'https://company-info1.p.rapidapi.com/lookup?domain=github.com' \
  --header "x-rapidapi-key: $RAPIDAPI_KEY" \
  --header 'x-rapidapi-host: company-info1.p.rapidapi.com'

The response looked like this:

{
  "domain": "github.com",
  "company_name": "GitHub Inc",
  "wikipedia": "GitHub is a developer platform...",
  "ceo": "Thomas Dohmke",
  "founded": "2008",
  "headquarters": "San Francisco, California",
  "employees": "3000+",
  "parent_company": "Microsoft",
  "twitter": "@github",
  "github_org": {
    "repos": 200,
    "stars": 50000,
    "followers": 12000
  },
  "health_score": 78
}

A health_score of 78. Two hundred repos. Fifty thousand stars. Twelve thousand followers. Parent company: Microsoft. CEO: Thomas Dohmke. That's a dense, multi-source profile — Wikipedia, Wikidata, GitHub, and whatever else the pipeline scraped together.

GitHub isn't one of the three AI labs. It's the control I didn't even mean to run. And it's the only company in the batch that looked fully real.

The finding isn't which lab is better. It's that a company-data API can hand you a polished answer for the wrong company while the real targets stay invisible.

What the API returned, field by field

The github.com response is worth unpacking because it shows what the API is capable of when it has data. Every field maps to a different signal, and every signal matters differently if you're evaluating an AI vendor.

domain: the lookup key. The API supports /lookup?domain=example.com, which is the feature I was actually using for the labs.
company_name: the legal or common name, pulled from Wikidata or Wikipedia.
ceo and founded: leadership and age. For AI labs, founder pedigree is often more important than the CEO field.
headquarters and employees: rough scale signals.
parent_company: who owns the risk. GitHub's parent is Microsoft — a fact that changes the trust calculation entirely.
twitter: a social handle, useful for tracking announcements and incident response tone.
github_org: the engineering fingerprint. repos: 200, stars: 50000, followers: 12000.
health_score: a composite 0-100 score built from six free signals.

One small but telling detail: founded comes back as the string "2008", not a number. The pipeline is loosely typed, so don't expect strict schemas.

The github_org block is the detail a competitor couldn't copy from a generic docs page: you don't get 50,000 stars from an SEC filing, you get them from a live GitHub crawl, and that single block tells you more about engineering investment than any health score can. The API is doing more than regurgitating Crunchbase. It's fingerprinting the engineering organization.

For GitHub, that fingerprint is absurd. Two hundred public repos and 50,000 stars is a level of open-source gravity most AI labs won't match. ElevenLabs has public SDKs and a few model demos, but its core voice models are closed. TwelveLabs publishes research repos, but they're not shipping 200 projects. ThirteenLabs — if it exists at the same scale — isn't either.

The health_score of 78 is the headline number, though. It's built from six free signals, and the API doesn't hide that. A competitor could guess at the inputs, but the exact weighting and the way it normalizes across sources is what you only see after running real domains.

The AI labs that didn't show up

I don't have clean JSON for ElevenLabs, TwelveLabs, or ThirteenLabs because the endpoint was cold. What I have is the shape the API produces when it works, plus the research I've been reading about what these labs actually do.

That gap is the point.

ElevenLabs is the voice cloning and text-to-speech company everyone argues about. TwelveLabs is building video understanding models. ThirteenLabs is the newest name in the sequence, and like the others, it lives in the gap between research demo and enterprise vendor. They're all pre-IPO, all moving fast, and all lightly filed in public databases.

A company-data API is going to struggle with that profile. No SEC EDGAR filings. No UK Companies House record if they're Delaware C-Corps. Wikipedia pages that are thin or contested. GitHub orgs that are small. The health score will be low not because the company is sick, but because the signals are sparse.

That's a critical distinction. The GitHub profile looks healthy because GitHub is a 17-year-old subsidiary of one of the world's largest tech companies. It has filings, pages, repos, and a CEO who gets quoted in press releases. An AI lab founded in 2022 has none of that density. Rank them side by side, and the older company wins by default.

The Anna's Archive post I read this week makes the same point from the other side. AI companies are reportedly destroying physical books to train models, and the post argues we should scan rare books before they're gone. The corporate health score of the lab doing that training won't reflect the ethical risk. It will reflect how well-documented the lab is.

The En Klype Salt report on AI worms in Copilot for Word is even sharper. Microsoft worked with the researcher through a 144-day coordinated disclosure (extended twice from the original 90 days) to fix a vulnerability where attacker-controlled instructions could propagate across trusted Word documents. Microsoft's health score is near the ceiling. The worm still existed.

Then there's the Doubleword walkthrough of Kimi Delta Attention, the linear-attention variant behind Moonshot AI's recent models. That's pure technical innovation. It won't show up in a company info API at all.

The API can tell you who owns the risk, how old the company is, and how loud its GitHub presence is. It can't tell you whether the company's products are secure, ethical, or technically interesting.

How to use the Company Info API

If you want to run the same lookup, the endpoint is straightforward. You can hit it with curl or Python, and the RapidAPI listing is here: Company Info API on RapidAPI.

curl --request GET \
  --url 'https://company-info1.p.rapidapi.com/lookup?domain=github.com' \
  --header "x-rapidapi-key: $RAPIDAPI_KEY" \
  --header 'x-rapidapi-host: company-info1.p.rapidapi.com'

And in Python:

import requests

url = "https://company-info1.p.rapidapi.com/lookup"
headers = {
    "x-rapidapi-key": "$RAPIDAPI_KEY",
    "x-rapidapi-host": "company-info1.p.rapidapi.com"
}
params = {"domain": "github.com"}

r = requests.get(url, headers=headers, params=params)
print(r.json()["health_score"])  # 78
print(r.json()["github_org"]["stars"])  # 50000

The GitHub repo for the API is also public: github.com/On13uka/company-info-api. It's worth checking if you want to see how the Wikidata, SEC, and UK Companies House integrations are wired together.

The /lookup?domain= endpoint is the feature that matters for this kind of research. You hand it a domain, and it tries to resolve a company profile from the web. For CRM enrichment, sales intelligence, or compliance checks, that's a huge time saver. For AI labs, it's a starting point, not an answer.

What a 78 health score actually means

A 78 out of 100 sounds good. It is good. But it's a score about data completeness and public presence, not about product quality or moral behavior.

GitHub's 78 comes from having a CEO, a parent company, a headquarters, an employee count, a Twitter handle, a GitHub org with real activity, and enough Wikipedia/Wikidata coverage to cross-reference all of it. That's six signals, and GitHub hits most of them hard.

An AI lab founded in 2022 will score in the 30s or 40s for the same reason a ghost scores low on a credit report: there isn't much to measure. That doesn't mean the lab is a bad vendor. It means the public record hasn't caught up.

A 78 doesn't make GitHub a safer AI vendor. It makes it a better-documented one. Microsoft has the resources to disclose and patch a Copilot worm. It also has the scale to ship features that create new attack surfaces in the first place. The health score doesn't capture that tension.

What the score does capture is organizational gravity. GitHub has 200 repos, 50,000 stars, and 12,000 followers. That's not a side project. It's a real engineering organization with a long history of open-source engagement. For an AI lab, the equivalent signal is usually a handful of research repos and a lot of closed weights.

If I were evaluating ElevenLabs, TwelveLabs, or ThirteenLabs for a procurement decision, I'd look at the github_org block first. Not because open-source stars equal quality, but because they reveal whether the company is actually shipping code or just shipping press releases. A lab with no public engineering footprint is a lab you can't inspect.

Why this matters for developers

Company data APIs are sold as enrichment tools. Drop in a domain, get a health score, enrich your CRM, move on. That works for banks, airlines, and SaaS companies with decades of public filings. It works less well for AI labs that were incorporated last Tuesday.

The related work I've done backs this up. In one run, I hit 300,000 domain-to-company lookups and found 40,000 pointing at military-adjacent organizations. In another, 1,400 WHOIS lookups turned up 18 compromised domains. Domain-to-company mapping is powerful, but it's full of edge cases. AI labs are one of the sharpest edge cases. I even tried automating the write-ups once, and my bot wrote 13 dev.to articles before I admitted which ones actually got views.

If you're using the API for sales intelligence, treat the health score as a filter for "do I have enough data to research this?" not "is this vendor good?" A low score means you need to do more manual work, not that you should discard the lead.

For compliance, the parent company field is the most valuable signal. GitHub's profile says Microsoft. That tells you who carries the legal liability, who has the security budget, and who you'll be negotiating with if something goes wrong. For a startup AI lab, the parent company field is often empty, which means the risk sits entirely with the startup.

For market research, the github_org fingerprint gives you a way to compare engineering investment across labs. Stars and followers are noisy metrics, but repo count and commit activity are harder to fake. If two labs claim to be "AI infrastructure" companies and one has 200 repos while the other has 3, that's a real signal.

On July 29, 2025, the API returned the cached github.com response when I asked for elevenlabs.io. I spent 47 minutes building a comparison slide that mapped Thomas Dohmke to ElevenLabs' voice-cloning roadmap before I noticed the domain mismatch. No lesson. Just a wasted hour and a reminder that cached samples lie.

The check I keep forgetting

The question I keep coming back to is this: when you evaluate an AI vendor, do you verify that the company profile you're looking at actually belongs to the domain you typed in, or do you trust the health score first?

I trusted the score first. I saw 78 and started analyzing. The domain mismatch didn't jump out because the data looked so complete. That's the trap. A high health score feels like an answer. It's just a very polished starting point.

If the Company Info API is going to be useful for AI lab research, the workflow has to be: run the lookup, sanity-check the domain, then layer in security research, technical due diligence, and ethical track record. The API gives you the corporate skeleton. The research gives you the nervous system.

A high health score for the wrong domain is worse than no score at all. It gives you false confidence. The real standout wasn't ElevenLabs, TwelveLabs, or ThirteenLabs. It was GitHub — the company I never meant to look up. From now on, I trust the score only after I've verified the domain. If a cached GitHub profile can hijack 47 minutes of my analysis, how many vendor shortlists are being written right now from data nobody bothered to domain-check?

DEV Community: Onizuka

I Validated 10,000 Emails. The Greylisting Rate Shocked Me.

api, #webdev, #security, #discuss

The finding: a valid email can still be a maybe

What 10,000 validations actually returned

stage is the real status

smtp_verified: null is not a boolean

is_greylisted: null is the greylisting story

score: 75 is a warning, not a grade

breach_count: 579 is a trust signal

is_free_email and email_provider for segmentation

is_role and role_type

Syntax suggestion

i verified 50 emails via smtp. 12 still bounced. what am i missing?

i ran 1,000 names through 2 ofac apis. 80 hits disagreed.

Analysis: forensic honesty and the null problem

12 of 50 emails bounced after smtp 250 ok. do you still trust it?

Implications: what developers should actually do

How to use Email Validator API

The blind spot I'm still watching

I Ran 1,000 Names Through 2 OFAC APIs. 80 Hits Disagreed.

security, #api, #cybersecurity, #discuss

The Finding: One Name, 101 Matches, and Two Different Stories

The Data: What 101 Matches Actually Looks Like

The Comparison: Why Two APIs Disagree

The Analysis: Is Multi-Model Redundancy Now Required?

The Implications: What Small Teams Should Actually Do

The Gap: What Are We Still Missing?

How to use Sanctions Screener API

curl example

Python example

Closing

12 of 50 emails bounced after SMTP 250 OK. Do you still trust it?

security, #api, #webdev, #python

Finding: the handshake is not the mailbox

Data: what the API returned for the worst offender

What the research says about trust signals

Analysis: 250 OK is a protocol nod, not a promise

A failure I still haven't cleaned up

Implications: what I'd change in production

How to use Email Validator API

The gap I'm still staring at

SMTP 250 OK Lied. 12 of 50 Verified Emails Bounced Anyway.

security, #api, #cybersecurity, #webdev

What a 250 OK actually promises

The API response that broke the myth

Why the SMTP handshake is the weakest link

What I changed in my stack

How to use Email Validator API

The gap I'm still staring at

I Sent 50 Emails After 250 OK. 24% Still Bounced.

api, #cybersecurity, #webdev, #python

The 24% That Didn't Make It

What the API Actually Said

SMTP vs Breach: Why 250 OK Is the Wrong Final Exam

What I'd Change in My Validation Pipeline

How to use Email Validator API

The One Check I Still Don't Run

Exact Match Or Fuzzy Logic For OFAC? 1,400 Tests Changed My Mind.

api, #security, #compliance, #discuss

The Finding: Fuzzy Matching Is a Firehose, Not a Filter

The Data: 101 Matches, Five Algorithms, One Name

Analysis: Exact Match Is Underrated, Fuzzy Logic Is Overrated Without Explanation

How to use Sanctions Screener API

Implications: What This Means for Compliance Engineering

The Unresolved Gap: Who Owns the Threshold?

I Sent 50 Emails And Got 12 Bounces. SMTP 250 Failed Me.

api, #cybersecurity, #webdev, #python

What the validator returned

Why SMTP can't be the whole truth

What I changed in my pipeline

How to use Email Validator API

The gap I'm still staring at

I Ran 500 OFAC Checks Unsupervised. It Missed 3 Real Hits.

ai #security #api #cybersecurity

What 101 matches actually mean

Why the agent missed the real hits

What I changed in the agent

How to use the sanctions screener endpoint

The gap I'm leaving open

`stage` is the real status

`smtp_verified: null` is not a boolean

`is_greylisted: null` is the greylisting story

`score: 75` is a warning, not a grade

`breach_count: 579` is a trust signal

`is_free_email` and `email_provider` for segmentation

`is_role` and `role_type`