webkitapi.dev

Email verification

Does this mailboxactually receive mail?

Validating syntax is worth nothing, everyone can do it. The expensive question is existence, and answering it takes MX resolution, an SMTP probe and a sending reputation.

Get a free key See the reference
POST /v1/email

Request

curl https://api.webkitapi.dev/v1/email \
  -H "Authorization: Bearer $WEBKIT_KEY" \
  -d '{"email": "john.doe@gmial.com"}'

Response

{
  "verdict": "undeliverable",
  "reasons": ["domain_typo"],
  "suggestion": "john.doe@gmail.com",
  "checks": { "syntax": "pass", "typo": "fail" }
}

What gets checked

Eight checks, cheapest first.

The order is the cost model. A syntactically impossible address never costs a DNS query, and a domain with no mail server never costs an SMTP connection.

  • Syntax and normalizationRFC 5322, plus the length limits servers actually enforce, and internationalized domain encoding.
  • Provider rulesGmail, Outlook, Yahoo and Proton publish their local-part constraints. Applied before any network call, they rule out addresses that cannot exist, for free.
  • Domain typoWeighted Damerau-Levenshtein distance, scored against AZERTY, QWERTY and QWERTZ layouts. This is the piece nobody ships properly.
  • Disposable domainA snapshot embedded in the library, a living corpus on the API side.
  • Role addresscontact@, support@, billing@. Mail arrives, but there is no person behind it.
  • MX recordsA domain with no MX but an A record still accepts mail, and treating the two the same would bounce real addresses.
  • SMTP probeConnect, MAIL FROM, RCPT TO, never DATA. Nothing is ever delivered to the address being checked.
  • Catch-all detectionA random local part is probed on the same domain. If it passes too, the server accepts everything and the verdict becomes unknown.

The typo

gmial.com is a mistake, gmx.de is not.

You cannot tell by looking at a domain whether it was mistyped. The question the engine answers is a different one, and it is computable: is this domain suspiciously close to a far more widely used domain, while being unknown itself?

Three signals have to agree, and six veto rules can cancel the suggestion. The strongest: a domain already in the reference list is never corrected. That is what stops us offering gmx.net to somebody who wrote gmx.de.

  • The keyboard layout mattersn and m are neighbours on QWERTY and are not on AZERTY, which decides whether gmail.con reads as a slipped finger.
  • Distance normalized by lengthOne edit across five letters is weak evidence, the same edit across twelve is strong. A fixed threshold of 2 is exactly what makes the old tools noisy.
  • French providers are in the listlaposte.net, orange.fr, sfr.fr, free.fr, wanadoo.fr. A list that ignores them is useless in France, and those are precisely the domains French users mistype.
  • Never an automatic correctionWe return a suggestion. Applying it on the user's behalf turns a feature that is right 94 percent of the time into tickets from the other 6.

The engine runs offline inside the npm and PyPI libraries, with no key and no network.

Questions

Including the awkward answers.

Do you send mail to the address being checked?
No, never. The SMTP conversation stops at RCPT TO and the DATA command is never issued, so nothing is delivered.
Why is there no confidence score?
A percentage nobody has calibrated is a claim we cannot stand behind, and it hands you a threshold decision you have less information than we do to make. The reasons array carries what a score destroys.
What does the unknown verdict mean?
That we could not tell. A catch-all domain accepts every address, a greylisting server asks us to come back later. Answering deliverable or undeliverable in those cases would be inventing a certainty.
Is a disposable address rejected?
It is marked risky, not undeliverable: mail really does arrive there. Whether that disqualifies a signup is your policy, not ours.