How to validate an email list before you send to it

Validation is a pipeline, not a single pass

Each check in a validation pipeline catches a different failure mode, and running them out of order wastes API calls on addresses you would have rejected anyway. The order that wastes the least effort is: syntax, domain, mailbox, risk classification, then activity.

Step 1: syntax and format

Reject anything that fails RFC 5321/5322 structure before you spend a lookup on it: missing @, illegal characters, consecutive dots, or a local part over 64 characters. This is free and instant - do it client-side at capture time, not just in a batch job later.

Step 2: domain-level checks

For every remaining address, resolve the domain's MX record. No MX record (and no A/AAAA record configured to accept mail) means nothing will ever be delivered there, full stop. This step also catches typo domains - gmial.com, yahooo.com - that syntax checking lets through because they are syntactically valid.

Step 3: mailbox-level verification

This is the step people call "email verification" and it is the most expensive and least reliable, because many mailbox providers (Gmail and Yahoo among them) don't give a clean answer to an SMTP RCPT TO probe for privacy and anti-harvesting reasons - they accept the connection and decide what to do with the mail at delivery time instead. Treat a "catch-all" or "unknown" result as medium risk, not as a pass.

Step 4: classify risk, don't just delete

A blunt "remove anything not 100% verified" approach throws away real subscribers who are on catch-all domains. Classify instead:

Spam traps are the real risk, not typos

A typo bounces and costs you nothing but a bounce rate tick. A spam trap accepts the mail silently and reports you to the receiving mailbox provider or a blocklist operator. There are three common trap types: pristine traps (addresses that were never real, seeded purely to catch harvesters or purchased lists), recycled traps (real addresses abandoned long enough that the provider repurposes them as traps), and typo traps (common misspellings of real domains, registered specifically to catch sloppy data entry). The second type is why "email collected 3+ years ago, never re-validated" is a real risk category even if it was clean when collected.

Step 5: activity and engagement checks

Addresses that are syntactically valid, on a real domain, and confirmed to exist can still be dead - no opens, no clicks, no replies in 6-12 months. For cold outreach specifically, treat "never replied across multiple campaigns" as a signal to pause that address, not keep retrying it; repeated sends to unengaged addresses are exactly the pattern that drags down sender reputation with mailbox providers that use engagement as a ranking signal.

What not to do

• Don't run validation once at list purchase and never again. Lists decay - a reasonable cadence is before every major send to a list that hasn't sent in 30+ days.
• Don't buy a list and assume a validation pass makes it safe to send to. Validation confirms the address exists; it says nothing about whether that person consented to hear from you, and consent is what actually drives complaint rate.
• Don't treat a soft bounce the same as a hard bounce. A soft bounce (mailbox full, server temporarily down) can retry; a hard bounce should be suppressed immediately and permanently.
• Don't validate and then send your entire corrected list at full volume on day one, especially from a mailbox that hasn't sent much before. Validation reduces risk; it doesn't replace ramping volume gradually.

Rebuilding trust after a bad send

If a list that wasn't properly validated has already gone out and produced a spike in bounces or complaints, stop sending to that list immediately rather than trying to push through it. Re-validate from scratch, remove every address that triggered a hard bounce or complaint, and resume at a reduced volume for several sends before returning to normal cadence - a mailbox's reputation recovers faster when it sees a clear, sustained improvement in signal than when it's given one clean send surrounded by dirty ones.

Where MailPilot fits

MailPilot doesn't run list validation itself, but the mailboxes you send validated lists from still need SPF, DKIM, and DMARC checked against what's actually being delivered, and a warm-up history that gives a provider a reason to trust a sudden volume increase. MailPilot tracks per-mailbox reputation daily and measures real per-provider inbox placement through a seed-inbox network, so you can see whether a cleaned list change actually moved placement, instead of guessing.