How to verify an email list before you send to it
Verify before you send: check syntax, confirm the domain resolves and publishes a mail exchanger, flag disposable and role addresses, and drop anything a mail server rejects. Then send a small sample. Verification reduces bounces; it does not prove consent, interest or inbox placement, so keep the claim narrow.
The checks, and the rows each one removes
Syntax removes typos and copy artefacts. DNS removes dead domains, which is usually the biggest cut on an old list. Mail exchanger checks remove domains that exist but accept no mail. Disposable and role flags are judgement calls, not errors.
Run them in that order because each pass makes the next cheaper. Checking a mailbox server for an address with a dead domain wastes time and tells you nothing.
What to do with the survivors
Sort the survivors by where they came from. If the published-source rows pass at a much higher rate than the pattern rows, keep that knowledge: it changes how you collect next time.
Then send a small batch. The only signal that matters after verification is what real receivers do, and you cannot get that from a checker.
Words that keep you honest
Say verified, not valid. A verified address passed technical checks. A valid address implies a person with a working relationship to that mailbox, which you do not know.
That distinction protects you when someone asks why a verified address bounced. The answer is that mailboxes close, and the check was a snapshot.
The order that saves the most time
Deduplicate, then run syntax and DNS checks, then probe mailboxes on what remains. Each pass shrinks the set, so the expensive check is applied to the smallest useful list.
If you probe first, you spend the slowest check on addresses that a dead domain already disqualified.
Reading the result honestly
Report a pass rate, not a success claim. Say how many rows passed and how many you removed, then say what you will watch in the first send.
That framing survives a bounce. A promise that everything is valid does not.
The numbers worth writing down
Record the pass rate per source, the number of hard bounces in the first send, and how many replies came back. Three numbers, one line per campaign.
After a few campaigns, the pattern tells you which source to buy from and which to stop using, without anyone having to argue about it in a meeting.
It also protects you: when a bounce spike happens, you can show that the list passed and the mailbox closed later.
The conversation to have before you send
Agree what a bounce means for the campaign before the first message goes out. If nobody has decided whether a hard bounce halts the batch, someone will decide it in the moment, badly.
Agree who removes the address, where the suppression list lives, and how the next import is checked against it. Those three answers prevent the complaint that ends a sending domain's useful life.
What good looks like after a month
You have a pass rate per source, a bounce count per campaign, and a shortlist of sources you trust. The arguments about data quality turn into a number.
Nobody has to defend the list in a meeting, because the record already did.
A five-minute habit that prevents most damage
Before any batch, open the first twenty rows of the export and read them. If the names, companies and titles look plausible together, send; if not, stop and fix the segment.
This habit catches the mistakes verification cannot: wrong category, wrong seniority, a list built from a competitor's customer base. It costs five minutes and prevents most of the complaints a cold outreach programme receives.
What each check proves
| Check | Removes | Does not prove |
|---|---|---|
| Syntax | Typos and copy artefacts | That the domain exists |
| DNS | Dead domains | That the mailbox exists |
| Mail exchanger | Domains that refuse mail | That a person reads it |
| Mailbox probe | Refused recipients | Consent or interest |
Catch-all domains accept mail for addresses that may not exist.
Verification pass
- Export the list with a source column
- Deduplicate first
- Run syntax and DNS checks
- Check mail exchangers
- Flag disposable and role addresses
- Keep the pass result per row
- Send a small sample before the batch
A worked example, hypothetical
A list of 1,000 rows from three sources loses 120 to syntax and 180 to dead domains. The licensed-source rows survive at nearly twice the rate of the scraped ones, which changes where the team spends next month's collection effort.
They send 50 from the strongest segment first and remove four hard bounces same-day. The remaining 700 wait until the segment proves clean.
- 1.Deduplicate
- 2.Syntax
- 3.DNS
- 4.Mail exchanger
- 5.Sample send
What this will not do
- A verification pass is a snapshot in time.
- Catch-all and role addresses remain uncertain.
- Verification never substitutes for a lawful basis.
Questions people ask about this
How often should a list be re-verified?
Before every campaign that uses it. Mailboxes and domains change constantly, and an old pass is only a record of what was true then.
Should I keep addresses that fail verification?
Keep them flagged in a separate segment if you have a reason, but do not include them in a send. Resending to known failures is how domains lose reputation.
Does a failed mailbox probe mean the person is gone?
No. Servers refuse probes for policy reasons. Treat a refusal as a reason not to send, not as proof about the person.
Do I need to verify addresses I collected myself?
Yes. A contact page can be outdated, and a form submission does not guarantee the mailbox still exists. Verification is cheap compared with a bounce.
Should verification block a send?
A failed technical check should. A domain-level uncertainty is a judgement call you should record, not a silent pass.