Email verification is a commodity dressed up as a technology. Every tool runs the same three checks; the interesting differences are in what they do when the answer is genuinely unknowable.
The three checks
1. Syntax
Is the address well-formed? Correct characters, one @, a plausible domain, no obvious typos.
Cheap, instant, and it catches an embarrassing share of real-world list problems: trailing spaces, .con instead of .com, two addresses in one field.
2. Domain
Does the domain exist, resolve, and publish MX records indicating it can receive mail?
This catches dead companies, typo'd domains and domains that were never configured for email. Also definitive, because a domain with no MX records cannot receive anything.
3. Mailbox
Does this specific address exist on that server?
The tool opens an SMTP conversation with the receiving server, gets as far as naming the recipient, and reads the response without sending anything. The server either indicates the address is deliverable or rejects it.
This is where it gets unreliable, for two reasons.
Some providers refuse to answer. Major providers deliberately return the same response for valid and invalid addresses, specifically to prevent this kind of enumeration. The verifier gets no signal.
Catch-all domains answer yes to everything. A domain configured to accept all mail returns a positive response for definitely-not-real-9973@company.com. The yes means nothing.
The catch-all problem
This is the honesty test for a verification tool.
A catch-all domain cannot be verified from outside. That is not a limitation of any particular vendor; it is a property of the configuration.
So a tool has two options:
- Report it as risky or unknown, which is true and less impressive
- Report it as valid, which is unprovable and makes the accuracy figures look better
Option two is common, and it is where inflated accuracy claims come from. It also produces the specific experience of running a list through a verifier, getting a clean bill of health, and watching a wave of bounces anyway.
Ask any vendor directly: how do you classify catch-all domains? The answer tells you how much to trust everything else they report.
What to do with catch-all addresses
Not "never send". Many catch-all addresses are perfectly good; they simply cannot be proven.
A workable approach:
- Keep them in a separate segment
- Send to them at lower volume, from a mailbox you are watching
- Measure their bounce rate independently
- Do not mix them into a large send that also carries your verified addresses
That way an unlucky segment cannot damage the reputation your verified sending is building.
Accuracy claims
"99% accurate" claims mean less than they look.
Accuracy against what? A test list of addresses that were straightforward to classify, excluding catch-alls and providers that block verification? That is most vendors' methodology, and it excludes exactly the cases where verification is hard.
A more useful question is: what percentage of a typical B2B list do you return an unknown or risky verdict for? A vendor who says 15 to 25% is being honest about the world. One who says almost none is classifying uncertainty as certainty.
The timing problem
This gets less attention than accuracy and matters more.
Business email data decays at roughly 20 to 30% a year. People change jobs, companies fold, domains lapse, addresses are retired.
A list verified in March is not a verified list in September. If your process is "verify on import, then send for months", you are protected at the start and progressively less so afterwards.
Two fixes:
Re-verify on a schedule. Anything older than three to six months before a campaign.
Verify at send time. Better, because it removes the decision. An address that has gone bad since import is skipped rather than sent to, whatever sequence it is in and however it arrived.
The second is what a sending platform should do for you. If yours does not, you are relying on remembering, and the whole point of tooling is to stop relying on remembering.
Do you need a standalone tool?
No, if your outreach platform verifies on import and again at send time, and does not charge credits that discourage you from doing it thoroughly.
Yes, if your platform verifies only at import, or does not verify at all, or meters verification in a way that changes your behaviour.
That last point deserves emphasis. Per-credit pricing creates a quiet tax on being thorough: cleaning a list has a price tag, so people clean less. The incentive should point toward verifying more, not less.
The bounce rate you are protecting
Under 1% is healthy. Under 2% is tolerable. Above roughly 5%, mailbox providers begin treating your sending as careless.
The important part: the cost of a high bounce rate is paid by the mail that did not bounce, through worse inbox placement for everything you send afterwards. That is what makes bounces expensive out of proportion to the addresses lost.
What verification cannot do
It cannot guarantee delivery. A mailbox can be full, a server can be misconfigured, an address can be deleted between the check and the send. Verification removes the large predictable share of bounces; a residue is normal and every sender has it.
It cannot tell you whether the person still works there. A perfectly deliverable address can belong to someone who left in March and whose mail nobody reads.
It cannot make a bad list good. Verification confirms the address exists. It says nothing about whether that business has the problem you solve.
Where Leads Ranger fits
Verification is built in rather than metered: every address found during discovery is checked as it arrives, imported lists can be run through the same checks in bulk, and every address is re-checked at send time so an invalid one is skipped rather than bounced. Catch-all domains are flagged as risky rather than reported as verified, because the alternative is a number that looks better and means less.
There are no verification credits to buy, which is deliberate: the moment cleaning a list costs money per address, people stop cleaning lists.