Best email verifiers for developers
Developers integrating email verification are choosing between four patterns: a local syntax check, a DNS lookup, a synchronous API call at the form, and an asynchronous batch job, each with different failure modes.
How this was compared
Figures read from each vendor's own pages in September 2026. Where a vendor is missing from a column, we could not read it rather than estimating.
The short version
- Latency budget, since anything synchronous at a signup form competes with the user's patience.
- Failure behavior, because every one of these patterns can fail and the form must still work.
- Cost per check, which differs by three orders of magnitude across the four patterns.
- What each pattern can actually establish, which is much less than its name suggests.
- Operational burden: retries, queues, webhooks and what happens when the vendor is down.
At a glance
| 10,000 addresses | Credit expiry | Bills unknowns | |
|---|---|---|---|
| ZapBounce | Not a verification vendor | ||
| An MX record lookup in your own code | Not a verification vendor | ||
| A synchronous API call with a short timeout | Not a verification vendor | ||
| An asynchronous batch job with webhooks | Not a verification vendor | ||
| A permissive regular expression | Not a verification vendor | ||
| A disposable domain list lookup | Not a verification vendor |
Vendor figures read from their own pricing pages in September 2026. Confirm before purchase, because prices move.
The ranking
Best first, with the situation each one wins and the situation it loses.
ZapBounce
An API that returns unresolved as a first-class result with a reason, instead of forcing a four-state reality into a boolean. Those responses are not billed, so an integration that retries them costs nothing.
- Best for:
- A signup form or a pipeline where collapsing unknown into invalid would reject real customers.
- Not for:
- A team that needs a library in every language today, or production references before it commits. We have neither yet.
An MX record lookup in your own code
One DNS query against the domain. Costs nothing, adds a few milliseconds, and eliminates typo domains such as gmial.com entirely, which is a large share of real signup errors.
- Best for:
- Every signup form, as the first check after a permissive syntax test.
- Not for:
- Confirming a mailbox, which a DNS record says nothing about.
A synchronous API call with a short timeout
Catches what DNS cannot: the mailbox that does not exist at a domain that does. Must fail open, because a receiving server refusing a probe is common and is not the user's fault.
- Best for:
- Signup forms where a wrong address costs you the customer relationship, such as an account identifier.
- Not for:
- Any flow where the call blocking would stop a purchase, since an SMTP probe depends on a third party's server responding.
An asynchronous batch job with webhooks
The only workable pattern above a few thousand addresses. Submit the file, receive a callback, process the result. Polling a large job wastes both sides' time.
- Best for:
- Cleaning a database export or an imported list before a campaign.
- Not for:
- Anything a user is waiting for, since a large batch takes hours against servers that rate-limit.
A permissive regular expression
Catches a pasted sentence and a missing @. Keep it loose: plus addressing and apostrophes are legal, and a pattern stricter than the specification rejects exactly the technical users you want.
- Best for:
- The first line of defense, before you spend a DNS query.
- Not for:
- Anything else. A well-formed address proves nothing about whether a mailbox exists.
A disposable domain list lookup
A local list check rather than a network call, which makes it the cheapest useful filter available and completely deterministic.
- Best for:
- Products where throwaway signups are the problem rather than typos.
- Not for:
- Catching typos or confirming mailboxes, neither of which a domain list addresses.
Our own first place, and what it does not cover
When none of these is the answer
For an internal tool with ten users, none of this is worth building. Accept the address, send the mail, and handle the bounce if it comes. Verification pays for itself at volume and at stakes, not at a form three people use.
Questions people ask
Should a verification call block a signup?
No. Use a short timeout and fail open. A server refusing our probe is common, and rejecting that registration loses you a user over a third party's rate limit.
Which pattern gives the best return for the least code?
The MX lookup. One DNS query, no vendor, no cost, and it removes typo domains completely, which is a large share of what goes wrong at a form.
How should a batch job be structured?
Submit, then receive a webhook. A large list means live SMTP connections to servers that rate-limit, so the job takes hours and polling it is wasteful for everyone.
Run the same sample through two of them
100 free checks a month, no card. Compare how many addresses each one declined to judge, which matters more than either accuracy claim.