How to verify a B2B email before outreach
What email verification actually checks, the four result states that matter (verified, catch-all, invalid, unknown) and how each should be priced and handled.
Verifying a B2B email before outreach means asking the receiving infrastructure whether the address can take mail: format and domain checks first, then an SMTP-level mailbox probe, then a catch-all test that tells you how much weight the probe answer actually carries. The output is not a yes/no; it is one of four states (verified, catch-all, invalid, or unknown), and honest tooling prices and labels each one differently.
"Verified" is the most load-bearing word in B2B contact tooling, and the least defined. This guide covers what a verification pass can and cannot check, what the result states mean in practice, and how to handle each one, including how CitedLeads charges for them.
What a verification pass actually checks
A business-email verification pass typically combines several signals:
- Format and domain checks: the address is well-formed and the domain accepts mail at all. Cheap, fast, and catches typos rather than dead inboxes.
- Mailbox existence: an SMTP-level probe asks the receiving server whether the mailbox exists, without sending a message. This is the core check, and it is exactly as reliable as the receiving server allows it to be.
- Catch-all detection: some domains accept mail to any address, so a "deliverable" probe response proves nothing about the person. Detecting that configuration is a separate check with a separate meaning.
- Recency: when the record was last confirmed, and against which source. A verification from eighteen months ago is a historical fact, not a current one.
What verification cannot check: intent, attention, or whether the person reads what lands. It is a deliverability claim: a statement about the mailbox, not about the human. Vendors that blur that line are selling past their evidence.
The four result states, and what they should cost
The useful way to read verification output is as a state, not a score:
| State | What it means | CitedLeads handling |
|---|---|---|
| Verified | The provider path confirmed the mailbox at reveal time | Charged: 1 credit |
| Catch-all (accept-all) | The domain accepts everything; the address was returned but the probe cannot distinguish real mailboxes from invented ones | Charged when an email is returned; flagged lower-confidence, never marked verified |
| Invalid | The server rejected the mailbox, or the address failed format/domain checks | 0 credits |
| Unknown / miss | The server would not answer definitively (greylisting, timeouts, protective mail gateways), or no email was found | 0 credits |
Two details in that table carry the whole honesty argument.
Catch-alls are charged when they return an email, and flagged, not disguised. A catch-all response means the server said "yes" to an address it would say "yes" to regardless. That is a real deliverable (you have an address the domain will accept), but it is a lower-confidence one, and it deserves a flag rather than a green checkmark. A tool that reports catch-alls as verified is not lying about the probe result; it is lying about what the result means.
Misses and unknowns cost nothing. If the provider path cannot return a usable email (invalid, unknown, or simply not found), the charge should not happen. Under a verified-reveal meter, the cost of bad data sits with the vendor, which is where it belongs: the vendor is the party in a position to reduce it.
Why catch-all domains are the quiet failure mode
A large share of B2B domains are configured to accept mail to anything, sometimes as a spam-management choice, sometimes as a default nobody turned off. Every one of them will happily confirm ceo@, wrong-name@, and this-address-was-invented@ alike.
The practical consequence: a list's measured "verification rate" can be inflated by catch-all domains without a single real mailbox being confirmed. When you audit a vendor or a list, ask for the catch-all share; a verification rate that does not exclude or flag catch-alls is marketing, not measurement.
In CitedLeads, catch-all results come back labeled lower-confidence on the brief. You can still write to them (many catch-all addresses are real), but you should know which contacts carry that flag before you stake sender reputation on them.
Verify at the moment of spend, not on a schedule
There are two places verification can live in a pipeline:
- A field on the record: verified at some point in the past, decaying ever since. People leave jobs; domains change configuration; a six-month-old green checkmark is a guess wearing a badge.
- At the moment of reveal: the provider path checks when you actually spend the credit, so the answer reflects now, not whenever the database was last refreshed.
CitedLeads verifies at reveal: the credit moves only when the provider path returns an email, and it stays in your balance when it does not. If a verified contact later hard-bounces anyway (verification is a moment-in-time claim, and moments pass), report it and support credits the reveal back manually; the adjustment lands in the same append-only ledger as the spend.
Working the states in practice
- Verified: safe to write to. Still warm it into your sequence like any contact; verification says the mailbox exists, not that it wants email.
- Catch-all: usable but flagged. Prioritize verified contacts; treat catch-alls as a second tranche, watch their bounce rate separately, and do not let a catch-all-heavy list carry a campaign.
- Invalid: dead. If the brief still matches your ICP, keep it on monitoring; a re-check costs 0 credits, and job changes sometimes revive a record.
- Unknown: unresolved, not dead. Re-checks are 0 credits; retry on a cadence rather than discarding.
What to ask any verification vendor
- What does "verified" mean concretely: mailbox probe, provider confirmation, or a confidence score wearing the word?
- How are catch-all domains reported: flagged as a distinct state, or silently marked deliverable?
- Does a miss consume the credit?
- When did verification happen: at reveal, or at some point before you bought the record?
- Is there a bounce remedy, and is it automatic or a support process? In CitedLeads it is a manual credit-back via support, printed that way on purpose, so the ledger records every adjustment.
FAQ
Is a catch-all email safe to send to? It is a real address the domain will accept, but the probe cannot confirm the mailbox exists. Sendable, lower-confidence, worth flagging rather than trusting. Segment them and watch their bounce rate separately.
Why does verification fail on real addresses? Greylisting, rate-limited probes, and protective mail gateways can make a live mailbox unanswerable; that is the "unknown" state. It is a property of the receiving server, not necessarily of the address.
Does a verified badge guarantee delivery? No, and nothing does. Verification is a deliverability claim about a moment in time; people leave jobs and domains reconfigure. Monitored re-verification at 0 credits is how a list stays honest after the reveal.
What happens when a verified contact bounces? Report it through the contact page; support credits the reveal back manually. There is no automatic refund path; adjustments are ledger entries you can audit.
Is email verification the same as enrichment? No. Verification asks "does this mailbox take mail"; enrichment adds fields to a record. CitedLeads verifies contact fields at reveal; it does not sell bulk-enriched databases.