Bulk Email Verification: How to Clean a List Before You Send

Bulk email verification is the same deliverability check run across an entire list in one job instead of one address at a time. Each row is parsed for syntax, its domain is resolved for mail exchange records, an SMTP handshake asks the receiving mail server whether that mailbox exists, and a final pass classifies what the first three could not settle.

The word bulk changes the economics rather than the mechanics. A single address takes one to three seconds and nobody notices. Fifty thousand addresses spread across ten thousand different mail servers, some of which greylist, some of which rate-limit and some of which will not answer a verification-style handshake at all, is a queueing problem, which is why every serious bulk verifier runs the job asynchronously and hands you a result file rather than holding a request open.

Nothing in the process delivers mail. That is the point people most often get wrong before they run one. A mail server can be asked whether it would accept mail for an address and answer without a message ever being composed, so a bulk run costs your sending domain nothing and warns nobody on the list.

What it answers is narrow and worth stating up front: whether each mailbox exists today. It does not tell you whether the person still works there, whether the address is a spam trap, or whether anybody wants to hear from you.

Because mailbox providers read your bounce rate as the single clearest signal that you are sending to a list you did not earn, and the penalty lands on the domain rather than on the campaign. Every future send from that domain is affected, including one-to-one mail from a rep who had nothing to do with the bad list.

The thresholds escalate in steps rather than smoothly. Cross 2% and Google and Microsoft start throttling. Cross 5% and the domain may be blocked from Gmail and Outlook inboxes outright. Unverified B2B lists commonly average 8% to 12% hard bounces, which means an unverified list clears both thresholds before the first send has finished going out.

Bounce velocity is weighted too, not just the final percentage. A list that bounces 4% inside the first sixty seconds of a send does more damage than the same 4% spread across a day, because a dense burst of 550 responses is the signature of a purchased list. Throttling your own send rate does not fix bad data, but it does stop bad data from concentrating its damage into a single reputational spike.

The asymmetry is what makes verification obviously worth doing. Getting under the threshold costs fractions of a cent a row. Getting back over it after a domain has been throttled takes 30 to 60 days of reduced volume, and every campaign in that window underperforms for reasons that have nothing to do with the campaign.

Under 2% for opted-in marketing email, under 3% for cold B2B outbound, and under 1% is best in class. Hard bounces specifically should sit under 1%, because they are the permanent kind and they are the kind mailbox providers weight most heavily.

Measure per segment rather than per send. A single blended number hides the case that actually matters, which is one bad segment inside an otherwise healthy list dragging a domain down while every other segment looks fine. If you send to a catch-all segment and a confirmed segment in the same campaign and report one figure, you have thrown away the only measurement that would have told you which half to fix.

Watch for the sudden spike as a separate signal from the running average. A bounce rate that jumps overnight usually means one of four things: a list that was imported without verification, a large employer on your list deactivating accounts during a layoff, a recipient domain migrating its mail infrastructure, or your own sending domain landing on a blocklist. The bounce log tells you which. If most of the new bounces share one recipient domain, the cause is on their side and no amount of re-verification will change it.

Five steps, in an order chosen so the expensive checks only ever run on rows that could plausibly pass them.

1. Deduplicate and scrub locally first. Remove exact duplicates and alias duplicates, drop rows that fail syntax outright, and decide what to do with role addresses and free consumer domains before you pay for anything. The free browser cleaner at /tools/email-list-cleaner does all of this in your browser without uploading the file anywhere, and on a typical raw list it removes enough volume to pay for itself before the paid step starts.

2. Upload what survives as a list. Loading rows into Cleanlist AI costs 0 credits, in the portal or through the API.

3. Run verification across the batch. It costs 0.5 credits an address and runs asynchronously, so you are not sitting on a spinner while the slowest mail server on your list decides whether to answer.

4. Segment on the verdict, do not filter on it. Four buckets come back, and three of them deserve different treatment rather than deletion. This is the step teams skip, and it is the step that decides whether the run was worth doing.

5. Enrich only the survivors. Verification is 0.5 credits and a phone number is 10, so learning that an address is dead before building a full contact around it costs a fraction of learning it afterwards.

Because a catch-all domain answers yes to every handshake, so a yes proves nothing about the specific address you asked about. A verifier that reports a binary clean or dirty flag has to put those rows somewhere, and wherever it puts them it is lying to you.

The share is too large to wave away. Roughly 15% to 25% of B2B domains run catch-all, which is the figure this site publishes as a dataset property, so a bulk run on a corporate list returns a large ambiguous middle rather than a clean two-way split. Excluding every catch-all from outreach throws away live prospects in volume, and most of what you cut was real.

Called clean, they bounce and take your domain with them. Called dirty, they throw away live prospects at companies whose mail servers happen to be configured permissively. Neither is a defensible default, which is why the verdict has to be four-way rather than two-way and why the reason code matters as much as the verdict.

The workable posture is to keep them, label them, and send to them as their own segment with tight bounce monitoring, capping them as a share of any single campaign rather than mixing them into your best list. Then a bounce rate from the catch-all segment does not contaminate the measurement on the rest, and you learn what that segment is actually worth instead of guessing.

Cleanlist flags catch-all behaviour as its own reason code, accept_all, rather than folding it into a pass. The handshake and the catch-all detection run through the verification providers in the Cleanlist AI pool, ZeroBounce and Emailable among them.

Four verdicts come back and each one is an instruction, not a score.

Valid, or deliverable. The mail server confirmed the mailbox. Send.

Invalid, or undeliverable. The server refused, or the domain has no mail exchange records at all. Do not send, and do not delete the row either. Move it to a suppression list, because a deleted address gets reintroduced by the next import from the same source and you pay to verify it a second time before making the same mistake.

Risky. The checks ran and the answer is genuinely ambiguous. Read the reason code, because accept_all, role_address and disposable_domain imply three different decisions. A catch-all goes into its own send segment. A role address such as info@ or sales@ lands in a shared inbox and belongs somewhere other than a one-to-one sequence, and it distorts your reply-rate measurement if you leave it in. A disposable domain is a burner and can go.

Unknown. The server would not answer, usually because it greylisted the connection or rate-limited it. This is not the same as invalid and deleting it is a mistake. Re-run the unknown segment later, because the deferral was about timing rather than about the mailbox, and a meaningful share of unknowns resolve on a second pass.

The teams that get the most out of a bulk run are the ones that route these four differently. A team that deletes everything except deliverable throws away a large slice of a list it just paid to check.

Before, always, because cleaning is free and verification is metered. Every duplicate, malformed address, disposable domain and obvious typo you remove locally is a row you do not pay to check.

The two jobs are genuinely different. Cleaning reads the address as a string: it catches exact and alias duplicates, addresses that cannot be valid, role-based shared inboxes, free consumer domains, known burner domains, and near-misses of common providers like gmial.com. It needs no network call at all, which is why it can run instantly and privately. Verification asks the mail server, which is the only thing that can predict a bounce.

The free cleaner at /tools/email-list-cleaner runs entirely in your browser and hands back two files, the cleaned list and a second file of everything it removed with the reason, so the decision stays yours rather than disappearing into a black box. Nothing you paste or drop into it leaves your machine.

One caveat worth being blunt about. A perfectly formatted address on a real company domain with no hygiene flags at all can still bounce, because the person left, the mailbox was deprovisioned, or the domain migrated. Cleaning cuts volume and cost. It does not substitute for verification, and any tool that implies it does is selling a string check as a mailbox check.

0.5 credits an address in Cleanlist AI, charged the same whether the verdict is good or bad, because the work is identical either way.

The plans are Free at $0 for 50 credits a month with up to 3 seats, Starter at $49 per seat a month with 750 credits per seat, Pro at $89 per seat a month with 1,500 credits per seat, credit levels up to 100,000 a month and the public REST API, and Enterprise at a custom price. Annual billing takes 25% off. Every seat adds its credits to one shared team wallet, so a single large run does not need to be split across licences.

The arithmetic that matters: at 0.5 credits a row, one Starter seat's 750 credits verify 1,500 addresses for $49, a Pro seat's 1,500 verify 3,000 for $89, and Pro's 100,000-credit level verifies 200,000. Finding a new verified work email is 1 credit, a phone number is 10, both on one contact is 11, and a lookup that returns nothing is 0.

Every new workspace starts with 14 days of Pro (3 seats, 250 credits, every Pro feature), which is 500 addresses verified, or fewer verified and some enriched, before anybody has to decide anything. There is also a free browser checker at /tools/email-verifier, 25 checks a day with no signup, which is the right instrument for one address you are unsure about and the wrong one for a list.

Yes, on Pro and Enterprise. The Cleanlist AI API v2 authenticates with clapi_ Bearer keys against OAuth scopes, and the bulk path is POST /enrichment/bulk, which returns one workflow_id for the whole list that you poll with GET /enrichment/status/{workflow_id} until the results are ready.

Asynchronous is the right shape here rather than a convenience. A handshake takes exactly as long as the remote mail server takes, and a synchronous endpoint would spend most of a large run timing out on the slowest servers on the list. Loading rows is free: POST /lead-lists/{id}/csv-import costs 0 credits and honours an idempotency_key, so a retried upload does not duplicate the list, and every read, status poll and export is 0 as well.

The piece worth designing against is POST /credits/estimate, which returns a signed quote_id with a five-minute life. An integration can read the price of a job before running it and refuse, which means a loop with a bug cannot quietly spend a month of credits overnight. Build that check in before you build the retry logic.

The MCP server is available from Starter upward and gives an assistant such as Claude the same enrichment and list tools without an integration being written at all.

Before each send, not on a calendar. A bulk verification is a snapshot of the moment it ran, and the moment starts decaying immediately.

The decay rates are published and consistent. Cognism puts B2B data decay at about 2.1% a month and 22.5% a year, and Cognism and SparkDBI put email addresses at 22.5% to 30% a year as the fastest-decaying field of all. A list verified ninety days ago is already carrying enough new invalids to push a real-world bounce rate back over the 2% threshold, which is why cadence matters more than the accuracy of any single run.

A quarterly sweep of the whole database is the expensive habit, and it is expensive in the wrong place. It spends credits on the majority of rows nobody will email this quarter, while the segment that does get sent to has aged since the sweep anyway. Verifying the two thousand rows you are about to touch costs less than sweeping fifty thousand and answers a fresher question.

There is one real case for a scheduled sweep: a CRM that routes on data quality. If lead scoring, territory assignment or a churn model reads an email field, the record is being acted on continuously rather than at send time, so freshness has to be maintained rather than fetched.

The cheapest maintenance habit is verifying at the point of capture as well, so a mistyped address never enters the database in the first place and never appears in any of these runs.

No, and any tool that implies otherwise is overselling. Verification removes exactly one cause of reputation damage, hard bounces, and it is the one cause that is entirely mechanical and knowable in advance. The rest are not data problems.

Authentication has to be configured on the sending domain: SPF, DKIM and DMARC. A new sending domain has to be warmed rather than switched on at full volume, and no amount of list quality substitutes for that ramp. Complaint rate is weighted more heavily than bounces by most receivers, and recipients who never asked to hear from you will complain at a rate that verification does not touch. Content and sending patterns are read as well.

Verification cannot influence any of those levers, including when you send through Cleanlist AI's own Sequences, and it would be dishonest to imply otherwise on a page whose job is to be cited.

What a bulk run removes is mail sent to mailboxes that do not exist. On an unverified B2B list that is 8% to 12% of the send, which is enough on its own to put a domain past two of the three thresholds. That is the claim, and it stops there.

Four things, and they are the four teams most often assume it covers.

Whether the person still works there. A mailbox that is still provisioned after somebody leaves verifies exactly like an active one. Verification says the mailbox is alive. Enrichment says whose it is and what they do now, and those are different questions answered by different work.

Whether the address is a spam trap. A recycled trap is an abandoned mailbox that a receiver has reactivated to catch senders using old lists, and it accepts mail by design, so it passes every check on this page cleanly. The defence is provenance and hygiene rather than a verifier: do not send to addresses you have not touched in a year, and do not buy lists.

Whether the message reaches the inbox. Deliverable means the server will accept mail for the mailbox. Where it goes after acceptance, inbox or spam folder or a filtered tab, is decided by the receiver's filtering reading your authentication, your history, your complaint rate and your content.

Whether sending is lawful. GDPR, CASL and their equivalents govern whether you may contact somebody at all. That is jurisdictional and it is not a data question, and no verdict from any verifier speaks to it.

In three cases, and they are worth naming because the wrong fit here wastes real money.

When the list is genuinely enormous and verification is all you want. Think of a single file of hundreds of thousands of addresses. If nothing about that list needs a name, a title, a company or a phone number attached to it, a dedicated verification service priced purely per address is the more direct instrument and this page is not going to pretend otherwise.

When the addresses are consumer rather than business. The large consumer mailbox providers answer the mailbox question inconsistently, so a consumer list returns far more accept_all and unknown verdicts than a corporate one. Cleanlist AI is built around B2B work addresses and its coverage numbers, 98% verified work emails and 85% phone numbers on a stratified 500-lead benchmark, are B2B numbers.

When you only need to check one address. Use the free checker at /tools/email-verifier, 25 a day with no account. Opening a plan to check a handful of addresses is the wrong purchase.

Where Cleanlist AI does fit is the list that has to be both verified and completed: rows that need the dead addresses removed and the survivors resolved into contacts with a title, a company and a phone number, from one run across a 25+ provider waterfall, rather than from a verification job and a separate enrichment job that have to be reconciled afterwards.

A dedicated per-address verifier, and Cleanlist AI is not it. The comparable unit is dollars per 1,000 addresses, which is the only figure that survives the difference between a credit plan, a pay-as-you-go pack and an allowance bundled into a sending tool, and almost nobody on this search states it plainly.

Cleanlist AI, computed from the rate card at 0.5 credits a validation. Starter is $49 per seat for 750 credits, which verifies 1,500 addresses at $32.67 per 1,000. Pro is $89 per seat for 1,500 credits, 3,000 addresses, $29.67 per 1,000. Pro's top level is $3,899 a month for 100,000 credits, 200,000 addresses, $19.50 per 1,000. Annual billing takes 25% off, so Starter at $37 a month works out at $24.67 per 1,000.

The market, from the Cleanlist AI B2B Data Pricing Index, every figure fetched from the vendor's own pricing page on September 1, 2026. Clearout's Starter is $19.50 for 3,000 credits at 1 credit a verification, so $6.50 per 1,000. Bouncer sells 1,000 pay-as-you-go credits for $8, so $8.00 per 1,000, and publishes that it charges for neither duplicates inside a list nor unknown results. Kickbox's table lists 100 verifications free, then 500 for $5 and 1,000 for $10, so $10.00 per 1,000. Smartlead's Base plan at $39 bundles 2,000 verified emails with sending, which works out at $19.50 per 1,000. Snov.io's Starter is $39 for 1,000 credits at 1 credit a verification, so $39.00 per 1,000. Lemlist charges 5 credits a verification against a 1,000-credit pack at $10, so $50.00 per 1,000. NeverBounce, Cognism and ZoomInfo publish no purchasable price at all, which is its own kind of answer. Volume floors go lower still: OrbiSearch advertises pay-as-you-go from $0.0002 a validation, which is $0.20 per 1,000 at its cheapest tier (orbisearch.com, fetched September 7, 2026).

So the ladder is clear. An entry plan at a dedicated verifier runs $6.50 to $10 per 1,000 and Cleanlist AI runs $19.50 to $32.67 on monthly billing. If verification is the only job you have, buy the verifier.

What the higher number buys is the finding as well as the checking, from one run rather than two jobs that have to be reconciled afterwards. Cleanlist AI: Best for a list that has to be both verified and completed. It validates at 0.5 credits an address, about $32.67 per 1,000 on Starter, and resolves the survivors across a 25+ provider waterfall at 1 credit per verified work email and 10 per phone number, with a miss costing nothing, starting at $49 per seat a month.

As long as the slowest receiving mail server on your list takes to answer, which is why every serious bulk run in this category is asynchronous and why no vendor can honestly promise you a wall-clock number before it sees the file. Cleanlist AI publishes no rows-per-minute figure and this page is not going to invent one.

What is publishable is the shape of the wait. The Cleanlist AI API dispatches a whole list as a single call, POST /enrichment/bulk, which returns one workflow_id and a poll url for the entire job. Status polls cost 0 credits, so how often you poll is a latency choice with no cost attached to it, and the worked example on the API page settles a run in four polls at 2, 4, 8 and 16 seconds.

One detail decides whether a client hangs. Terminal means completed or completed_with_errors. A run with any failed row settles on the second of those, so a client waiting for completed alone waits forever. Branch on the status field rather than on the prose beside it. Enrichment takes no idempotency key either, so a blind retry starts a second billable run rather than resuming the first.

The published rate limits, 60 requests a minute per organisation and 30 per key, are not the per-address bound, because one dispatch covers a whole list. The real bound is the credit balance behind the run.

For a published sense of the spread, ZeroBounce, one of the verification providers in the Cleanlist AI pool, states 250,000 addresses in under 10 minutes on popular domains and 250,000 in 2.3 hours or less on complex ones (zerobounce.net, fetched September 7, 2026). Roughly 14x on identical volume, decided entirely by which mail servers are on the file.

Clean it on two axes, because a list has two independent failure modes and everything above this section addresses only one of them. The technical axis asks whether the mailbox exists: syntax, mail exchange records, the SMTP handshake, the catch-all question. The engagement axis asks whether the human on the other end reads anything, and no verifier can see that at all.

The engagement pass runs on your sending platform's own data, because that is where opens and clicks live. Identify contacts with no open and no click in the last three to six months. Run a sunset or re-engagement sequence that gives them one clear chance to stay. Suppress or delete whoever does not respond. A verified address that nobody has opened in six months passes every check on this page and still drags a domain down, through complaint rate and through the low-engagement signals receivers weigh alongside bounces.

There is a second argument for the engagement pass that has nothing to do with deliverability. Most email platforms bill on total subscriber count, so dead weight on a list is a line item every month whether or not it ever bounces.

Verification cannot run the engagement half. That work belongs to the platform that owns the record of who read what. The technical half is the part Cleanlist AI does: validation at 0.5 credits an address with a reason code beside every verdict, and the survivors resolved into contacts across a 25+ provider waterfall at 1 credit per verified work email and 10 per phone number. Running only one of the two axes leaves a list that is half clean.

Split it on a column you can reason about rather than on row number, and verify the segment you are about to send to rather than the database behind it.

Start with the file. A bulk uploader needs one clearly labelled email column, and mapping that column to the tool's email field is a step every platform makes you take, so name the header Email before you export rather than after an upload fails. Run the free local clean first, at /tools/email-list-cleaner, so the metered step sees a smaller file than the one you started with.

Then the upload. A large file goes into Cleanlist AI as a list in the portal or through the API, and ingest is free on both paths. POST /lead-lists/{id}/csv-import costs 0 credits and honours an idempotency_key, so a retried upload does not duplicate the list, and POST /lead-lists/{id}/leads skips duplicate rows at 0 credits as well. Only the verification and enrichment steps are metered, which means the staging work itself costs nothing to get wrong twice.

The rule that saves the most money is about scope rather than batch size. A quarterly sweep of fifty thousand rows spends credits on the majority nobody will email this quarter, and the segment that does get sent to has aged since the sweep anyway. Verifying the two thousand rows going out this week costs a fraction of that and answers a fresher question.

Good verifiers catch most bad addresses, and any accuracy percentage published without a denominator is unfalsifiable. That second half matters more than the first, because this category publishes a lot of bare percentages.

Start with what Cleanlist AI's own number is. On the Cleanlist AI 500-Lead Enrichment Benchmark, 2026, the waterfall returned a verified work email for 98% of 500 stratified B2B leads and a phone number for 85%. That is a coverage measure, meaning how often the system found an address at all, and it does not describe how often a verdict was right. Cleanlist AI publishes no verification accuracy percentage, and reading the 98% as one would be a mistake this page would rather prevent than be blamed for later.

An accuracy claim is checkable only when it carries three things. A denominator, so you know how many addresses produced the rate. A sample whose true state was established independently of the verifier being tested, which in practice means real bounce logs rather than the vendor's own verdicts. And a stated treatment of catch-alls, which is the field that quietly decides the number, because a vendor scoring every accept-all verdict as correct can publish whatever figure it likes.

For the shape of a claim you can actually check, OrbiSearch publishes a test against 538 real hard bounces from cold outreach campaigns, reporting 96.3% flagged and a 3.7% false positive rate (orbisearch.com, fetched September 7, 2026). Agree with the sample or not, it names one, which is more than a percentage sitting alone on a homepage does.

Three vendor names and nine cited sources, every one of them a vendor's own product page. Cleanlist AI measured the live United States desktop result for this term and two neighbouring ones on September 7, 2026, through the DataForSEO SERP API at depth 50 with the AI Overview body loaded, one task per query.

For bulk email verification, the AI Overview named ZeroBounce, MillionVerifier and Hunter, each with a single clause of capability attached: deep checks for spam traps and catch-alls, fast processing with pay-as-you-go pricing, and finding plus verifying in one place. Two of those three are companies Cleanlist AI buys data from, so this page reports what Google said and does not rank them. The nine sources behind the answer were bulkemailchecker.com, clearout.io, zerobounce.net, orbisearch.com, hunter.io, millionverifier.com twice, myemailverifier.com and verifalia.com. No blog post, no listicle and no forum thread was cited at all.

The two neighbouring terms invert that completely. On email list cleaning, 8 of the 11 cited sources were editorial, six written posts and two YouTube videos, against 3 vendor pages. On email list cleaning service, 10 sources broke down as 6 vendor pages, 2 blog posts and 2 forum threads, one on Reddit and one in the HubSpot community. Same category, opposite source diet, which is worth knowing before anyone decides what shape of page to build for which term.

The organic top five on the day, by rank_group, were bulkemailchecker.com, zerobounce.net, hunter.io, orbisearch.com and emaillistverify.com. Cleanlist AI appeared nowhere in the top 50 for any of the three terms. That is the honest position this page starts from, and it is why the page is being deepened rather than replaced.

Pick on the job, because three different purchases hide behind one question and the right answer changes completely between them. This page publishes no ranked vendor table, and the reason is worth stating plainly: several of the highest-ranking bulk verifiers on this search are companies Cleanlist AI buys data from, so ranking them would be positioning rather than advice.

Job one, verification only, at volume, on a list that needs nothing else attached to it. A dedicated per-address verifier is the more direct instrument, and the section above on cost shows why. The deciding fields are price per 1,000 addresses, published throughput, and how duplicates and unknown verdicts are billed.

Job two, verification plus finding. The list has holes in it as well as dead rows, and one run beats a verification job and an enrichment job that have to be reconciled afterwards. This is the case Cleanlist AI is built for, at 0.5 credits a validation and 1 credit for a verified work email.

Job three, verification at the point of capture. A form-level API question, sized in requests a day rather than addresses a month, and a different purchase from either of the others.

Whichever job it is, get three answers in writing before the trial rather than after the invoice: what is the price per 1,000 addresses, what is charged for an unknown verdict, and what does the accuracy figure's denominator contain. The section above on when Cleanlist AI is the wrong tool still stands, and nothing here softens it.

Duplicates cost nothing on Cleanlist AI. Unknown verdicts are a question to get in writing from any vendor, including this one.

Duplicates are handled at ingest rather than at billing. POST /lead-lists/{id}/leads skips duplicate rows at 0 credits, and POST /lead-lists/{id}/csv-import honours an idempotency_key, so a retried upload does not create a second copy of the list and does not create a second charge. Loading rows into Cleanlist AI is free in every form, and only the verification and enrichment steps draw down credits.

Unknown is where parts of the market publish a rule and Cleanlist AI does not. Bouncer states on its pricing page that it charges for neither duplicated addresses inside a list nor unknown results (usebouncer.com, fetched September 1, 2026 for the Cleanlist AI B2B Data Pricing Index). Cleanlist AI publishes one validation rate, 0.5 credits an address, with no separate carve-out for unknown verdicts stated anywhere public. Ask before a large run rather than assuming, and remember that unknowns are typically a small but real share of any batch.

The safeguard that does exist is the quote. POST /credits/estimate returns a signed quote_id with a five-minute life, so an integration can read the price of a job before running it and refuse, and a settled bulk run reports both credits_charged and credits_refunded. A loop with a bug cannot quietly spend a month of credits overnight, which is the failure mode worth designing against first.

Yes for a few hundred addresses and no for a real list, and the shape of a free tier tells you immediately which one you are being offered.

Cleanlist has three free surfaces. The browser checker at /tools/email-verifier runs 25 checks per IP per day with no account, covering syntax, DNS and mail exchange records, disposable domains and role flags, and deliberately stopping before the SMTP handshake. The cleaner at /tools/email-list-cleaner runs entirely in your browser with no upload and no cap. The Free plan carries 50 credits a month for up to 3 seats, which is 100 addresses validated. New workspaces start with 14 days of Pro (3 seats, 250 credits, every Pro feature), which is 500 addresses validated.

The rest of the market, from the Cleanlist AI B2B Data Free-Tier Census, every figure served by the vendor's own page and fetched September 1, 2026. Verifalia gives 25 free credits a day that reset at midnight GMT and do not bank, with CSV, XLS and XLSX upload supported. Clearout gives 100 credits on account creation with no card, and they never expire. Bouncer gives 100 one time, with a 1,000-credit minimum on the first paid purchase. Kickbox lists 100 verifications free. NeverBounce offers a free list analysis and free test credits without ever stating the count.

The shape rule is simple enough to apply in a minute. A daily trickle suits spot checks. A one-time batch suits cleaning one list before one campaign. Neither suits a pipeline that runs every week.

Cleanlist AI returns a verdict of valid, risky or invalid, with unknown for a receiving server that never answered, and a reason code beside it saying why. Six codes carry almost all of the traffic, and each one is an instruction rather than a label.

mx_ok. The domain publishes mail exchange records, so mail addressed to it has somewhere to go. Necessary and not sufficient on its own.

smtp_ok. The receiving server confirmed the specific mailbox at the handshake. This is the code behind a valid verdict and the only one that predicts a delivery.

no_mx. The domain publishes no mail exchange records at all, so nothing can reach any address on it. Invalid, and usually a typo in the domain rather than in the name before the at sign.

accept_all. The domain answers yes to every address, so the yes proves nothing about this one. Risky. Send it as its own segment with tight bounce monitoring rather than folding it into a confirmed list.

role_address. A shared functional inbox such as info@ or sales@. It exists and it will accept mail, and it belongs somewhere other than a one-to-one sequence, because it distorts reply-rate measurement wherever you leave it.

disposable_domain. A burner address from a temporary mail service. Treat it as invalid for outreach even when the mailbox is technically live today.

Unknown carries no reason code of its own, because no answer was obtained to explain. Re-queue those addresses for a later batch instead of deleting them or sending to them.