Email Verification Tools: Validating Addresses at Capture
Real-time verification against batch cleaning, what each catches, and the accuracy claims to be sceptical of.
On this page
The short version
- Real-time verification at capture and batch cleaning of an import solve different problems, and only one of them is worth running on an established list.
- Your own bounce data is more reliable than any verifier for addresses you already mail, because it reflects actual delivery rather than a probe.
- Treat "unknown" and "risky" results as a segment to be careful with, not as a removal instruction. Some correct addresses come back uncertain.
Verification services check whether an address is likely to accept mail, by validating the syntax, confirming the domain resolves and has mail servers, and — where the receiving server permits it — probing whether the mailbox exists.
That last step is the one that varies. Many providers deliberately accept all addresses at the probe stage, which means a verifier cannot distinguish a real mailbox from a non-existent one at those domains and returns an uncertain result.
Two uses, different value
| Real-time at capture | Batch on an import | |
|---|---|---|
| Prevents | Typos and bad addresses entering | Mailing a list of unknown quality |
| Cost basis | Per address, ongoing | Per address, one-off |
| Value on an established list | High — every new signup | Low — bounce data is better |
| Value before a first send | n/a | High, and sometimes essential |
| Failure mode | API down blocks signups | A batch marked wrong is removed |
Why your bounce data beats a verifier
For any address you have already mailed, you have direct evidence: the receiving server either accepted it or told you why not. That is a real delivery attempt, not an inference from a probe.
Running a verifier over an established, actively mailed list therefore tells you very little you do not already know, and it costs per address. The exception is a list that has been dormant — addresses valid two years ago may not be now, and there is no recent bounce data to rely on.
So the rule is: verify what you have not mailed. Trust bounce data for what you have.
What the result categories mean
Valid: syntax, domain and — where possible — mailbox all check out. Safe to mail.
Invalid: the domain does not exist or the server confirmed no such mailbox. Remove.
Accept-all or unknown: the receiving server accepts everything at the probe stage, so the verifier cannot tell. This is not a bad address, it is an unanswerable question, and it is common at some large providers.
Disposable: a temporary-address service. Whether to keep them is a judgement — they will never engage, and your hygiene rules will remove them anyway.
Role: info@, sales@, support@. Not invalid, and lower-engaging on average. Segment rather than remove.
The category to be careful with is accept-all. Removing everything marked unknown will remove a meaningful number of perfectly good addresses at providers that do not answer probes.
Reading accuracy claims
Vendors publish accuracy figures in the high nineties. Those are usually measured against a test set of known addresses, which is a different population from your list.
The check worth running: take a sample of addresses you know the answer for — recent bounces, recent engaged subscribers — run them through, and count how many the service gets right. It is an hour and it tells you what the figure means for your data.
The number that matters most is how many of your engaged subscribers come back as invalid or risky. Any false positive there is an address the service would have had you remove, and one of those in a hundred is a lot on a large list.
Verification check
- Real-time verification is used at capture, not on the established list
- The form fails open when the service is unreachable
- Batch verification runs before importing, not after mailing
- Accept-all results are kept, not removed
- Role addresses are segmented rather than deleted
- Accuracy was measured against a sample you know the answer for
- False positives among engaged subscribers were counted
Frequently asked questions
Is verification worth the cost?
At capture, yes if you acquire from mixed sources — a single hard bounce costs more in reputation than the check costs. On an established list, usually not, because your own bounce data already answers the question.
Should I remove disposable addresses?
They will not engage and your hygiene rules will remove them in due course. Blocking them at capture costs you some privacy-conscious subscribers who would have engaged, so it is a trade rather than an obvious win.
How often should a list be verified?
An actively mailed list, never — bounce processing is continuous verification. A dormant list, before any send, because there is no recent evidence to work from.