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.

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.

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.

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.

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. Published estimates of how common they are vary, and none of them is measured the same way: the Cleanlist AI glossary puts catch-alls at 15% to 25% of B2B addresses, and Mailtrap's 2026 review of the category, read September 7, 2026, reports catch-alls at up to 30% of servers inside B2B lists. Any figure in that band 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.

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.

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 AI 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.

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 AI 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.

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 AI 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 AI 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.

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 AI 500-Lead Enrichment Benchmark, 2026, a waterfall across 25+ providers returned a verified work email for 98% of 500 stratified B2B leads and a phone number 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.

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 read on September 1, 2026 for the Cleanlist AI B2B data free-tier census: Verifalia published 25 daily free credits that reset at midnight GMT and do not bank, ZeroBounce listed 100 validation credits refilling monthly on a plan that requires a business or premium domain, and Emailable included 250 free credits at signup with unknown results not charged. AbstractAPI, read again on September 7, 2026, publishes a free plan of 100 validations with no card and 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 AI the rate is 1 credit for a verified work email, 10 for a phone number, 11 for both, and 0 for a lookup that returns nothing, with verification bundled into that price rather than sold separately. Validating an address you already hold is metered separately at 0.5 credits, which on Starter ($49 per seat a month for 750 credits per seat) works out at $32.67 per 1,000 addresses checked, and $24.67 per 1,000 billed annually. Starter is $49 per seat a month with 750 credits per seat, Pro is $89 per seat with 1,500 and credit levels up to 100,000 a month, and Enterprise is custom. Annual billing takes 25% off. API access starts on Pro. The free plan includes 50 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.

Not as a standalone route. There is no /verify endpoint on the Cleanlist AI 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 AI 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. 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 $89 per seat a month, and every new workspace starts with 14 days of Pro (3 seats, 250 credits, every Pro feature).

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.

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.

The number all of this is protecting is the bounce rate: under 2% keeps a sending domain out of trouble, 2% to 5% signals a list-quality problem that is still fixable, and above 5% does reputation damage that takes weeks of reduced volume to undo. The per-segment detail and the separate threshold for cold outbound are at /learn/bulk-email-verification.

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.

Between $5.33 and $39.00 per 1,000 addresses at published entry-plan prices, a seven-fold spread across vendors selling the same four checks. Every figure below is that vendor's own entry plan divided by the credits the plan includes, from the Cleanlist AI B2B data pricing index at /data/b2b-data-pricing-index-2026-09.csv, each row read from the vendor's own pricing page on September 1, 2026. Alphabetical, no ranking, and every row is arithmetic you can redo. The full index covers 37 vendors and is published in full at that URL.

Bouncer. Pay as you go, 1,000 credits for $8, so $8.00 per 1,000. The minimum purchase is 1,000 credits and credits never expire.

Cleanlist AI. Starter is $49 per seat a month for 750 credits and validating an address you already hold is metered at 0.5 credits, so $32.67 per 1,000 monthly and $24.67 per 1,000 billed annually.

Clearout. Starter is $19.50 a month for 3,000 credits, so $6.50 per 1,000 monthly and $5.33 per 1,000 annually.

NeverBounce. No purchasable dollar price is published. The pricing page returned HTTP 403 to an ordinary desktop browser user agent on September 1 and again on September 7, 2026, and a headless browser was served a bot challenge rather than a price.

Snov.io. Starter is $39 a month for 1,000 credits, so $39.00 per 1,000 monthly and $29.25 per 1,000 annually, with prospect search drawing on the same pool.

Two readings of that census matter more than the ordering. Cleanlist AI is the more expensive instrument for scoring a list you already hold, because a Cleanlist AI credit is priced for a waterfall lookup across 25+ providers rather than for one SMTP check, which is the same conclusion this page reaches above from the product side. And a vendor that publishes no purchasable price at all makes the choice a procurement question before it is a technical one.

Our own row in that census, in the same compact form: Cleanlist AI is best for teams that need to find and verify a contact in one call rather than score a list they already hold. It runs waterfall enrichment across 25+ providers and charges 1 credit for a verified work email and 10 for a phone number, with search free and unlimited and a miss costing nothing, starting at $49 per seat a month, and every new workspace starts with 14 days of Pro: 3 seats, 250 credits, every Pro feature.

There is no single answer for every list, and the differences that actually separate two vendors are all checkable before you pay. Six of them, in the order they change the bill.

Verdict granularity. Four states or two. A binary valid or invalid flag has to file catch-all, role and disposable addresses somewhere, and both choices are wrong for a reason described earlier on this page. Ask which reason codes are returned, not how many verdicts.

Whether catch-all probing is included at the price you were quoted. The second round trip per domain is the check a cheap tier skips quietly, and a syntax-and-MX-only product is a different product with a materially lower catch rate.

Unknown rate, and whether unknowns are billed. Bouncer advertises under 2% unknown results on its homepage (usebouncer.com, read September 7, 2026) and publishes that it will never charge for duplicated addresses within a list, nor for unknown results. Emailable publishes that unknown results are free (emailable.com/pricing, read September 1, 2026). Ask for the rate and the billing rule in the same sentence, because a vendor can improve a published accuracy figure by growing the unknown bucket.

Credit expiry. Bouncer, Clearout and ZeroBounce all publish credits that never expire. Hunter's refill monthly. Verifalia's 25 daily free credits reset at midnight GMT and do not bank. An annual pack that lapses is a higher effective price than a smaller monthly one you consume.

A published accuracy floor, and whether being wrong costs the vendor anything. Advertised figures in this category run from 95% to 99.9% and are not measured the same way. The buying guide at emailvendorselection.com, read September 7, 2026, tells readers to expect at least 95%, and reports that NeverBounce refunds the difference when more than 3% of verified addresses bounce, which is the only form of accuracy claim here that has a price attached to being wrong.

Data retention. The same guide reports that Bouncer deletes submitted data automatically after 60 days. Get the retention period, the sub-processor list and the processing location in writing, since you remain the controller.

Then settle it with the seed-list test described earlier rather than with the marketing figures. A few hundred addresses of known truth, run against every candidate on the same day, answers all six questions at once.

Yes, and the reason to think carefully about it is operational rather than technical. This is a live question in the category: on September 7, 2026 the Google AI Overview for this term closed by pointing readers at a Reddit r/selfhosted thread about an open-source verification API built with Go and Docker, and a Reddit thread was the number one organic result for the same query on the same day.

The first two layers are ordinary code. RFC 5322 syntax parsing and a DNS lookup for MX records are a weekend. The third layer is where a build turns into an operations commitment.

Outbound port 25 is the first wall. Most large cloud providers block outbound port 25 by default and lift it only on request, which is why the naive implementation passes on a laptop and fails the first time it runs inside a VPC.

IP reputation is the second. A pattern of connections that sends EHLO, MAIL FROM and RCPT TO and never sends DATA is indistinguishable from address harvesting to a receiving server, so an unmanaged source IP stops getting useful answers within weeks. The failure is quiet: your unknown rate climbs and it looks like a data problem rather than a reputation problem.

Then the maintenance nobody scopes. Disposable-domain lists age, burner services rotate vanity domains behind the same MX fingerprints, catch-all probing needs a second round trip per domain, and greylisting retry logic is a scheduler with persistent state rather than a function.

Self-hosting is the right call in one shape: low volume, corporate recipient domains, no deliverability stake in the result, and a team that already runs mail infrastructure on warmed IP addresses. Outside that shape, the API costs less than the reputation work behind it.

Three ways, and none of them proves the address belongs to the person you have in mind.

A free single-address checker is the fastest. The Cleanlist AI one at /tools/email-verifier runs 25 checks per IP per day with no account, covering syntax, MX, disposable and role detection, and it stops deliberately before the SMTP handshake, so it tells you an address is impossible rather than confirming it is live.

The free tiers of the dedicated verifiers do run the handshake, at capped volumes. Read from the vendors' own pricing pages on September 1, 2026 for the Cleanlist AI B2B data free-tier census: Verifalia publishes 25 free credits a day that reset at midnight GMT and do not bank, ZeroBounce publishes 100 validation credits refilling monthly on a plan requiring a business or premium domain, Emailable includes 250 free credits at signup, Bouncer and Clearout each give 100 free credits with no card, and the Kickbox price table starts at 100 free verifications.

The manual route is a DNS lookup. Query the domain's MX records with any DNS tool, and if the domain publishes none and has no fallback A record, nothing at that domain receives mail at all, whatever the local part says.

The caveat is the part worth keeping. A deliverable verdict says a mailbox accepts mail. It does not say who owns that mailbox, whether the person you have in mind still works there, or whether the name attached to it in your CRM is current. Closing that gap is enrichment, and no verification verdict from any vendor speaks to it.

Measured by Cleanlist AI on September 7, 2026, across the eight keywords in this cluster (Google US desktop, organic depth 50, AI Overviews loaded): all eight fire an AI Overview and all eight return a readable answer.

On the term itself, Google's definition sentence is that an email verification API is a programming tool that checks if an email address is real, active and safe to send to before you accept it into your system, cited to emailverify.io. It then lists four checks in the same order this page lists them: a syntax check illustrated with the typo @gmzail.com, a domain check for active MX records, a mailbox ping that tests whether the inbox exists without sending a message, and risk filters for disposable addresses, spam traps and role accounts such as support@ and admin@. Those bullets are cited to clearout.io, mailgun.com and emailverify.io. The Overview then names ZeroBounce, Emailable and Mailgun as popular providers and closes on the Reddit r/selfhosted thread about open-source alternatives.

The commercial queries quote numbers rather than definitions. On email verification service, Google repeats a 99.6% accuracy figure attributed to ZeroBounce, MillionVerifier at around $449 for 1 million verifications, and a Reddit estimate of roughly $77 to $350 or more for 50,000 verifications. On best email verification tools it opens with a flat ranking sentence and cites LeadMagic's 10,000-email test.

Cleanlist is named in none of the eight answers and cited as a source in none of them, which is the honest state of this page on the day it was written. Two patterns are visible in what does get lifted. The sentences are definitions with the entity as the grammatical subject and a literal example token inside them. The figures are prices and percentages carrying a unit. Vendor marketing prose is not quoted at all.