B2B contact verification: what it means, who pays
What contact verification actually checks, where catch-all domains break the model, and how credit-per-lookup pricing shifts bad-data cost onto buyers.
B2B contact verification is a deliverability check: it asks whether an address is well-formed, whether the domain accepts mail, whether the specific mailbox exists according to an SMTP-level probe, whether the domain is catch-all, and how recently any of that was confirmed. It is a claim about the mailbox, not about intent, attention, or whether the person reads what lands.
"Verified" is the most load-bearing word in B2B contact tooling, and the least defined. Different vendors mean different things by it, and the pricing model determines who pays when verification fails. This page is a category explainer: what verification can and cannot check, where it breaks, and how the money flows under each pricing model.
What verification can check
A business-email verification pass typically combines several signals:
- Format and domain checks: the address is well-formed and the domain accepts mail.
- Mailbox existence: an SMTP-level probe asks the receiving server whether the mailbox exists, without sending a message.
- Catch-all detection: some domains accept mail to any address; a "deliverable" response there proves nothing about the person.
- Recency: when the record was last confirmed, and against which source.
What verification cannot check: intent, attention, or whether the person reads what lands. Verification is a deliverability claim, not a performance promise; vendors that blur that line are selling past their evidence. For the operational version (the four result states and how to handle each), see how to verify a B2B email before outreach.
The catch-all problem
Catch-all domains are the quiet failure mode of the category. A large share of B2B domains are configured to accept everything, so a mailbox check returns "deliverable" for addresses that were never real. A tool that reports these as verified is not lying about the probe result; it is lying about what the result means.
The honest handling is a distinct state, not a pass. In CitedLeads, catch-all results come back flagged as lower-confidence. A reveal that returns an email is charged like any delivered reveal; what we never do is mark a shrug from the server as "verified." When auditing a vendor, ask for the catch-all share of their verified numbers: a verification rate that does not break it out is measuring the probe, not the mailbox.
Verification timing: when "verified" was true matters
Verification is a moment-in-time claim. Two placements exist in the market:
- Verified at record time: the status is a field on a record checked at some point before you bought it. Job changes and domain reconfigurations decay it from the moment it is stamped.
- Verified at reveal time: the check happens when you spend, so the answer reflects now.
Neither placement guarantees delivery (nothing does), but the timing changes what a green badge is worth. A verified field on a database record is evidence about the past; a verified reveal is evidence about the present.
How pricing models distribute the cost of bad data
Verification quality is an economic question as much as a technical one. Three common arrangements:
| Model | Who pays for a miss | Buyer exposure |
|---|---|---|
| Pay-per-lookup | The buyer: the lookup consumed the credit regardless of outcome | Real cost = sticker price ÷ hit rate |
| Verification as a second meter | The buyer, twice: once to reveal, once to check | Verification spend grows with distrust of the data |
| Verified-reveal only | The vendor: no verified outcome, no charge | Misses cost 0 credits |
CitedLeads uses the third model. 1 credit = 1 verified, cited contact reveal; misses, invalids, unknowns, re-checks, and monitoring refreshes consume 0 credits. If a verified contact later bounces, report it and support credits the reveal back: a manual adjustment in the ledger, not an automatic refund path. The vendor absorbs the cost of bad data, which is exactly where that cost belongs, since the vendor is the one in a position to reduce it.
The middle row deserves a beat: charging separately to verify the vendor's own data means the buyer's verification spend scales with their distrust, a model where worse data produces more revenue.
How the main tools line up
| Verification role | Meter shape | |
|---|---|---|
| CitedLeads | Priced into the reveal, at reveal time; catch-alls flagged | One meter: misses cost 0 |
| Hunter.io | Standalone verification product + status on lookups | Separate search and verification quotas |
| Apollo.io | Status fields on records within a multi-meter platform | Several meters by action type |
None of these is uniformly "best"; they are different allocations of the bad-data risk. The right question for your buying math is which party holds it. For the audit metrics, see lead list quality metrics.
What to ask a 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?
- When did verification happen? At the moment you spend, or at some point before the record reached you?
- Does a miss consume the credit? The answer tells you who holds the bad-data risk.
- Is there a bounce remedy? Automatic, a support process, or a policy page with no mechanism? CitedLeads' version is a manual credit-back via support, printed, and recorded in the ledger.
- Can you audit the spend? A visible, append-only ledger turns "trust us" into a record you can check.
Where CitedLeads sits
CitedLeads verifies at the moment of reveal through licensed provider adapters, flags catch-alls as lower-confidence rather than verified, credits back proven bounces when you report them, and logs every credit event to a ledger you can inspect. The product is in early access (it runs on synthetic demo data while provider contracts clear), so today these are the printed rules the product is built around, verifiable on the pricing and trust pages, rather than measured production statistics. To get on the list, use the contact page.
FAQ
Is a "verified" badge on a database record trustworthy? It is a claim about when the record was last checked, which may be months old. Ask when verification happened, not whether it happened.
What is a catch-all domain? A domain configured to accept mail to any address. Mailbox probes return "deliverable" for real and invented addresses alike: a distinct result state that honest tools flag rather than mark verified.
Are catch-all emails charged in CitedLeads? Yes. A reveal that returns an email is charged like any delivered email, and the result carries a lower-confidence flag. Misses, invalids, and unknowns cost 0.
Who should pay for bad data: buyer or vendor? Whichever party can reduce it. Verification-pricing that charges buyers per attempt makes bad data the vendor's revenue; verified-reveal pricing makes it the vendor's cost.
Does verification guarantee my email lands? No. Verification is a deliverability claim about a moment in time, not a promise about placement, attention, or intent.