The business story
Why this system exists
Loading a raw account list straight into a sending tool and letting its built-in verifier sort it out is how deliverability dies quietly. Two failure modes hide inside "verified" lists: domains with no mail exchange at all (typos, dead companies), and domains that run catch-all — they accept mail for literally any address, so a per-mailbox verifier reports every guess as valid. On a real 147-contact India list I worked, 41 contacts — 28% — turned out to be catch-all domains once checked this way.
What I actually built and ran
A segment-before-load discipline applied to every outbound list, across markets: check MX before anything else, flag known catch-all-by-default providers, and hold that cohort out of the send rather than trusting a verification tool that cannot actually tell a real inbox from a typo on those domains. The clean cohort ships first; the held cohort gets a human decision, not a guess.
The judgment calls
- Segment before loading, every time, no exceptions. The discipline only works if it's the first gate, not a cleanup pass after a bounce spike.
- Catch-all is a hold, not a guess. No verification tool at any price can distinguish a real inbox from a typo on a domain that accepts everything — the honest answer is "hold for a human," not a confidence score.
- "Invalid" needs a reason, not just a flag. A domain that does not exist (NXDOMAIN), a domain with no mail setup, a name that can't be queried, and a resolver that couldn't be reached look identical in a spreadsheet — but one is permanent, one is fixable, one is a typo, and one might be transient.
What went wrong before this was standard practice
Before this became a mandatory first gate, verified-seeming lists shipped with catch-all domains blended in, inflating apparent list quality while quietly capping deliverability — a sending tool has no way to tell you it just spent a send on a domain that would have accepted the wrong address just as happily.
What I'd change today
The catch-all provider list here is a short, known-pattern set. A production version should also flag domains whose MX changed recently (a signal a company just moved providers and old contacts may bounce) and track false-positive/negative rates against real send outcomes over time.