Why Every Email Vendor's Accuracy Number Means Something Different

The three numbers, and why they are not comparable

Three different metrics get reported as though they were the same thing.

Coverage, also called match rate or hit rate, is how often a provider returns any address at all for the records you submit. Clay, which runs public provider tests, defines it as how often the provider returns any value at all for the records you send.

Accuracy, also called data quality, is how often a returned address is correct. Crucially, it is scored against the addresses the tool returned, not against the contacts you submitted.

Bounce rate is measured after you send, on addresses that were already returned to you.

Notice that accuracy and bounce rate both have the same move available to them: they are measured on what the tool chose to return. A provider that returns very few addresses, and only the easy ones, will post a spectacular accuracy number. The number is true. It is also close to meaningless without the coverage figure beside it, and the reverse is equally true.

What you hand the tool changes its score more than the tool does

Here is one tool, Findymail, scored in three public tests:

• Clay's work-email provider test: 90.26% coverage
• Anymail Finder's June 2026 benchmark, where every tool received the contact's name, company, domain and LinkedIn URL: 70.9% coverage, 95.6% accuracy
• Dropcontact's 2025 benchmark, where tools received only first name, last name and company name, with no domain and no LinkedIn: 42.5% raw, 39.9% after subtracting hard bounces and wrong domains

Same tool. Ninety percent down to forty. Nothing about the product changed between those tests. The only variable is how much you hand it before it starts work.

So when a vendor quotes a coverage number, the question that decides its meaning is: coverage of what, given what? Almost nobody states it.

There is a further gap that nobody publishes at all. All three tests above supply the person's name. If your input is a list of companies and you do not yet know who works there, the tool has to discover the human first, and that step has its own failure rate. We could not find a single vendor publishing a number for that problem, which is the problem most buyers actually have.

What a bounce guarantee cannot see

This is the part with real money attached.

A catch-all domain is configured to accept every incoming message regardless of whether the specific mailbox exists. Roughly a third of B2B domains run one. Across the conversational AI vendors we looked at, catch-all domains were 41% of companies.

Everyone in this industry knows catch-all breaks verification: you cannot confirm a mailbox on a server that says yes to everything. That much is common knowledge.

The part that gets skipped is what happens at send time. A wrong address at a normal domain is rejected and you get a hard bounce. A wrong address at a catch-all domain gets a 250 OK, is accepted, and is then silently discarded or delivered to a mailbox nobody reads. No bounce. No error. No signal of any kind.

Now hold that against the guarantee the industry advertises. A bounce guarantee measures bounces. A wrong guess on a catch-all domain does not produce one. The guarantee is structurally incapable of detecting the failure it appears to protect you from. It can sit at a perfect zero while a real share of your list goes nowhere at all.

The vendors are not hiding this. It is in their own documentation:

• Findymail advertises "under 5% bounce rate, guaranteed" with credits refunded if exceeded. Catch-all addresses sit inside that guaranteed pool rather than being carved out of it.
• Apollo states the policy directly in its knowledge base: "we don't eliminate a valid email just because it belongs to a catch-all domain."
• Hunter takes the opposite approach and gives catch-alls their own status, accept_all, with the warning that using this type may lead to bounces.

Neither of the first two is lying. Both disclose the behaviour to anyone who reads the documentation. The problem is that a buyer reading only the headline draws a conclusion the headline does not support.

What that looks like from your desk: you buy a thousand addresses, you send, your bounce rate comes back at 1%, comfortably inside the guarantee, and your reply rate is dismal. So you rewrite the subject line and question the offer. The copy was never the problem.

The same pipeline, reported three ways

To make the accounting concrete, here is our own data reported three different ways. The set is 136 decision-makers we discovered at 56 companies. The outcomes were 49 SMTP-verified, 60 on catch-all domains, and 27 pattern misses.

All three are defensible. All three describe the same day, the same data, the same pipeline. Nothing improved between the first row and the third except the arithmetic. We publish the first.

The third row deserves a closer look, because it is the one the industry actually uses. Those 60 extra addresses are not near-misses or educated guesses. At every one of those companies the mail server accepts everything, and we had no confirmed address anywhere at that company to learn the format from. There is nothing behind them at all. Counting them as finds is what takes a 36% into an 80%, and it is invisible to the buyer, because as covered above they will never bounce.

A head-to-head we ran on ourselves

On 6 August 2026 we ran our own pipeline directly against Findymail. We took 25 decision-makers our discovery had found at live-chat and conversational AI vendors, and submitted identical names and domains to both.

They returned an address for 23 of the 25. That is better raw coverage than we would report on the same set, because we withhold anything we cannot SMTP-confirm. Credit where it is due.

Two findings came out of it.

One of those 23 addresses belonged to a different person. For one executive, the returned address was built from another employee's surname: same first name, wrong human, at the right company. The domain was catch-all. Nothing in any verification step could have caught it, and nothing at send time would either. It would be accepted, it would not bounce, and it would land in the wrong inbox or in none.

Our own engine reproduced 21 of their 22 correct answers, about 95%, usually as its first or second guess. So the gap between their coverage number and our verified number is not that they can find addresses we cannot. On this sample we found the same addresses. The difference is which ones each of us is willing to label verified.

The one we genuinely missed used a hyphenated format that is rare enough that chasing it would cost verification credits on every other lead to catch the occasional outlier. That is a deliberate trade, and worth being explicit about.

Caveats, stated plainly: 25 contacts is a small sample, we ran the test ourselves, and we are an interested party. We are publishing the method so anyone can rerun it.

Finding the domain a company actually receives mail on

The test cost us some pride, because it exposed a real gap. Three of the 25 sat on domains that do not carry the company's mail at all, so every candidate we generated was aimed at a domain that could never confirm. That led to the most useful technique in this article.

The domain on a company's website is not always the domain its people receive mail on. Product brands, acquisitions and TLD moves all break the assumption. Two public DNS records give it away, and both are free to check on any DNS lookup site.

MX records list the servers permitted to accept mail for a domain. If a domain has no MX records at all, it cannot receive mail, full stop, and every address you generate there is dead before you send. One vendor in our test set ran its entire marketing site on a domain with zero MX records.

DMARC report addresses are the powerful one. A DMARC record, published as a TXT record on the _dmarc subdomain, tells receiving servers where to send authentication reports through its rua (aggregate) and ruf (forensic) tags. Those reports go to whoever operates the company's mail programme. So a report address on a different root domain is strong evidence of the real corporate domain.

In our test set this resolved a product domain to its parent company, and a .ai marketing domain to the matching .com where the mailboxes actually live.

One trap will ruin the technique if you miss it: filter out third-party DMARC processors first. Valimail, MXToolbox, dmarcian, EasyDMARC and similar all appear as report addresses. Without a blocklist, every company using Valimail appears to resolve to vali.email and the signal is worthless.

Adding this took our reproduction rate on that 25-contact set from roughly 70% to 95%. Two DNS lookups, no API, no cost.

How address prediction actually works

Companies almost never mix mailbox formats. Whoever configured the mail server picked a convention and it stuck. We measured this across 272 real contacts: 88.2% of addresses follow a pattern derivable from the person's name.

The distribution is not evenly spread, which matters because it decides which guess you pay to test first. In B2B SaaS we measured first.last at 40.8%, bare first at 30.4%, and flast at 17.5%, with a long tail after that. In small trades businesses the order is different, with bare first dominating. Reusing one industry's priors on another is a quiet and expensive mistake.

The compounding effect is where the economics live. Guessing blind at an unknown domain, our first candidate is correct about 44% of the time. After a single confirmed address at that domain, the first candidate is correct about 76% of the time. So the first person at a company may cost several verification credits and everyone after them usually costs one. Finding ten people at one company is far cheaper per person than finding one person at ten companies.

The same memory works in reverse and saves more than it earns. Once a domain answers yes to everything, it is catch-all: record that, and every future contact there short-circuits before you spend anything.

Two questions worth asking any vendor

If you take nothing else from this:

1. Out of every contact I submit, how many do I get a usable address for? Not accuracy on what you returned. Coverage on what I gave you.
2. Are catch-all addresses counted inside that number, and inside your bounce guarantee?

The second question changes the answer more than any other. In our own data it is the difference between 36% and 80%.

We label ours in tiers and we do not count a catch-all guess as a verified address. The full method, including what our SMTP verification actually does and where our own numbers land, is written up on how we verify emails. If you want to see the labels in your own data, the ready-made lead lists and the platform both carry them.