In this post:
Contact verification is the check that a contact's email address, phone number and job are still real and current before anyone on your team reaches out to them.
It sounds like admin, and most teams treat it that way. The catch is that bad contact data never announces itself. An export from a data provider looks just as tidy when a fifth of it is dead as when none of it is, and you only learn which one you bought when the bounces come back and your sending domain absorbs the damage.
Where it usually goes wrong is scope and timing. Teams check the email once, at import, and treat the green tick as permanent. An email check says nothing about whether the person still works there, and a check from March tells you very little about a list you send in September.
TL;DR
Email checks run in a fixed order: syntax, then the domain and its MX records, then a mailbox check that talks to the recipient's mail server without sending anything. Catch-all domains and servers that hide the answer come back as unknown, which is not the same as valid.
A good verification pass gives every record a verdict (valid, invalid, risky or departed) instead of a vague sense that the list looks fine. Only the valid and current group goes straight into a sequence.
Email validation covers one field. Contact verification also covers the phone number, the job title and whether the person still works at the company, because a working inbox for someone who left six months ago reaches nobody.
Lists go stale between checks because people change jobs and companies merge, rebrand or close. Every bounce from a stale list counts against your sender reputation, which then affects all your mail, including the sends to good contacts.
Act on each verdict differently: delete invalids, suppress spam traps and known complainers, send catch-all addresses separately in small batches, swap role addresses like info@ for a named person, and re-check unknowns before deciding.
Verify in bulk when you build a list and again just before launch, and wire the check into your Clay table or enrichment flow so it runs on every new record without anyone remembering to do it. Phone numbers and job titles need the same habit, checked and re-enriched before each campaign.
What a verifier does when it checks an email address
Email verification tools all follow roughly the same sequence. Knowing the steps helps you read the results, and it explains why some addresses can never get a clean yes.
Syntax. The tool checks that the address is formatted correctly. This catches typos and broken imports instantly.
Domain and MX records. It looks up whether the domain exists and publishes MX records saying which servers accept its mail. This part is often called MX validation, and it catches dead and misspelled company domains.
Mailbox check. The tool opens a conversation with the recipient's mail server, names the address as a recipient and disconnects before any message is sent. If the server rejects that recipient, the mailbox doesn't exist.
Risk flags. Addresses that exist can still cause trouble. The tool flags catch-all domains, known spam traps, disposable addresses and role-based addresses like info@ or sales@.
Person check. Better setups then confirm the human: is this person still at this company in this role? That needs fresh data from an enrichment source or a profile lookup, not a mail server.
Why some addresses come back unknown
The mailbox check depends on the receiving server giving a straight answer, and plenty don't. The SMTP standard itself, RFC 5321, notes that some servers don't verify recipients until after the message text has arrived. Others are set up as catch-all domains that accept every address so they never leak which mailboxes are real.
ZeroBounce's documentation is blunt about catch-all addresses: they can't be validated without sending a real email and waiting for a bounce. So a catch-all result means the tool couldn't find out. Treat it that way.
Role-based addresses are a different problem. They're real, and RFC 2142 even standardizes names like INFO, SALES and SUPPORT for reaching parts of an organization. But they belong to a function, not a person, so they tend to land with whoever triages a shared inbox, and that person is far more likely to hit the spam button than to book a meeting.
Four records from one "clean" list, run through those checks
Here is what that looks like on real data. These four rows came from a list that looked perfect in the spreadsheet: names filled in, titles filled in, every email in a sensible format.
Sofia, a VP of Operations, passes everything. Her mailbox exists, she still holds the role, and the company details match. She's the only one of the four you'd load into a sequence without a second thought.
Jan is the sneaky one. His email at his old employer still accepts mail, so a basic email check passes it. He left six months ago, though, and whoever reads that inbox now (if anyone does) isn't going to reply to a message about growth tooling. No bounce comes back to warn you, so this kind of record can sit in your CRM for years.
Amira's mailbox no longer exists. Send to her and you get a hard bounce, which mailbox providers read as a sign that you don't look after your data.
Tom's address is info@ on a domain that accepts mail for any address. It might reach a shared inbox, it might reach nobody, and the verifier can't tell you which. That's a risky verdict, not a valid one.
One list, four different answers. The point of contact verification is to get those answers before you send, while they're still cheap.
Email validation checks an address. Contact verification checks a person
The two terms get used interchangeably, and they shouldn't be. Email validation answers one question: can this address receive mail? Format, domain, mailbox, risk flags. That's steps one to four above.
Contact verification includes all of that and adds the rest of the record. Is the phone number live, does the person still hold the title you have on file, are they still at the company at all, and do the firmographic data attached to them (company size, industry, location) still hold? Your personalization is only as true as those fields.
Jan from the example is why the difference matters. His email passes validation. Only the wider check catches that he's gone. If you run outbound at any volume, a meaningful slice of your "valid" emails will belong to people like Jan, and email validation on its own will never show you which.
Why contact data goes stale between checks
A verified list is a snapshot. The moment the check finishes, the people on it carry on changing jobs, getting promoted and leaving.
Job changes do most of the damage. When someone leaves, their work email is usually switched off or redirected to a colleague, the title on your record stops being true, and nothing in your spreadsheet changes to tell you. Promotions and internal moves are quieter still, because the email keeps working while the role you're writing to has gone.
Companies change underneath the people too. An acquisition moves everyone to a new domain, a rebrand retires the old one, and a shutdown takes a whole set of contacts with it in one go. This is data decay, and it never pauses.
The cost lands in three places. Reps spend time on contacts who can't be reached. Invalid addresses push up your bounce rate. And those bounces wear down the sender reputation that decides your email deliverability for every message you send, including the ones going to perfectly good contacts. A new sending domain feels this fastest, because it has no history to cushion a bad first week.
What to do with each contact verification result
Verification tools don't return a simple pass or fail. They return categories, and each one calls for a different decision. Names vary by vendor, but this is how we handle the usual set.
Result | What it means | What we do with it |
|---|---|---|
Valid | The mailbox exists and accepted the check | Send, as long as the person check also passes |
Invalid | The server rejected the address | Remove it, then look for a new address through enrichment |
Catch-all or accept-all | The domain accepts everything, so the mailbox can't be confirmed | Send in a separate, small batch from a well-warmed inbox and watch bounces closely |
Role-based | A shared address like info@ or sales@ | Keep out of cold sequences and find a named person at the account instead |
Spam trap or known complainer | Flagged by the vendor as an address that hurts senders | Suppress permanently |
Disposable | A temporary inbox service | Suppress |
Unknown | The server didn't answer, often because it was offline or behind an anti-spam system | Re-check a few days later before deciding |
Two cautions. Spam trap detection is partial by nature, and ZeroBounce's own documentation says it knows many traps but not all of them. And a "valid" verdict only describes the mailbox, so a valid address still needs the person check before it goes anywhere near a sequence.
When to verify, and how to stop relying on people remembering
Bulk verification cleans a whole list in one pass. It's the efficient way to prepare a campaign, and it belongs inside list building itself, so bad records are caught before they ever reach your CRM or sequencer.
Real-time verification checks a contact at the moment it's used: when a form is submitted, when a record is created, or just before it enters a sequence. It's the freshest check you can get.
We use both. Bulk at build, then a second pass right before launch, and another whenever a list has sat unused for more than a few weeks. The second pass catches whatever decayed in between, and on older lists that's rarely nothing.
The setups that hold up are the ones where nobody has to remember any of this. In a Clay table, verification is just another column that runs on every new row. Paired with waterfall enrichment, it does more than flag bad addresses: when one provider's email fails the check, the next provider gets a chance to find a better one. That turns verification and data enrichment into one loop that finds, confirms and replaces.
Volume is what makes the automation non-negotiable. A small share of bad addresses across a few hundred sends is an annoyance. The same share across thousands of sends a week is enough to push your bounce rate into territory where providers start filtering you. Building the check into the systems that automate sales prospecting means every contact is verified before it's used, at whatever volume you run.
Phones and job titles need checks of their own
Email gets most of the attention because email bounces are visible. Phone data fails quietly: a number that rings out, reaches a switchboard or belongs to someone's previous employer just looks like a rep who isn't connecting.
Phone verification checks that a number is live and, ideally, whether it's a direct line or mobile rather than a main office number. That difference decides whether a cold call reaches the person. We cover the practical side in our guide to getting phone-ready leads.
Job data needs the same treatment. A title that was right when you enriched the record may be wrong after a promotion or a move, and your message will read oddly to someone who no longer does that job. Re-enriching titles before a campaign is the person-level version of re-verifying emails, and it's the step most teams skip.
Recap
A contact list only tells you who someone was when the data was collected. Contact verification is how you find out who is still there, still reachable and still in the job you're writing to, and it has to happen close enough to the send to mean something.
The mechanics are well understood. Mail servers will confirm or reject many mailboxes, catch-all domains can't be confirmed at all, and role addresses are real but rarely worth a cold email. The judgment sits in what you do with each answer, and in checking the person as well as the address.
Teams that get this right rarely talk about it, because nothing dramatic happens to them. Their bounce rates stay low, their domains stay healthy, and their reps spend the day on people who can reply. The top outbound experts treat it as a fixed step for that reason, and it sits quietly underneath any serious go-to-market system.
If you'd like that step built for you, we set up verification inside your own Clay and CRM, connected to enrichment and to the sequencer, and hand it over so it keeps running after we leave.
Frequently asked questions
Does contact verification slow down outreach?
Not in any way that matters. Verifying a list of a few thousand contacts usually takes minutes, and a check built into your enrichment table runs without anyone touching it. The slow path is skipping it: reps working dead contacts, bounce rates climbing, and weeks spent repairing a sending domain after one bad campaign. A short check before launch protects the speed of everything after it.
Does verifying an email address send an email to the contact?
No. A verifier connects to the recipient's mail server, asks whether it will accept mail for that address, and disconnects before any message is sent. The contact never sees anything. The exception is a catch-all domain, where the server accepts every address, so the only way to be sure is to send a real email and see whether it bounces, which verification tools deliberately avoid.
Is it safe to send cold email to catch-all addresses?
Sometimes, with care. Catch-all addresses are often real, but a verifier cannot confirm them, so some will bounce. Send them in a separate, small batch from a warmed inbox with a healthy reputation, and watch the bounce rate on that batch alone. If it climbs, stop and drop the rest. Never mix a large block of catch-all addresses into your main send from a new domain.
Why do emails that passed verification still bounce?
A few reasons. The mailbox may have been deleted after the check, which is common on lists that sat for weeks. Some servers accept the recipient during the check and reject the message later. Catch-all domains can pass a lenient tool and then bounce. And a full mailbox or a temporary server problem produces a soft bounce. Re-verifying close to send and treating catch-alls separately removes most of these.
Can an email verifier detect spam traps?
Only partly. Verification vendors keep lists of addresses they believe are spam traps and flag them, but nobody has a complete list, because the organizations running traps keep them secret on purpose. The better protection is where your data comes from. Traps tend to sit in scraped, bought or very old lists, so building lists from reputable sources and re-checking older data matters more than any single flag.
If a data provider says its emails are verified, do I still need to check them?
Yes. A provider's verified label describes the address at the moment the provider last checked it, which could be weeks or months before you download the list. It also rarely covers whether the person still holds the role. Run your own check when you build the list and again before launch. It costs little and catches whatever changed since the provider's last pass.
Should you verify contacts that are already in your CRM?
Yes, especially before a reactivation or win-back campaign. Records that have sat in a CRM for a year or more are full of people who changed jobs and companies that moved domains. Re-verify the emails, refresh job titles through enrichment, and mark the departed contacts rather than deleting them, because the person who left may now be a buyer somewhere else.
How do you verify a phone number before a cold call?
Use a phone validation service or an enrichment provider that reports whether a number is active and what type it is, such as mobile, direct dial or main switchboard. A live mobile or direct dial is worth calling. A switchboard means you will need a gatekeeper. Numbers flagged as inactive should be removed, and ones with no result should be re-sourced before a rep spends time on them.
How accurate are email verification tools?
They are reliable on clear cases, such as a mailbox that exists or a domain that does not. Accuracy drops on catch-all domains and on servers that block or delay the check, which is where tools disagree most. Before committing to one vendor, run the same sample of a few hundred contacts through two tools and compare how each handles the risky and unknown results.
Share this post
Verification
Data
Glossary
Related glossary items
Understanding the core GTM concepts
Ready to build your pipeline
