What Is an Email Verification API?

What is an email verification API?

An email verification API is an HTTP endpoint that answers one question about one address: can a mailbox at this address receive mail, right now, without anything being sent to it. You POST an address with a bearer token, and you get back a verdict and a reason.

The reason the question needs a network service at all is that the answer lives on somebody else's mail server. Syntax and DNS you could check in your own code in an afternoon. The mailbox-level answer requires opening an SMTP conversation with the recipient's mail server from an IP address that server is willing to talk to, and that is an operational problem rather than a coding one.

What you are buying, in practice, is four things bundled: a pool of outbound IP addresses that are kept off blocklists, retry and backoff logic against servers that defer unfamiliar connections, maintained lists of disposable domains and catch-all fingerprints, and a normalised response shape so you write one integration rather than one per receiving mail platform.

The category name is unstable and the words are used interchangeably in the market. Some vendors call the same endpoint an email validation API, some an email verifier API. The distinction worth holding is between a string check and a live check, described in the next section, because it is the difference between catching most typos and catching most bounces.

What checks does an email verification API run, and in what order?

Four checks, run in ascending order of cost, and an address that fails an early one never reaches the later ones.

1. Syntax. The address is parsed against RFC 5322 and normalised. This rejects a malformed local part, a missing at-sign, a doubled domain and the typo family (gmial.com, a trailing comma pasted from a spreadsheet). It costs nothing and it clears a real share of any raw list.

2. DNS and MX. The domain is resolved and its mail exchange records are read. A domain with no MX record and no fallback A record cannot receive mail at all, whatever the local part says. This is one DNS query, it is cacheable per domain, and it settles a whole class of dead addresses cheaply.

3. SMTP handshake. The service connects to the highest-priority MX host and asks whether the mailbox exists. Nothing is sent. This is the expensive step: it opens a TCP connection to a third party, it can be deferred or refused, and it is why the checks run in this order.

4. Classification. Everything the first three could not settle: is the domain accepting every address, is the domain disposable, is the local part a role alias. This pass is what produces a risky verdict rather than forcing an ambiguous address into a binary yes or no.

Ordering matters to your bill as well as to latency. Any API that charges per address and runs the handshake first is paying for a TCP connection to prove something a free string parse already knew. Where a vendor exposes a cheaper syntax-and-MX-only mode, that mode is a different product with a different catch rate, and worth checking before you assume the price you were quoted covers the handshake.

What does the SMTP handshake actually send?

It sends the envelope of a message and then abandons it before the message exists. The conversation is roughly: connect to the MX host on port 25, read the 220 greeting, send EHLO with a hostname, send MAIL FROM with a sender address, send RCPT TO with the address being checked, read the reply, then send RSET or QUIT.

The RCPT TO reply is the entire answer. A 250 means the server would accept mail for that recipient. A 550 means it would not, usually with text naming the reason (no such user). A 4xx means try later rather than never. The DATA command, which is where an actual message body would be transmitted, is never sent, so nothing is queued, nothing is delivered, and nothing appears in anyone's inbox.

The MAIL FROM address is the part API designers get wrong. Many receiving servers evaluate the sender before answering about the recipient, and some reject or misreport when the sender domain does not resolve, so a verification service uses a real, resolvable sending domain of its own. This is also why the connecting IP matters: a server that has blocklisted the source will refuse the conversation, and a refusal is not evidence about the mailbox.

Two consequences follow for anyone thinking about building this. First, most large cloud providers restrict outbound traffic on port 25 by default and require an explicit request to lift it, so the naive implementation fails in production even though it worked on a laptop. Second, verification traffic looks exactly like address harvesting to a receiving server, so an IP that runs it at volume without reputation management stops getting answers. Those two facts, more than the protocol, are what the category sells.

What do the verdicts and reason codes mean?

Four verdicts, and a reason code that says which check produced it. Deliverable means the mail server confirmed the mailbox. Undeliverable means it refused. Risky means the checks completed and the answer is genuinely ambiguous. Unknown means no answer was obtained, so nothing is claimed.

Four rather than two is a design decision worth insisting on when you compare APIs. A binary valid or invalid flag has to put catch-all domains, role addresses and disposable domains somewhere, and either choice is a lie: called valid they bounce, called invalid they discard real prospects at companies whose mail servers happen to be configured permissively.

The reason code is what makes a risky verdict actionable, because the three common causes want three different decisions. accept_all means the domain answered yes to everything, so route it to a segment you are willing to risk. role_address means info@ or sales@ or support@, deliverable but landing in a shared inbox, so route it away from one-to-one sequences. disposable_domain means a burner that will be gone before a reply is, so drop it.

Map the verdicts onto your own sending rules once, in one place, rather than letting each consumer of the data invent a rule. The mapping that survives contact with production is: deliverable sends, undeliverable goes to a permanent suppression list, unknown is re-queued for a later run, and risky is split by reason code. Store the reason and the timestamp next to the verdict, because a verdict with no date and no cause cannot be re-evaluated later.

How does an email verification API detect a catch-all domain?

By asking the same server about an address that certainly does not exist. The service issues a second RCPT TO for a random local part at the same domain, something no human would own, and if the server answers 250 to that too, the domain accepts everything and its yes about your real address proves nothing.

That is why catch-all detection needs an extra round trip and why it is the check that cheap tiers quietly skip. An API that runs one handshake per address and reports the 250 as deliverable will return a clean-looking list that bounces, and the bounce arrives after the domain has already accepted the mail, because the rejection happens internally at the recipient rather than during the conversation.

Catch-all configurations are common at small companies and at organisations that would rather receive a misaddressed message than bounce it, which makes them an ordinary part of a B2B list rather than an edge case. Glossary data in this repo puts them at 15% to 25% of B2B addresses, which is far too many to delete and far too many to trust blindly.

The useful posture is to keep them, label them, and send to them as a separate segment so their bounce rate is measured on its own and does not contaminate the number you use to judge the rest of your list.

How does an API detect disposable and role-based addresses?

By list lookup, not by protocol. Neither flag is something a mail server will tell you, so both are pattern matching maintained on the vendor's side, which makes freshness the thing you are actually paying for.

Disposable detection matches the domain against a maintained set of throwaway mail providers, and increasingly against MX fingerprints, because a burner service can spin up thousands of vanity domains that all point their mail exchange records at the same handful of hosts. Domain-list-only detection ages badly for exactly that reason, and a provider that never mentions how the list is maintained is worth a question.

Role detection matches the local part against a set of shared-inbox conventions: info, sales, support, admin, billing, contact, hello, help, team, careers. This is a routing signal rather than a validity signal. Role addresses are usually perfectly deliverable, they are simply read by a rota rather than a person, and they distort reply-rate measurement because a shared inbox behaves nothing like an individual.

Free addresses are a third flag some APIs return and it means something different again: gmail.com, outlook.com and their equivalents are real mailboxes that happen not to be corporate. For B2B work a free-domain flag is a data-quality signal about the record rather than a deliverability problem with the address, and treating it as a failure throws away founders and consultants who genuinely work from one.

Should verification run synchronously or as a bulk job?

Synchronously for one address at the point of capture, asynchronously for anything that resembles a list. The split is forced by the protocol rather than chosen for convenience: an SMTP handshake takes as long as the remote server takes, so a synchronous endpoint holding a connection open across thousands of addresses spends most of its life waiting on the slowest servers in the batch.

A single-address endpoint answers in roughly a second or two when the receiving server is responsive, which is fast enough to sit inline in a signup form or a lead capture handler. Set a client-side timeout and decide in advance what you do when it expires, because the wrong answer is blocking a signup on a third party's latency. Accept the address, mark it unverified, and re-check it out of band.

A bulk endpoint takes the list and returns a job identifier immediately. From there APIs differ in one important way: some deliver results by webhook to a callback URL you register, others expect you to poll a status endpoint until the job reaches a terminal state. Polling is simpler to build and needs no public endpoint of your own. Webhooks are cheaper at scale and need signature verification and an idempotent handler, since a delivery can arrive twice.

Whichever you get, handle every terminal state rather than only the happy one. A bulk run that completes with some rows failed often settles in a distinct status, and a client written to wait for a plain completed status hangs forever on exactly the runs you most need to look at. On the Cleanlist API, asynchronous work returns a workflow_id and a poll_url, there is no v2 webhook delivery, status polls cost 0 credits, and completed_with_errors is terminal alongside completed.

How should an email verification API return errors?

An undeliverable address is HTTP 200, not 4xx. The request succeeded, the answer is simply that the mailbox is dead, and an API that returns an error status for a valid question breaks every client that treats non-200 as a retryable failure. Reserve the error range for problems with the request itself.

The conventional mapping is worth checking against any API you evaluate: 400 for a malformed body, 401 for a missing or bad key, 402 or 403 for an exhausted balance or a scope the key does not hold, 404 for an unknown job id, 422 for a well-formed request the service cannot process, 429 for rate limiting, and 5xx for the vendor's own faults. Only 429 and 5xx are worth retrying blind.

The field that saves the most debugging time is a machine-readable error code separate from the human-readable message, because message text changes without notice and a client that pattern-matches on prose breaks on a copy edit. The Cleanlist API returns a single error envelope of code, problem, fix, retryable, docs_url and request_id, and the retryable boolean is the one to branch on rather than inferring intent from the status.

Log the request id on every failure. The difference between a vendor support thread that resolves in one reply and one that runs for a week is almost always whether you can hand over an identifier that points at the exact request.

How do rate limits, timeouts and retries work?

Every verification API imposes a per-key and usually a per-organisation ceiling, and the client design that survives all of them is the same: size the dispatch loop under the lower of the two limits, widen the delay on each miss rather than polling on a fixed interval, and stop on a terminal status.

Read the ceiling from the vendor's documentation rather than discovering it from 429s. Cleanlist publishes 60 requests per minute per organisation, 30 per minute per API key, and 60 People Searches per UTC day per key, and the same ceilings apply whether you call the REST API or drive the same tools through the MCP server, because both reach one wallet and one quota.

Timeouts need two layers. The vendor has its own SMTP timeout against the receiving server, which is what turns a silent mail server into an unknown verdict rather than a hung job, and you need your own HTTP timeout on the call to the vendor. Setting the second one shorter than the first is the classic mistake: your client gives up, retries, and pays twice for one answer.

Retry only on 429 and 5xx, with exponential backoff and jitter, and never retry a verdict you dislike. Unknown is an answer, and the correct response is to re-queue that address for a later batch, not to hammer it, because unknown usually means the receiving server is greylisting, which is to say deliberately deferring an unfamiliar connection in the expectation of a retry after a delay measured in minutes to hours.

Check for an idempotency key before you build a retry path, because whether a repeated request is a repeated charge depends entirely on the vendor. On the Cleanlist API the enrichment routes have no idempotency key, so a retried dispatch is a new billable workflow, while ingest routes do accept an idempotency_key and a replay inside 24 hours returns idempotency_replayed true without charging again. Keep your own ledger of what you have already resolved either way.

How accurate is an email verification API, and how do you test the claim?

Accuracy claims from verification vendors are close to unfalsifiable as published, so test them yourself with a seed list. Every vendor in this category advertises a number in the high nineties, the numbers are not measured the same way, and none of them are measured on your list.

Build the seed list from addresses whose truth you already know: mailboxes you control that certainly exist, mailboxes you have deliberately deleted, a domain you own configured as catch-all, a handful of disposable addresses, several role aliases, and, most importantly, a sample of your own real records with their recorded bounce outcomes from a previous send. A few hundred addresses is enough to separate two vendors.

Then measure four things rather than one. False deliverable rate is the number that costs you money, because those are the bounces you paid to avoid. False undeliverable rate is the one nobody measures and it is expensive in a quieter way, since every wrongly rejected address is a prospect deleted. Unknown rate tells you how much of the list the service simply could not settle, and a vendor with a spectacular accuracy figure and a large unknown bucket has moved its hard cases rather than solved them. Latency at your batch size tells you whether the thing fits your pipeline at all.

Run the same seed list against every candidate on the same day, because mail servers change behaviour and a comparison across two weeks is not a comparison. Keep the list and re-run it quarterly against whoever you chose, since a verification service degrades quietly: the disposable list ages, the IP pool picks up a blocklisting, and nothing in your metrics announces it.

For context on how coverage differs from accuracy: on the Cleanlist 500-Lead Enrichment Benchmark, 2026, a waterfall across 25+ providers returned a verified work email for 98% of 500 stratified B2B leads and a direct dial for 85%. That measures how often a contact could be found and verified, which is a different question from how often a verdict on an address you already hold is correct. Do not let a vendor answer one with the other.

What does an email verification API cost?

Verification is priced per address checked, in volume tiers, and the charge normally lands whether the verdict is good or bad, because the work is identical either way. That is the first thing to confirm in a contract, since a list that is 40% dead still costs full price to discover that.

Three structural details move the real number more than the headline rate. Whether credits expire, because an annual pack that lapses is a higher effective price than a smaller monthly one you consume. Whether unknown verdicts are billed, since they are an answer the vendor could not give and they are typically a few percent of any batch. And whether the price you were quoted includes the SMTP handshake and catch-all detection, or only syntax and MX, which is a cheaper product with a materially lower catch rate.

Free tiers in this category are capped rather than absent, because each check costs the vendor DNS queries and SMTP connections from IP addresses that have to stay off blocklists. As of the pricing pages fetched on August 7, 2026: Verifalia published 25 daily free credits, ZeroBounce listed 100 validation credits refilling monthly, and Emailable included 250 free credits at signup. AbstractAPI published a free tier of 100 requests with paid plans from $17 a month billed annually. Read each vendor's current pricing page before planning around any of these, since they move.

On Cleanlist the rate is 1 credit for a verified work email, 10 for a direct dial, 11 for both, and 0 for a lookup that returns nothing, with verification bundled into that price rather than sold separately. Plans are Starter $79 a month for 1,500 credits, Pro $229 for 5,000 and Scale $599 for 15,000, each 25% cheaper billed annually. API access starts on Pro. The free plan includes 30 credits a month, and the free browser checker at /tools/email-verifier runs 25 checks per IP per day with no account, covering syntax, MX, disposable and role but deliberately stopping before the SMTP handshake.

Does Cleanlist have an email verification API?

Not as a standalone route. There is no /verify endpoint on the Cleanlist public API to point at addresses you sourced somewhere else. Verification runs as a step inside enrichment: every address the waterfall produces is checked for syntax, DNS and MX and an SMTP handshake, with catch-all, disposable and role domains flagged rather than silently passed through, and that check is part of what the 1-credit verified email buys.

So the fit depends on which job you actually have. If the job is finding and verifying contacts, the enrichment API does both in one call and you are not billed for a miss. If the job is scoring a list you already own, a dedicated verification API is the better instrument and you should buy one. That is the honest answer even on a page that would rather sell you something, and it is why the verification vendors in the Cleanlist pool, ZeroBounce and Emailable among them, are named here as suppliers rather than compared against.

The API itself is REST at api.cleanlist.ai/api/v2, roughly thirty endpoints, authenticated with a Bearer clapi_ key checked against fourteen OAuth scopes. Search and every read cost 0 credits, paid bulk work is gated behind a signed quote from the credits estimate endpoint with a five-minute life, and the OpenAPI description is published openly. Access starts on the Pro plan at $229 a month, and the 14-day Scale trial (250 credits, 3 seats, no card) excludes both the API and the MCP server.

The list of what it does not do is published on the product page rather than discovered in integration, which is the disclosure you should demand from any vendor in this category: no webhooks on v2, no idempotency key on the enrichment routes, no natural-language search endpoint, no published uptime SLA and no SOC 2 report as of August 22, 2026. If procurement needs an availability commitment, raise it before you build.

Where should verification sit in your pipeline?

At three points, and the third is the one most teams skip. Verify at capture, inline and synchronously, so a mistyped address never enters the database. Verify immediately before a send, because that is the only check that speaks to the list you are about to touch. Verify on import, whenever records arrive from an event, a partner or a purchased file, before they are merged into anything you already trust.

Verify before you enrich rather than after. Checking an address costs a fraction of building a full contact around it, so spending the cheap check first to learn that a mailbox is dead avoids spending the expensive one on a record that cannot be used. Cost per valid record, not cost per call, is the number to optimise.

Re-verifying an entire database on a calendar is the expensive habit and it spends money in the wrong place. A quarterly sweep of a large CRM pays to check the majority of records that nobody will email this quarter, while the segment that does get sent to has aged since the sweep anyway. Verifying the segment you are about to send to costs less and answers a fresher question. The exception is a CRM that routes on data quality, where lead scoring or territory assignment reads the email field continuously, so the freshness has to be maintained rather than fetched.

Store three fields alongside the address, not one: the verdict, the reason code, and the timestamp of the check. A verdict with no date cannot be aged out, and a verdict with no reason cannot be re-evaluated when you change your sending rules. Cognism puts B2B data decay at about 22.5% a year, so a verification result is a dated observation rather than a permanent property of the record.

Keep undeliverable addresses in a suppression list rather than deleting the record outright. Delete it and the next import from the same source reintroduces the address, you pay to verify it a second time, and you risk sending to it in the window before you do.

What can an email verification API not tell you?

Five things, and they are the five people most often assume are covered. It cannot tell you that the person still works there, that the message will reach the inbox rather than the spam folder, that the address is not a monitored spam trap, that your sending domain is configured correctly, or that contacting this person is lawful where they live.

A mailbox that is still provisioned after somebody leaves verifies exactly like an active one. That is the gap between verification and enrichment: verification says the mailbox is alive, enrichment says whose it is and what they do now.

Inbox placement is decided after acceptance, by the receiver's spam filtering, which reads your authentication, your sending history, your complaint rate and your content. A deliverable verdict means the server will accept the mail, and nothing about where the mail goes next.

Spam traps are the case worth naming explicitly, because they defeat every check on this page by design. A recycled trap is an abandoned mailbox a receiver has reactivated to catch senders working from old lists, and it accepts mail, so it verifies clean. The only defences are provenance and recency: do not send to addresses you have not touched in a year, and do not buy lists.

Sender reputation has several inputs and verification removes one of them. SPF, DKIM and DMARC have to be configured on your sending domain, a new domain has to be warmed rather than switched on at full volume, and complaint rate is weighted more heavily than bounces by most receivers. Any verification vendor implying its API protects your reputation on its own is overselling. Legality is jurisdictional and is not a data question at all: GDPR, CASL and their equivalents govern whether you may contact somebody, and no verdict from any API speaks to it.