Email verification is the process of confirming an address is real and able to receive mail before it gets sent to, catching invalid or dead addresses that would otherwise show up as bounces and damage sender reputation.
Verification runs a real check against an address, not just a format check for an @ sign and a domain. But the state changes over time. Contact lists decay continuously, not on a schedule: people change jobs, mailboxes get deprecated, role accounts get retired, and an address that verified cleanly two months ago can bounce today. Pre-send verification catches that drift before it shows up as a bounce, instead of after.
A provider can mark an address verified because it checked the mailbox months ago and nothing since forced a recheck. That's a different claim than a check that ran this week, against this exact send. If a stack can't say which one it's looking at, it's trusting a word instead of a result. Worth asking directly: does a verified flag mean this address got rechecked on the current pass, or is it carried forward from whenever a provider first touched it?
Verification is a separate job from enrichment even when the same vendor sells both. FindyMail and BetterContact both run this step well, and the number that matters isn't a headline match rate. It's the bounce rate, tracked over time, on the specific sends this layer touched. Match rate measures how often the tool finds something. Bounce rate measures whether what it found was actually real.
Verification runs on every batch before it sends, not just once at list import, and that matters more the more sources feed a list. Pulling contacts through a waterfall across several enrichment providers means verification is the step that catches whatever staleness each individual source introduced before it ever reaches a sending domain's reputation.
Verification and enrichment get treated as the same step because one vendor happens to sell both, but they answer different questions. Enrichment finds an email. Verification confirms it's still real right now. The other mistake is treating a verified tag as permanent, when it's really a claim with a shelf life that depends on when the check actually ran.
Tell us how your motion runs today. We'll show you what we'd engineer.
Contact us