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 runs the syntax, MX, role and disposable checks and deliberately stops before the SMTP handshake and the catch-all detection, 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, three come back deliverable, and only those three 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 and 3 seats, 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, three come back deliverable, two come back risky on role and catch-all grounds and two undeliverable on no-MX and disposable grounds, and only the three deliverable ones are looked up into full contacts. Running the lookup first would have spent enrichment credits on the four addresses that did not clear the check.

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.

How do you verify an email address?

Three routes, and which one you want depends on how many addresses you are holding. All three run the checks described above, and none of them sends a message to the address.

One address: the free checker. Paste it into /tools/email-verifier. It is 25 checks a day per IP with no account, and it returns a verdict in about two seconds. It runs the syntax, MX, role and disposable layers and stops before the SMTP handshake, so it can prove that an address is malformed or that its domain takes no mail at all, and it cannot prove that a specific mailbox exists.

A list: CSV upload. Upload the addresses and run the batch. CSV upload starts on the Starter plan at $79 a month, a list holds 2,500 leads on any paid plan and 100 on Free, verification is 0.5 credits an address, and the run is asynchronous rather than a request held open. Every row comes back with a verdict and the reason code behind it, which is what lets you route accept_all separately from role_address instead of deleting both.

In code, or from an assistant. The Cleanlist API v2 exposes the verification endpoint on Pro at $229 a month, and the MCP server gives an assistant such as Claude the same verification tools from Starter upward. Both are held back during the 14-day trial. The request shape, the signed cost quote and the polling loop are covered on /learn/email-verification-api.

Whichever route you take, the ordering rule is the same: verify first, enrich second. A verification is 0.5 credits and a direct dial is 10, so checking an address before building a contact around it costs a twentieth of the contact. Every new workspace opens on Scale for 14 days with 250 credits and 3 seats, which verifies 500 addresses before anybody decides anything.

What is the difference between valid, deliverable and accept-all?

They are the same states under different names. The mapping matters because two tools answering the same question in different vocabularies look like they disagree when they agree exactly.

Valid is deliverable. The mail server confirmed the mailbox. Cleanlist returns deliverable with the reason codes mx_ok and smtp_ok, and the run at the top of /product/email-verification labels the same rows valid.

Invalid is undeliverable. The domain or the mailbox was refused. The reason code says which one: no_mx means the domain cannot receive mail at all, and a rejected mailbox means the domain takes mail and this address is not one of its mailboxes.

Catch-all and accept-all are one thing under two names. In the Cleanlist verdict set it is the accept_all reason code, and it sits inside risky rather than standing as a top-level state, because a yes from a server that says yes to everything is not evidence.

Disposable and role are reason codes, not states. disposable_domain and role_address both sit inside risky, and they imply different decisions: a burner will be gone before a reply is, and a shared inbox is a real destination that rarely produces a personal reply.

Unknown means unknown everywhere. No vendor can turn a server that declined to answer into an answer.

Below the top-level state, published taxonomies in this category run from four labels to eighteen or more. Emailable, a verification provider in the Cleanlist pool, uses the same four states Cleanlist uses, deliverable, undeliverable, risky and unknown, and breaks them into eleven reasons and seven attributes, with mailbox full, no reply, timeout, no connect, invalid SMTP and rejected email among them (read on emailable.com, September 7, 2026). Cleanlist folds those into undeliverable and unknown and returns the reason code that drives the decision.

More labels buys routing granularity rather than accuracy. The question worth asking a vendor is whether the status it hands back tells you what to do with the row, rather than how many statuses it is able to print.

How much does it cost to verify 1,000 email addresses?

Between $14.97 and $26.33 on Cleanlist, depending on the plan and the billing term. The arithmetic is public and you can check it: a verification is 0.5 credits, so the price per thousand is the plan price divided by its credit allowance, halved, times a thousand.

Starter, $79 a month for 1,500 credits. $0.0527 a credit, so $26.33 per 1,000 verifications. On annual billing at $59 a month, $19.67 per 1,000.

Pro, $229 a month for 5,000 credits. $22.90 per 1,000. On annual billing at $172 a month, $17.20.

Scale, $599 a month for 15,000 credits. $19.97 per 1,000. On annual billing at $449 a month, $14.97.

The trial, $0. The 14-day Scale trial carries 250 credits and 3 seats, which is 500 addresses verified before you have paid anything.

A dedicated verifier is usually cheaper per address than a platform that also finds addresses, and the reason is structural: a verifier does one job and never has to pay a second provider when the first one misses. If verification is the whole task, price it against verifiers. These rates were read on each vendor's own pricing page on September 1, 2026. Clearout's Starter plan is $19.50 a month for 3,000 credits at 1 credit a verification, which is $6.50 per 1,000 (clearout.io/pricing/). Skrapp's Professional plan is $39 a month for 2,000 credits, $19.50 per 1,000 (skrapp.io/pricing). Snov.io's Starter plan is $39 a month for 1,000 credits, $39.00 per 1,000, and prospect search draws on the same pool (snov.io/pricing). UpLead's Essentials plan is $99 a month for 170 credits that bundle an email with a mobile number, which works out at $582.35 per 1,000 and is a different product being priced (uplead.com/pricing/).

That comparison only exists when a vendor publishes a rate, and many do not. Of the 37 vendors in the Cleanlist B2B data pricing index, 30 publish a purchasable price and 7 do not. Among the seven, NeverBounce and ZoomInfo served a press-and-hold bot challenge instead of a readable pricing page when the index was collected on September 1, 2026, and Seamless.AI shows Contact sales on every tier above its free one.

How long does a verification result stay good?

About 90 days as a working shelf life, and closer to a single campaign for any segment you are about to email at volume. The decay rates behind that are published: Cognism puts B2B contact data at 2.1% a month and 22.5% a year, Cognism and SparkDBI put email addresses specifically at 22.5% to 30% a year as the fastest-decaying field of all, and LinkedIn's Economic Graph puts annual job changes at 10.9% of professionals.

Run the arithmetic on your own list rather than taking the interval on trust. At 2.1% a month, a segment verified 90 days ago carries roughly 6% addresses that have gone bad since the verdict was written, which is on its own enough to cross the under-2% bounce threshold that Gmail and Microsoft throttle against. At six months it is roughly 12%, which is the bottom of the 8% to 12% band that unverified B2B lists average, so half a year of shelf life is worth about the same as never having verified at all.

The useful way to hold this is that a verdict is a fact with a timestamp on it rather than a permanent attribute of the record. Cleanlist charges 0.5 credits to write a fresh one, so re-checking the few thousand addresses you are about to send to costs less than trusting a stored verdict on all of them.

There is one exception. A CRM that routes on the email field, for lead scoring, territory assignment or a churn model, is acting on that record continuously rather than at send time, so its freshness has to be maintained rather than fetched. /learn/bulk-email-verification covers what a maintenance cadence looks like across a whole database.

Why do some mail servers refuse to answer, and what is greylisting?

Greylisting is a spam defence: the receiving server temporarily defers a connection it does not recognise and expects a legitimate sender to come back and retry a few minutes later. Emailable, a verification provider in the Cleanlist pool, puts its reach at around 3% of all emails (read on emailable.com, September 7, 2026). A verifier that reads a deferral as a refusal turns those addresses into false negatives, which is the expensive kind of error because it deletes people who exist.

Greylisting is one of five reasons a handshake comes back without an answer.

Rate limiting. The server answers a few connections and then stops answering, which is why a large run against one domain can produce a block of ambiguous results that have nothing to do with the addresses.

Anti-harvesting policy. Some servers refuse verification-style handshakes outright, on purpose, because a server that answers every mailbox question honestly is a directory of everyone who works at the company.

Timeouts. The connection opens and nothing comes back inside the window.

The server is down. Temporary and indistinguishable, from the outside, from a server that is refusing you.

A greylist deferral. The 3% case above, and the only one of the five that is designed to be resolved by trying again.

All five produce the same honest output, which is why unknown exists as a verdict and why it is worth keeping unknowns in their own segment rather than merging them into either pile. The question below on why addresses come back unknown covers what to do with that segment.

How do you verify an email address at the point of signup?

Check the address inside your form handler, before the record is written, because the alternative is finding out at send time when the bounce has already been counted against your sending domain. A form that accepts anything is a machine for manufacturing bounces, and it runs at whatever rate your traffic runs at.

Two costs make this worth wiring up. Fake and automated signups inflate the subscriber count your email platform bills you for, and they arrive faster than anyone reviews them. Then the addresses that were never real bounce on the first send, and a run of hard bounces from a single source is one of the cleanest signals a receiver has that a sender is not maintaining its list.

What to do with each verdict at the form is a design decision worth making deliberately. Block on undeliverable, since the address cannot receive the confirmation email anyway. Accept risky and flag the record, because catch-all domains are ordinary at small companies and blocking them turns away real customers. Never block on unknown, because a greylisting server would lock out a legitimate signup for a reason that has nothing to do with the person filling in the form.

The honest boundary: Cleanlist does not ship a form widget or a drop-in JavaScript component for this. Vendors in this category do, and Verifalia for one publishes a free embeddable widget that checks addresses as the user types (read on verifalia.com, September 7, 2026). With Cleanlist the route is the API v2 verification endpoint on the Pro plan, or the MCP server from Starter upward, called from the server side of your form. That is a few lines in a handler rather than a script tag, and it is worth knowing before you choose.

What is the best email verification tool for your case?

The one whose verdict you will actually act on, at the volume you actually run, at a price it publishes. There is no single best tool in this category, and a vendor that ranks first for the search term has not been ranked against your list.

Cleanlist: best for teams that are finding addresses as well as checking them. It runs waterfall enrichment across 25+ providers and charges 1 credit for a verified work email and 10 for a direct dial, with search free and unlimited and nothing charged on a miss, starting at $79 a month, and verification at 0.5 credits an address inside the same wallet.

Five axes separate the options, and only the first two get asked about often.

Volume. A hundred addresses a month and a hundred thousand are different products with different failure modes. At the low end a free single-address checker is the whole answer. At the high end the questions are concurrency, asynchronous jobs and what happens when one domain rate-limits you.

Whether verification is the whole job. If you already hold the addresses, a dedicated verifier is cheaper per address. If you are finding them too, verification inside the enrichment platform saves a hop, a second bill and a reconciliation step between two sets of ids.

Whether a miss costs you. Some vendors charge for a lookup that returns nothing, which quietly changes the real price per usable record. On Cleanlist search costs 0 credits and a lookup that finds nothing costs 0 credits.

Whether the vendor publishes a price at all. 30 of the 37 vendors in the Cleanlist B2B data pricing index do, and 7 do not. A vendor that will not print a rate is asking you to run a sales cycle to get a number that the rest of the category puts on a page.

What happens to catch-alls. This is the axis almost nobody asks about and the one that moves the usable size of a B2B list the most. A tool that calls them clean will hand you bounces. A tool that calls them invalid will delete real accounts. A tool that labels them and hands the decision back leaves you the option of sending to them as their own segment.

What does Google's AI Overview say about email verification today?

We measured it. On September 7, 2026, a Google US desktop search for email verification (6,600 US searches a month, $4.12 average cost per click, measured with the Google Ads keyword planner and the DataForSEO SERP API) returned an AI Overview above the results. This is what that answer contained, and every part of it is checkable by running the same search.

The definition it opens with. Email verification confirms that an email address is real, active, and able to receive messages without sending an actual test email. That sentence is cited to verifalia.com and experian.com.

The four checks it enumerates. Syntax check, domain check, MX record check and SMTP ping, one line each, cited to clearout.io, snov.io and verifalia.com.

The four results it enumerates. Valid, Invalid, Catch-All and Disposable, one line each, cited to hunter.io, skrapp.io, verifalia.com and zerobounce.net.

The tools it names. Three, in a block headed Popular Tools: Hunter, ZeroBounce and Verifalia. Two of those three, Hunter and ZeroBounce, are verification providers in the Cleanlist pool, so Google's shortlist for this query is partly built from companies whose answers Cleanlist already buys and passes through.

The sources it cites. Seven in total: verifalia.com, experian.com, clearout.io, snov.io, hunter.io, skrapp.io and zerobounce.net. Cleanlist is not among them.

Two things are worth taking from that measurement, and neither is about ranking. Every source cited on the two enumerations is cited on a labelled list with a single line per label, which is the shape this page uses throughout. And Google's answer speaks in valid, invalid, catch-all and disposable while this page speaks in deliverable, risky, undeliverable and unknown, which is precisely why the mapping between the two vocabularies is written out above.

What does a verification confidence score mean?

It is the strength of the evidence behind a verdict rather than the probability that a human being reads the mail. The run at the top of /product/email-verification returns a score out of 100 beside the verdict, 98 on a confirmed row, and the smtp_provider behind the address, Google Workspace on that row.

Read the verdict first, the reason code second, the score third. The verdict says what happened, the reason code says why, and the score says how much the layers agreed. Routing on the score alone throws away the reason code, which is the field that tells you what to do.

A deliverable verdict with a low score usually means one layer answered weakly. A slow or partial SMTP response, or a domain whose records are unusual, will pull a score down without changing the verdict. It is a reason to put the row later in a send order, not a reason to move it to another bucket.

Use the score to sort within a bucket. If you are sending to 4,000 deliverable rows and want to warm up on the safest 1,000, the score is the right sort key. If you are deciding whether catch-alls get sent to at all, the score has nothing to say and the accept_all reason code has everything to say.

smtp_provider explains inconsistency. Knowing that an address sits behind Google Workspace or Microsoft 365 explains why a mailbox question came back ambiguous, since the large mail platforms answer that question inconsistently by design. The question below on consumer mailboxes is the same effect seen from the other side.

Scores are not comparable between vendors. Each one computes its own from its own layers, so a 92 from one tool and a 92 from another are two different measurements wearing the same number.

Does verification keep you off a blocklist?

No. It removes one input to that decision and leaves every other input untouched. Three things get conflated in this conversation, and they behave differently enough that treating them as one is how a team ends up surprised.

A bounce. Mail sent to a mailbox that does not exist, refused by the receiving server. This is the one verification is designed to prevent, and it prevents it well.

A spam trap. An address a receiver or a list operator monitors specifically to catch senders with bad list hygiene. A recycled trap is an abandoned mailbox that was reactivated for the purpose, and it accepts mail by design, so it passes every check on this page. A pristine trap was never a valid address held by a person, and it reaches your list only through scraping, purchase or a broken import.

A blocklist entry. A receiver or a third-party operator deciding that your domain or your sending IP is a source of unwanted mail. Bounces feed that decision. So do complaint rate, sending volume, authentication and the traps you hit, and complaint rate is weighted more heavily than bounces by most receivers.

There is a failure mode almost nobody plans for: you do not always receive the bounce message. A receiver can accept a message and then discard it, or refuse it without telling you, so a send that failed can look identical to a send that was read and ignored. Reply rate and open rate both go quiet in the same way.

The defences against traps and blocklists are provenance and hygiene rather than a verifier. Do not send to addresses you have not touched in a year, do not buy lists, keep a suppression list rather than deleting dead records, warm a new sending domain rather than switching it on at full volume, and configure SPF, DKIM and DMARC before any of the rest of it. Cleanlist does not send email, so none of those five levers is one it can pull for you.

What happens to your list when you upload it for verification?

The addresses are processed to produce a verdict, and the verdict is what comes back. Nothing is sent to any address on the list, which is the property that makes verification safe to run on a list you have not touched in a year. Four questions are worth asking any vendor before the first upload, including this one.

Is the result cached, and for how long? A cache is the difference between a verdict written for your run and a verdict written for somebody else's run weeks ago. Emailable publishes a maximum cache of five minutes as an accuracy claim (read on emailable.com, September 7, 2026), which tells you the length of a cache is a live axis in this category rather than an implementation detail.

What is the retention basis? Cleanlist publishes its own in the data processing addendum at /dpa: on termination of the service you can export customer data for 30 days, and after that window Cleanlist deletes or deidentifies it, except where it must be kept to comply with law or to handle security, billing, dispute resolution or suppression. Ask any vendor for the same statement in writing rather than for a reassurance in a sales call.

Is the upload a processing operation or a contact? Under GDPR and CASL, verifying an address is processing, and it is a different act from sending a message to it. That distinction is why verifying a list you may not lawfully email is possible, and why doing so does not make the list lawful to email.

What does the verdict not carry? No verdict from any vendor speaks to lawful basis, consent or jurisdiction, which the closing section of this page states in full. A clean list and a lawful list are two separate pieces of work.

How accurate is email verification, and how would you check?

Full verification catches 95% to 99% of bad addresses, and a syntax and MX check on its own catches 70% to 90%. That gap is the whole argument for the SMTP layer, and it is also the gap between most free tools and most paid ones.

Vendor accuracy claims in this category are real numbers measured on samples the vendor chose. Emailable publishes a 99% deliverability guarantee, and Verifalia describes over 30 verification steps and more than 40 classifications and statuses (both read on their own pages, September 7, 2026). Neither figure is wrong and neither is comparable to the other, because a guarantee computed on one vendor's sample of one kind of list is not a measurement of your list.

So measure it on your list, which takes an afternoon. Pull two slices you already know the answer for: addresses that replied to something in the last 30 days, and addresses that hard bounced on your last send. Run both through the tool without telling it which is which. Count how many of the known-good come back deliverable and how many of the known-dead come back undeliverable. A tool that fails the first slice is deleting your pipeline, and a tool that fails the second is the reason you are still bouncing.

The honest ceiling on any accuracy claim is the share of receiving servers that answer at all. No verifier can beat a mail server that declines to respond, which is why the unknown bucket exists and why a vendor that reports no unknowns at all is rounding somewhere. /learn/email-verification-api covers what the protocol-level limits look like from inside an integration.

What is an email verification code, and is that the same thing?

No. Two different things share the name, and most searches for this phrase want the other one.

An email verification code is a one-time passcode that a service emails or texts you to confirm you control an account: six digits, a short expiry, sent to you, arriving in your inbox. If that is what brought you here, the code comes from the service you are signing in to, so that service is who to ask. Check the spam folder, wait a minute for the queue, request a new code rather than reusing an expired one, and contact that company's support if none of it arrives. Cleanlist does not send email and cannot issue, retrieve or resend anyone's login code.

Email verification in the sense this page is about is a list-hygiene check. It asks a mail server whether an address can receive mail and it sends nothing at all, which is why it can be run across fifty thousand addresses without a single message being delivered.

One confirms that a person controls a mailbox. The other confirms that a mailbox exists. The wording overlap is why the searches around this term mix them, and the distinction is the one worth keeping.