How Email Verification Works

What is email verification?

Email verification confirms that an address can receive mail, without sending anything to it. It parses the address, resolves the domain's mail exchange records, opens an SMTP handshake with the mail server to ask whether the mailbox exists, and then classifies the risk of what came back.

The handshake is the part people are surprised by. A mail server can be asked whether it would accept mail for an address and answer without a message ever being composed or delivered, which is why verifying a list of fifty thousand addresses puts nothing in anybody's inbox and costs your sending domain nothing.

Verification answers one question well and refuses to answer several others. It tells you whether a mailbox exists today. It does not tell you whether the person still works there, whether they will read anything, or whether they want to hear from you.

What is the difference between email verification and email validation?

Validation checks the address as a string. Verification checks it against the live mail server. Validation can tell you that name@compnay.com is well formed and cannot tell you that nobody is behind it.

In practice most tools use the two words interchangeably and most free tools only do the first half, which is why a free syntax and MX checker will pass an address that bounces on the first send. Full verification catches 95% to 99% of bad addresses. A syntax and MX check on its own catches 70% to 90%.

Cleanlist charges 0.5 credits for the full check, not for the string check, and returns the reason code alongside the verdict so you can tell which layer the address failed at.

What does each verification check actually do?

Three network checks answer whether an address can receive mail, and a fourth classification pass answers whether you should send to it. They run in order, and an address that fails an early one does not reach the later ones.

1. Syntax. The address is parsed against RFC 5322 and normalised. This catches the typo family that makes up most of a bad list: a missing dot, a doubled domain, gmial.com.

2. DNS and MX. The domain is resolved and its mail exchange records are read. A domain with no MX record cannot receive mail at all, whatever else is true about it.

3. SMTP handshake. The mail server is asked whether the mailbox exists. Nothing is sent. A server that answers yes to every address is recorded as accept_all rather than passed through as clean.

4. Risk classification. What the first three could not settle: catch-all behaviour, role addresses, disposable domains. This is the pass that produces a risky verdict instead of a binary one.

The ordering is a cost decision as much as a logical one. Syntax is free and rejects a meaningful share of a raw list, DNS is cheap, and the handshake is the expensive step, so running them in that order means the expensive check is only spent on addresses that could plausibly pass it.

The handshake and the catch-all detection run through the verification providers in the Cleanlist pool, ZeroBounce and Emailable among them. The free browser checker at /tools/email-verifier deliberately stops after the first two layers, which is why it is free and why it cannot prove a specific mailbox exists.

What do the verdicts deliverable, risky, undeliverable and unknown mean?

Deliverable means the mail server confirmed the mailbox. Undeliverable means it refused. Risky means the checks ran and the answer is genuinely ambiguous. Unknown means the server would not answer, so nothing is claimed either way.

Four verdicts rather than two is the whole design. A binary clean or dirty flag has to put catch-all domains, role addresses and disposable domains somewhere, and wherever it puts them it is lying: called clean they bounce, called dirty they throw away real prospects at companies whose mail servers happen to be configured permissively.

Every verdict carries its reason code, so a risky row is not a shrug. accept_all, role_address and disposable_domain each imply a different decision, and a team that routes them differently gets more out of the same list than a team that deletes all three.

mx_ok, smtp_ok. The domain takes mail and the server confirmed this mailbox. Send.

accept_all. The domain says yes to every address, so a yes here proves nothing. Your call.

role_address. info@, sales@, support@. It lands in a shared inbox and rarely gets a personal reply.

disposable_domain. A burner. The mailbox will be gone before a reply is.

no_mx. The domain cannot receive mail at all. Usually a typo in the domain half.

What is a catch-all domain, and why is it not a pass?

A catch-all domain is one configured to accept mail addressed to anything at that domain, whether or not the mailbox exists. Its mail server answers yes to every handshake, so a yes carries no information about the address you asked about.

Catch-alls are common at small companies and at organisations that would rather receive a misaddressed message than bounce it. That makes them a real chunk of most B2B lists and a real decision rather than an edge case.

The useful posture is to keep them, label them, and send to them separately from your confirmed addresses, so a bounce rate from the catch-all segment does not contaminate the measurement on the rest. Deleting them throws away accounts you may care about, and merging them into your clean segment is how a healthy-looking list produces a bounce rate that gets a domain throttled.

How do you verify an email list in bulk?

Upload the addresses as a list and run the same three checks across the batch. A list holds 2,500 leads on any paid plan and 100 on Free, verification costs 0.5 credits an address, and the run is asynchronous rather than a request held open.

CSV upload is a paid-plan feature, so bulk cleaning starts at Starter. On Starter's 1,500 credits, 0.5 a row is 3,000 addresses verified for $79, and credits sit in one shared team wallet rather than being allocated per seat.

The order that saves the most money is verify first, enrich second. Verification is a twentieth of the price of finding a direct dial, so spending 0.5 credits to learn that an address is dead before spending 11 to build a full contact around it is the whole argument for doing them in that sequence. The live run at the top of /product/email-verification is that sequence: seven addresses in, four fail, and only the three survivors are enriched.

Is there an email verification API?

Yes. The Cleanlist API v2 exposes verification and waterfall enrichment endpoints, authenticates with clapi_ Bearer keys and OAuth scopes, and returns a signed cost quote before any credits are spent. It is included on the Pro and Scale plans.

Bulk jobs are asynchronous: a request returns a workflow_id that you poll until the results are ready. That is the right shape here because a handshake takes as long as the remote mail server takes, and a synchronous endpoint would spend a large run timing out on the slowest servers.

The signed quote is the part worth designing against. An integration can read the price of a job before running it and refuse, so a loop with a bug cannot quietly spend a month of credits overnight.

The MCP server is available from Starter upward and gives an assistant such as Claude the same verification and enrichment tools without an integration being written at all. Both the API and MCP are held back during the 14-day trial.

What does email verification cost?

0.5 credits an address, charged the same whether the verdict is good or bad, because the work is identical either way. Finding a new verified work email is 1 credit, a direct dial is 10, both together are 11, and a lookup that returns nothing is 0.

Plans are Free at $0 for 30 credits a month, Starter $79 for 1,500 credits and 2 seats, Pro $229 for 5,000 credits and 5 seats with the public REST API, and Scale $599 for 15,000 credits and 10 seats. Annual billing takes 25% off, and an extra seat is $20 a month.

There is also a free browser checker at 25 checks a day with no signup, which does the syntax, MX, role and disposable read and is the right tool for one address you are unsure about rather than for a list.

Every new workspace opens on Scale for 14 days with 250 credits, 3 seats and no card, which is 500 addresses verified, or fewer verified and some enriched, before anybody decides anything.

When should you run verification in your workflow?

At three moments, and a fourth that most teams skip. Verify at capture, so a mistyped address never enters the database in the first place. 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 a list arrives from an event, a partner or a scrape, before it is merged into anything you already trust.

The fourth is the one that gets skipped: verify before you enrich, not after. Verification is 0.5 credits and a direct dial is 10, so an address checked first costs a twentieth of the contact you would otherwise have built around a dead mailbox.

Re-verifying a whole database on a calendar is the expensive habit, and it is expensive in the wrong place. A quarterly sweep of 50,000 rows spends credits on the majority of records that nobody will email this quarter, while the segment that actually gets 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 one case for a scheduled sweep is a CRM that routes on data quality: lead scoring, territory assignment or a churn model that reads an email field. There the record is being acted on continuously rather than at send time, so the freshness has to be maintained rather than fetched.

Why do email lists go bad in the first place?

Because the people move. Cognism puts B2B data decay at about 2.1% a month and 22.5% a year, Cognism and SparkDBI put email addresses at 22.5% to 30% a year as the fastest-decaying field, and LinkedIn's Economic Graph puts annual job changes at 10.9% of professionals.

A mailbox does not usually announce that it has died. It is deprovisioned when somebody leaves, or it starts forwarding, or the company migrates its domain and the old one stops resolving. None of that produces an event in your CRM, which is why a list that was verified eighteen months ago and has not been touched since is not a verified list.

The practical consequence is that verification is a step in a sending workflow rather than a project. Verifying immediately before a campaign is worth more than verifying a whole database twice a year, and it costs less, because you only pay for the segment you are about to touch.

What bounce rate should you be aiming for?

Under 2%. That is the point at which Gmail and Microsoft begin throttling a sending domain, against an 8% to 12% industry average for unverified B2B lists.

The asymmetry is what makes this worth doing. Getting under the threshold is a few cents a row. Getting back over it after a domain has been throttled takes weeks of reduced volume, and every campaign in that window underperforms for reasons that have nothing to do with the campaign.

Measure bounce rate per segment rather than per send. A single blended number hides the case that matters, which is one bad segment inside an otherwise healthy list dragging the domain down while every other segment looks fine.

Does verification protect sender reputation on its own?

No, and any tool that implies otherwise is overselling. Verification removes one cause of reputation damage, hard bounces. Authentication, sending volume ramp, list provenance, content and complaint rate are the rest, and Cleanlist does not send email, so it cannot touch them.

The other levers are worth naming so nobody buys the wrong thing. SPF, DKIM and DMARC have to be configured on the sending domain. A new domain has to be warmed rather than switched on at full volume. Recipients who never asked to hear from you will complain at a rate that no amount of verification changes, and complaint rate is weighted more heavily than bounces by most receivers.

What verification removes is the one failure mode that is entirely mechanical: mail sent to a mailbox that does not exist. That is the claim this page makes, and it stops there.

What is reverse email lookup, and how does it relate to verification?

Reverse email lookup takes an address and finds the person behind it: name, job title, company, LinkedIn URL and, where a provider in the pool holds it, a direct dial. It is the natural second step after verification, because it is worth doing only on addresses that survived the first one.

That ordering is the causal chain the live run on /product/email-verification shows. Seven addresses go in, four fail on syntax, MX, role or disposable grounds, and the three deliverable ones are looked up into full contacts. Running the lookup first would have spent enrichment credits on four addresses that cannot receive mail.

The lookup runs the same 25+ provider waterfall as the rest of Cleanlist, stopping at the first provider that returns a verified value. Resolving an address into a contact costs 1 credit, adding a direct dial costs 10, and a lookup that finds nothing costs nothing.

What can email verification not tell you?

Four things, and they are the four people most often assume it covers. It cannot tell you that the person still works there, that they will read the message, that the address is not a monitored spam trap, or that sending is lawful in their jurisdiction.

A mailbox that is still provisioned after somebody leaves verifies exactly like an active one, which is why verification and enrichment answer different questions and both matter. Verification says the mailbox is alive. Enrichment says whose it is and what they do now.

Spam traps are the one worth naming explicitly. A recycled trap is an abandoned mailbox a receiver has reactivated to catch senders using old lists, and it accepts mail by design, so it passes every check on this page. The defence is list hygiene and provenance rather than a verifier: do not send to addresses you have not touched in a year, and do not buy lists.

Legality is jurisdictional and is not a data question. GDPR, CASL and their equivalents govern whether you may contact somebody, and no verdict from any verifier speaks to it.