A 9% bounce rate doesn't just kill the campaign you're on. It tells inbox providers you sent to a list you didn't clean, and they adjust your reputation for everything that follows. Valid contacts start going to spam. Verification is the step teams skip until they learn this in production. This guide covers how to build it before that.
What it means to verify an email address
Verifying an email address is not one check. It is three, run in order, and an address has to clear all of them to be safe to contact.
The first is a syntax check: is the address formatted correctly? An address like john.doe@@example..com fails before anything else happens. The second is a domain check: the verifier looks up the domain's MX records to confirm the domain can actually receive mail. A domain with no mail server, or one that no longer exists, fails here. The third is the mailbox check, and it is the one that matters most: the verifier connects to the receiving mail server and asks whether that specific mailbox exists, without ever sending a message.
The reason verification matters is that the first two checks pass for plenty of addresses that are still dead. jsmith@stripe.com is perfectly formatted and stripe.com has working mail servers, but if Jsmith left the company eight months ago, that address bounces. Only the mailbox check catches it, and a list that looks fine in a spreadsheet often loses most of its bad addresses at exactly that stage.
Run one address through all three checks
Awaiting check
Awaiting check
Awaiting check
The addresses that bounce are usually the ones that look fine: they clear the syntax and domain checks and only fail at the invisible mailbox check.
Email verification vs. email validation
These two terms get used interchangeably, and the difference is worth keeping straight because it changes what you can trust.
Validation checks whether an address is correctly formatted and follows the syntax rules of an email address: a local part, an @, and a real domain. It catches typos, stray spaces, and invalid characters. What it does not do is confirm the address exists. notarealperson@stripe.com passes validation cleanly.
Verification goes the step further. It checks whether the address is deliverable by querying the receiving mail server to confirm the mailbox is active. Validation tells you the address looks correct. Verification tells you it exists. For outbound, only the second one protects your sender reputation, because inbox providers do not care whether an address was well-formatted. They care whether it bounced.
Why unverified lists wreck deliverability
Bounce rate is the single metric inbox providers watch most closely, and it compounds against you faster than most teams expect. A hard bounce, which happens when an address does not exist at all, is read as a signal that you are sending to a list you did not clean. Send enough of them and providers start routing all of your mail, including mail to valid contacts, to the spam folder.
This is why verification is a deliverability problem, not a data-hygiene nicety. The teams that send the most outbound are the ones who feel it hardest, because a damaged sending domain takes weeks to recover and there is no shortcut back.
“Not having Clay would hugely reduce our ability to run good outbound campaigns. We wouldn't be calling people as much, because it's hard to get good phone numbers. We wouldn't be emailing as much, because we'd be likely to bounce or go to spam. With Clay, we have a reliable source.”
The practical rule: verify before the first send, and verify again before any send to a list you have not touched in a few months. Addresses decay. People change jobs, abandon inboxes, and switch providers, and an address that verified clean in January can bounce in June.
The catch-all problem: why some addresses can't be cleanly verified
Here is where most verification tools quietly struggle, and where the difference between a good verifier and a weak one shows up.
A catch-all domain (also called accept-all) is configured to accept mail for every possible address, whether the mailbox exists or not. When a verifier runs its mailbox check against anything@catchall-company.com, the server says yes to all of it. The verifier cannot tell a real mailbox from a fake one, because the server refuses to distinguish them. Catch-all setups are common at larger companies, so this is not an edge case you can ignore.
Clay's first-party provider testing makes the gap concrete. On normal, non-catch-all domains, the best verifiers reach near-perfect accuracy: ZeroBounce hit 99.25% accuracy with 99.37% coverage, and Findymail hit 98.92% with full coverage. On catch-all domains, the same category of tools tops out lower: Findymail led at 94.99% and the next-best options sat around 92 to 94%. The roughly five-point drop is the entire catch-all problem in one number, and it is why a single "valid" stamp means different things depending on the domain.
The same address, verified on a standard vs. catch-all domain
j.rivera@example.com99.25%
accuracy
99.37%
coverage
Catch-all domains are where verification certainty breaks down: the same tool that is near-perfect on a normal domain can only reach the mid-90s when the server accepts every address.
How to verify email addresses without sending an email
The naive way to test an address is to send it a message and watch for a bounce-back. That works for a single address you do not mind exposing, but it is the wrong approach at any scale: every test send risks your sender reputation, takes a real address to send from, and tips off the recipient.
The standard method skips the send entirely. A verifier connects to the recipient's mail server over SMTP and begins the handshake a real message would start, asking the server whether it will accept mail for the address. The server answers based on whether the mailbox exists. The verifier then closes the connection before any message is delivered. Nothing lands in the recipient's inbox, and no reputation is spent.
For a handful of addresses, a free single-address checker is fine. The moment you are working with a list, doing this address by address stops making sense. You want a tool that runs all three checks across the whole list in one pass, flags catch-all and disposable addresses separately, and returns a clean status you can filter on before anything reaches your sequencer.
Why no single verifier is enough
If you only ever verified non-catch-all domains, you could pick the single most accurate tool and stop reading. Real lists are not that tidy. They mix domain types, regions, and company sizes, and across those conditions every individual provider forces a tradeoff between quality (how accurate its verdicts are) and coverage (what share of addresses it can return a verdict on at all).
Clay's work-email testing shows the pattern plainly. Hunter posted the highest global accuracy at 97.15%, but returned a verdict on only 52.87% of addresses. Findymail traded a little accuracy for far more reach: 96.26% quality at 90.26% coverage. Wiza covered 85% at 94.72% quality. No provider sat in the top-right corner of both axes, because the providers that are cautious enough to be highly accurate are also the ones that abstain most often.
Quality vs. coverage across work-email providers (2025 test)
Tap any dot to see its exact quality and coverage. The dots sit along a tradeoff line, not in one corner.
Every single verifier forces a choice between accuracy and coverage; the most accurate tools return a verdict on the fewest addresses, so no one provider wins both.
How waterfall verification works
The way out of the tradeoff is not to pick a better single tool. It is to stop relying on one. A waterfall runs an address through multiple providers in a set order, starting with the cheapest, and stops the moment one returns a confident result. The first provider you query handles the easy addresses cheaply. Anything it cannot resolve falls through to the next provider, and the next, until one of them lands a confident verdict or the chain runs out.
This is the mechanic behind Clay's coverage numbers. A single provider that returns verdicts on 50% of a list leaves the other half unusable. Chain three or four providers and the misses from the first get caught by the second, so usable coverage climbs toward the high coverage of your widest provider while accuracy stays near the level of your best one. You stop choosing between accurate and complete.
One address running through a cheapest-first verification waterfall
p.nguyen@example.comUsable coverage
53%
One provider alone: 53%
Cost so far
$0.000
Cheap providers run first; you only pay the chain until one lands.
Ordering verifiers cheapest-first and stopping at the first confident result recovers addresses a single tool would have discarded, lifting usable coverage without dropping accuracy or overspending.
Customers feel this most when they switch from a single provider to a combined approach. Open AI's team saw enrichment coverage climb from roughly 40% to roughly 80% after moving to waterfall enrichment.
enrichment coverage after moving from a single provider to waterfall enrichment.
The fallback logic is the same reason waterfalls beat single tools for finding data in the first place, and teams describe it the same way once they see it work.
“When one provider doesn't have it, Clay automatically checks the next one. It really helps our inbound and outbound motions because we can use the best source of data. I've never seen a tool that was so easy to do this process.”
How to verify email addresses in Clay
Putting this together in Clay takes a single table and a few columns.
- 1
Bring your contacts into a Clay table
Import from a CSV, your CRM, or a list you built with a Find People search. You need at least an email address per row, or the name and company domain to find one.
- 2
Add a work-email waterfall if you are starting from names
Clay queries the providers you add to the waterfall in the order you set, so the chain is yours to configure rather than a fixed sequence.
- 3
Add an email verification column and run it across the list
Clay returns a verification status for each row: Valid, Invalid, Catch-all, Unknown, or Role-based, so catch-all and role-based addresses are flagged separately instead of waved through as valid.
- 4
Filter on the status column
Route clean, deliverable addresses to your sequencer, hold catch-all addresses for a more cautious send or a secondary check, and drop the invalid ones before they ever cost you a bounce.
- 5
Set the table to re-run on a schedule or when new rows arrive
Verification happens continuously instead of as a one-time cleanup you forget to repeat.
One extra step separates careful teams from the rest. Verification confirms an address is deliverable. It does not confirm the person still works there, and a verified address at a company someone left last quarter is still a wasted send. For your highest-value accounts, add a Claygent research step to confirm current employment before you trust an older address.
Research whether {{first_name}} {{last_name}} currently works at{{company_name}} ({{company_domain}}).Check the company's team or about pages and recent public professionalprofiles. Return one of: "Current" (clear evidence they work there now),"Left" (evidence they moved to a different company), or "Unconfirmed"(no clear evidence either way).In one sentence, state the evidence you used. Do not guess. If sourcesconflict or are missing, return "Unconfirmed."
Choosing a verifier: what the benchmarks say
You do not have to take provider accuracy on faith. Clay tests verifiers against ground-truth datasets and publishes the results, so you can match a tool to your list instead of guessing.
Clay's verifier benchmarks by category
The pattern holds across the board: non-catch-all verification is close to solved, catch-all verification is the hard part, and the cost gap between premium and budget tools is far smaller than the bounce a single bad send can cost you. Start cheap, waterfall to a premium verifier for the addresses your first tool cannot resolve, and treat catch-all results as a separate bucket rather than a clean pass.