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

What is bulk email verification?

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.

Why does bounce rate matter enough to verify a list first?

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 gets flagged. Cross 10% and it risks being blocklisted outright. Unverified B2B lists commonly average 8% to 12% hard bounces, which means an unverified list clears the first two 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 two to six weeks of reduced volume, and every campaign in that window underperforms for reasons that have nothing to do with the campaign.

What bounce rate should you be aiming for?

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.

How do you verify a large email list, step by step?

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. In Cleanlist a list holds 2,500 leads on any paid plan and 100 on Free, and CSV upload is a paid-plan feature, so bulk cleaning starts at Starter.

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 direct dial is 10, so learning that an address is dead before building a full contact around it is a twentieth of the cost of learning it afterwards.

For a file bigger than one list, split it or push it through the API. The honest version of this page says so rather than implying a 200,000-row CSV drops into the portal in one piece.

Why do catch-all domains break naive bulk verification?

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 20% to 30% of B2B domains run catch-all, and the figure climbs above 50% inside Fortune 1000 companies, which means the accounts you most want to reach are the ones hardest to verify. Excluding every catch-all from outreach can shrink an enterprise list by 40% or more, 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 pool, ZeroBounce and Emailable among them.

What should you do with each bucket the run returns?

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

Deliverable. The mail server confirmed the mailbox. Send.

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.

Should you clean a list before you verify it, or after?

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.

What does bulk email verification cost?

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

The plans are Free at $0 for 30 credits a month with one seat and 100 leads per list, Starter at $79 for 1,500 credits and 2 seats, Pro at $229 for 5,000 credits and 5 seats with the public REST API, and Scale at $599 for 15,000 credits and 10 seats. Annual billing takes 25% off and an extra seat is $20 a month. Credits sit in one shared team wallet rather than being allocated per seat, so a single large run does not need to be split across licences.

The arithmetic that matters: at 0.5 credits a row, Starter's 1,500 credits verify 3,000 addresses for $79, Pro's 5,000 verify 10,000, and Scale's 15,000 verify 30,000. Finding a new verified work email is 1 credit, a direct dial is 10, both on one contact is 11, and a lookup that returns nothing is 0.

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

Can you run bulk verification through an API?

Yes, on Pro and Scale. The Cleanlist 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. Both the API and MCP are held back during the 14-day trial.

How often should you re-verify a list?

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.

Does verifying a list protect sender reputation on its own?

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.

Cleanlist does not send email, so it cannot influence any of those levers, 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.

What can bulk verification not tell you?

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.

When is Cleanlist the wrong tool for bulk verification?

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. A Cleanlist list holds 2,500 leads, so a single file of hundreds of thousands of addresses means splitting it or driving it through the API rather than the portal. 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 is built around B2B work addresses and its coverage numbers, 98% verified work email and 85% direct dial 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 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 direct dial, 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.