What an email validation API can honestly verify
Before you send, you can reliably check: syntax, whether the domain has an MX record (or implicit MX) and can receive mail at all, whether it is a known disposable provider, whether it is a role account like support@, and whether it looks like a typo of a common provider. You cannot reliably verify that a specific mailbox exists — and any vendor promising otherwise is selling you a confidence level, not a fact.
The checks that are worth doing
| Check | Decision it supports |
|---|---|
| Syntax | Reject structurally malformed input outright. |
| MX / implicit MX | Does the domain advertise any mail route at all? |
| Disposable domain | Flag known throwaway providers. |
| Role account | support@, billing@ — may not be one person, and may not want your product email. |
| Typo suggestion | "Did you mean gmail.com?" — recovers real signups. |
The limit, stated plainly
DNS cannot prove a mailbox exists. It proves the domain can receive mail. Those are very different claims, and the gap between them is where the email-verification industry sells confidence it does not have.
SMTP probing does not close the gap either. Catch-all domains accept everything. Greylisting defers you. Some servers deliberately lie about recipient validity precisely to defeat probes, and aggressive probing is a good way to get your IP blocked. So:
deliverable_domain — the domain can receive mail and nothing looks wrong. The
response carries mailboxVerified: false and catchAllChecked: false,
always, because we do not do those things and we are not going to imply we do. Treat any
validation result as risk reduction, never as a delivery guarantee.
The typo check, and why it's fussy
Suggesting gmail.com for gmial.com is easy. The hard part is
not suggesting a correction when the domain is simply an unfamiliar company. A naive edit
distance will happily "correct" acme.com to me.com, which is a real
domain and a real disaster in a signup flow. We use Damerau-Levenshtein with a length-gap guard so
that short legitimate domains are not mangled into popular ones.
Implementation
curl https://api.canitsend.com/v1/validate \
-H 'Authorization: Bearer snd_live_...' \
-H 'Content-Type: application/json' \
-d '{"email":"[email protected]"}'
Validate on the server. Keep the user's original input so you can offer a correction rather than silently rewriting it. Distinguish hard failures (malformed, no MX) from risk flags (disposable, role) — they deserve different product behaviour.
API reference · Try the checker
Frequently asked
Can an API check if an email address really exists?
Not reliably. DNS proves only that the domain can receive mail, never that a particular mailbox exists. SMTP probing — connecting and issuing RCPT TO — is inconclusive in practice: many servers accept all recipients (catch-all), many temporarily defer, and some deliberately misreport recipient validity to defeat exactly this probe. A validation result is risk reduction, not proof.
What is a catch-all domain and why does it break verification?
A catch-all domain accepts mail for every address at the domain, whether or not the mailbox exists. An SMTP probe against a catch-all returns success for anything, so it tells you nothing about whether the specific address is real. A large share of business domains are catch-alls.
Should I validate emails on the client or the server?
Server. Client-side checks are a UX affordance and trivially bypassed. Also: send the address in a POST body, not a URL query string — URLs end up in server access logs, browser history and Referer headers, and an email address is personal data you did not intend to scatter. Our /v1/validate endpoint is POST-only and refuses GET for exactly this reason.
Related
- An SPF, DKIM and DMARC API — A JSON API for SPF, DKIM and DMARC over live DNS — correct 10-lookup counting, record flattening, and bulk auditing.
- Setting up email authentication, in the right order — A working sequence for SPF, DKIM and DMARC that doesn't reject your own mail on the way.
- Looking for an MXToolbox alternative? — MXToolbox is a good diagnostic site.
Automate this → — free tier, public pricing, API key emailed in about thirty seconds. No call with anyone.