How we verify emails, and what we refuse to guess

The short version

There are three outcomes in a Lyre Leads export, and no middle ground between them:

• Verified — an SMTP verifier opened a real conversation with the recipient's mail server and the server confirmed this specific mailbox accepts mail. Typical bounce rate: under 2%.
• Published — the company printed this exact address on its own website, but its mail server accepts everything, so no verifier can confirm it either way. First-party evidence, unconfirmable by anyone. Labelled separately and never counted as verified.
• No email returned — we could not confirm an address and the company does not publish one for this person. You get their name, title and LinkedIn URL, and no email.

That is the whole vocabulary. What we never do is invent an address. If a company's mail server accepts everything (a catch-all configuration) then nobody, us included, can confirm an individual mailbox there, so we will not apply a plausible-looking format to a name and hand it to you wearing a confident label. Most tools in this space do exactly that and count it toward their coverage number.

Repeating an address the company itself published is a different act from guessing one. We kept those apart rather than collapsing them, in both directions: we do not hide a real address because a check was unavailable, and we do not promote it to "verified" because it looks good.

What "verified" actually means

When you see a "verified" label, this is what happened behind it: our verification provider (MillionVerifier) established a TCP connection to the recipient's mail server, went through the SMTP handshake, and issued a RCPT TO: command with the specific address in question. The server either responded with a 250 code (mailbox exists, accepts mail) or a 550 code (mailbox does not exist). We only mark as verified the addresses that got the 250.

This is the strongest confirmation possible short of actually sending a message. It confirms three things: the domain is real and has valid mail servers, the specific mailbox exists, and the mailbox accepts mail from the outside world. Combined with syntax checks, spam-trap filtering, and disposable-domain detection, a verified email in our platform has a false-positive rate roughly matching MillionVerifier's own published accuracy: about 1-2%.

That number is small enough that verified emails should be safe to send at your normal sending cadence without warming or throttling, provided your sending domain is already in good standing.

What catch-all is, and why every tool has this problem

A catch-all domain is one whose mail server is configured to accept every incoming message, regardless of whether the specific mailbox in the To: field actually exists. It's a common setup at larger companies — the mail team enables it so that typos, forwarded addresses, and legacy aliases don't bounce. Estimates vary but roughly 30-40% of B2B SaaS domains run some form of catch-all in 2026.

The consequence for email verification is absolute: SMTP verification cannot tell you whether a specific mailbox on a catch-all domain exists. The server answers "yes" to every RCPT TO: including nonsense addresses like [email protected]. This isn't a bug in verification tools; it's how the SMTP protocol responds when the server owner configures it this way.

Every email verification tool on the market — Findymail, Hunter, Snov.io, Prospeo, Icypeas, ContactOut, Wiza, us — hits this wall the same way. What varies is how each tool handles it after the wall.

The part nobody explains: catch-all addresses fail silently

Everything above is about verification time. Now consider send time, because the same server behaviour applies there and the consequence is the one that actually costs you money.

When you send to a wrong address at a normal domain, the server rejects it and you get a hard bounce. You see the failure immediately. When you send to a wrong address at a catch-all domain, the server answers 250 OK, accepts the message, and then routes it to a junk mailbox nobody reads, or discards it entirely. There is no bounce. There is no error. There is no signal of any kind.

Work through what that means for the guarantee the industry advertises. A bounce-rate guarantee measures bounces. A wrong guess on a catch-all domain does not produce a bounce. So the guarantee is structurally incapable of detecting the exact failure it appears to protect you from. It can hold at a perfect 0% while a meaningful share of the addresses in your file go nowhere at all.

This is not a hypothetical, and the vendors are not hiding it. It is in their own published documentation:

• Findymail advertises a bounce guarantee of "under 5% bounce rate, guaranteed" with credits refunded if exceeded. Catch-all addresses sit inside that guaranteed pool. They are not carved out of it.
• Apollo states the policy plainly in its own knowledge base: "we don't eliminate a valid email just because it belongs to a catch-all domain."

Neither statement is dishonest. Both are accurate descriptions of what those tools do, and both companies disclose the behaviour to anyone who reads the documentation. The problem is not deception. The problem is that the headline metric being guaranteed cannot see the failure mode, so a buyer reading only the guarantee draws a conclusion the guarantee does not support.

Here is what it looks like from your desk. You buy 1,000 addresses. You send. Your bounce rate comes back at 1%, comfortably inside the guarantee. Your reply rate is dismal. You conclude your subject line is weak, or your offer is wrong, or the market is saturated, so you rewrite the sequence and run it again. The copy was never the problem. A share of those messages were accepted by a server and deleted without a human ever seeing them, and no number on your dashboard was ever going to tell you.

This is the single reason our labels exist, and it is also why we do not lead with a bounce-rate guarantee of our own. On this specific failure, a bounce guarantee is not a weak promise. It is an unfalsifiable one.

What we do on a catch-all domain, and what we decided not to do

An honest account, including a change of mind.

The obvious workaround, and the one we built, is to infer the format. If you have confirmed addresses for two or more people at a company and they all use first.last@, you can apply that format to a third person and label the result a prediction rather than a verification. We shipped exactly that, as two graded tiers with the supporting sample count attached.

Then we measured how often it could actually fire. In August 2026, across our entire production database, of 125 catch-all domains one had two or more confirmed addresses behind it, and 119 had no confirmed address at all. The reason is circular and unavoidable: on a catch-all domain every verification returns "yes", so we stop checking, so we never accumulate the confirmed addresses the prediction depends on. The evidence can only come from somewhere else, and for these companies it usually does not exist. Domains run catch-all precisely because the company does not publish individual mailboxes.

So we removed the tiers. A feature that fires on one domain out of 125 is not a capability, it is a line in a marketing page, and this is the wrong page to keep one on. If the underlying data ever becomes dense enough to support a prediction honestly, we will build it back and say so.

We re-measured in September 2026, and the density has moved: of 551 domains we have now confirmed as catch-all, 117 carry a learned format and 60 have two or more samples behind them. The tiers are still switched off. Density was the reason we removed them, so it is a reason to look again, but turning them back on changes what an address on a catch-all domain claims to be, and that is a decision about what we tell you, not a threshold in a config file. When we make it, this page will say so before the code does.

The one case we changed our mind about

Removing the prediction tiers was right. Applying the same rule to addresses the company publishes about itself was not, and we corrected it in August 2026.

If a business prints [email protected] on its own contact page, and the person we identified is David, that address is not a prediction. It is a first-party fact, published deliberately by the company so that people would use it. The only thing SMTP would have added is confirmation that the mailbox is still live today, and on a catch-all domain SMTP cannot supply that for any address, including ones we would have happily called verified on a normal domain.

Withholding it was not caution. It was throwing away the company's own answer to the question, and leaving the user to go find the same page themselves. So we now return it, under its own label, with the reason it cannot be verified stated plainly. It is never folded into a verified count, never exported in a verified-only file, and always carries its own badge.

How much difference it makes, measured

Not much, and we would rather say so than let the label imply otherwise. Across 13,515 enriched US businesses holding a scraped business email, 44% of those addresses are person-named on the company's own domain rather than a role address like info@. The label only changes the outcome where such an address sits on a catch-all domain, which is rare, and so far it has returned an address at 51 companies that would otherwise have come back as a name with no email.

The reason it is small is the same circularity that killed the prediction tiers, seen from the other side: a company that runs catch-all is usually a company that has decided not to publish individual mailboxes. The two behaviours travel together. Separately, in a sample of 96 US local businesses with working websites, only 11% published any mailto: link at all; most take enquiries through a form.

We shipped it anyway, because a small number of correct addresses is worth more than a rounding error's worth of principle, and because withholding an address a business printed on its own website was never defensible. But it is an increment, not a breakthrough, and anyone comparing tools should read it that way.

These addresses also do something useful beyond the individual lead: they are evidence about a domain's convention that does not come from SMTP, which is the exact ingredient the prediction tiers were starving for. If enough accumulate, the measurement that switched those tiers off becomes worth re-running. We ran it again in September 2026, which is where the 117 domains above come from, and we will keep running it before changing anything, not the other way round.

What you get on a catch-all domain

The person's name, their title, their LinkedIn URL where we found one, and their address if the company published it. If it did not, you get the person without an email. That is still a genuinely useful outcome: you know exactly who to approach and you can reach them on LinkedIn, which is often the better channel for a company that has deliberately made itself hard to email. What you will not get from us is a plausible-looking address that nobody, including the company, ever put in writing.

Why this costs us a coverage number

Counting those predictions as finds would take our reported coverage on one recent sample from 36% to 80%, without a single additional address being confirmed. That is the same arithmetic we describe above, applied to ourselves. We would rather publish the smaller number and have it mean something.

What you should do with each label

Verified: send at your normal cadence. Bounce risk is under 2%, which is well below the thresholds that hurt sender reputation with Gmail, Outlook, and the major ESPs.

Published: send, but keep it in its own segment and watch it separately. The address came from the company's own website, so it was correct when they published it. What nobody can tell you is whether the mailbox is still live, and on a catch-all domain a dead one will not bounce, it will go quiet. Segmenting these means a problem shows up as a reply-rate difference instead of hiding inside your overall number. Do not put them in a file you have labelled verified, for yourself or for a client.

No email returned: reach the person on LinkedIn. You have their name, title and profile URL, and for a company running catch-all that is usually the channel that works anyway. If you source the address elsewhere, verify it before you send.

Why the industry doesn't distinguish the two

Most email finders in 2026 fold pattern-matched addresses into their "valid" or "verified" totals. They usually disclose this — buried in an FAQ or a knowledge-base article — and often back it with a bounce guarantee (typically under 5%, refund on credits if exceeded).

That guarantee is real, and the tools that offer it are not lying. But it has two properties worth understanding:

1. The refund is on credits, not on damage. If your bounce rate ticks up past a threshold and your sending domain gets throttled or spam-foldered by Gmail, no credit refund makes you whole. The damage lives on your sender reputation for weeks or months.
2. On catch-all domains, the guarantee measures the wrong thing entirely. As covered above, a wrong address on a catch-all domain does not bounce, so it never counts against the guaranteed number. The addresses most likely to be wrong are precisely the ones the guarantee cannot see.
3. The headline coverage number gets inflated by the ambiguity. When a benchmark reports Tool X at 65% coverage, that number counts pattern-matched addresses as full "found" — the same as SMTP-verified ones. So a competitor number and ours are not measuring the same thing. Theirs counts predictions; ours counts confirmations. The honest comparison is to ask any vendor what their number looks like with catch-all addresses excluded

We chose to label the two categories separately because we think the distinction matters to the person who ends up sending the email. If you know which is which, you can pick your sending strategy per tier. If everything is one bucket, you're relying on the tool's guarantee to absorb risk it doesn't actually absorb — because the credits it refunds cost cents while a burned sending domain costs weeks.

We tested this against a competitor, and found it happening

The argument above is mechanical, so on 6 August 2026 we checked whether it shows up in practice. We took 25 contacts our own pipeline had discovered at live-chat and conversational-AI vendors, and submitted the identical names and domains to Findymail, one of the better-regarded email finders in this category. Small sample, run by us, and we are the interested party. Read it with that in mind.

Findymail returned an address for 23 of the 25. That is a good result on a genuinely hard task, and better raw coverage than we would have reported on the same set, because we withhold anything we cannot SMTP-confirm.

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. 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 person's inbox or in no inbox at all. This is the failure described in the section above, caught in a sample of 25.

The second finding surprised us more. We re-ran our own pattern engine over the same 25 people and compared our candidate addresses to theirs. Our engine independently produced the identical address for 21 of their 22 correct answers, about 95%, usually as its first or second guess. The one we 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 comparison is the honest summary of where we actually stand. The difference between a tool reporting 92% coverage and us reporting a much lower verified number is not that they can find addresses we cannot. On this sample we found the same addresses they did. The difference is what each of us is prepared to call verified, and which failures each of us is prepared to let you discover on your own.

The test paid for itself in a second way. It exposed three cases where a company's marketing domain is not the domain its people receive mail on, so every address we generated was aimed at a domain that could never confirm. We now resolve that automatically from public DNS records before guessing, which took our reproduction rate from roughly 70% to 95% on the same set. We would not have found that without running the comparison.

Our commitment

Three rules we won't break:

1. Every email address we return is either SMTP-confirmed or carries a label saying it is not, with the reason. Nothing that was not confirmed is ever counted in a verified total, exported in a verified-only file, or sold as verified.
2. We will not ship a predicted address under a softer label to lift a coverage number. We built that feature, measured that it could almost never fire honestly, and removed it rather than keep the claim.
3. On a catch-all domain we never call an address verified, because nobody can. If the company published one itself we return that, labelled Published. Anything we generated carries the catch-all label, which says plainly that it could not be confirmed. Presenting a statistical prior ("first.last is 41% of SaaS domains, so first.last it is") as a find is the industry's coverage-inflation trick, and a label that tells you what you are holding is the difference.

Both rules are enforced in code (see PATTERN_MATCH_MIN_SAMPLES in our email pipeline). Changing the threshold or blurring the tier would require a code change and a commit in our public GitHub history, so this is not just a policy — it's a technical constraint we've placed on ourselves.

On bounce rates and what we do (and don't) claim

We do not publish a public bounce number today. The reason is simple: we can't measure it. Once you export an email from Lyre Leads and send it from your own ESP, we don't see the bounce. The bounce lands in your account, not ours.

What we can measure — and will start publishing once we have meaningful volume — is the bounce rate on emails we send from Lyre Leads for our own outreach. That number will be a lower bound on what customers should expect (our sender reputation may be better or worse than any given customer's), but it will be an honest ceiling on how well the verification pipeline is doing.

Until then: if someone quotes a headline bounce rate on any email tool without showing you their measurement methodology, treat it as marketing copy, not evidence.