Contact data decays at roughly 2–3% per month. At that rate, a 10,000-contact list loses 240–360 valid addresses every quarter—before you've sent a single email. Verification is how you stop paying for bounces you could have prevented. Done at scale, it requires more than a single API call; it requires a layered architecture that distinguishes truly invalid addresses from catch-all domains, applies the right verification method at the right stage of your workflow, and re-certifies records before they age past acceptable thresholds. This guide covers the full technical stack: verification methods, vendor trade-offs, domain-handling strategies, batch versus real-time trade-offs, cost modeling, bounce-rate targets by mailbox provider, and re-verification cadence.
- Google/Gmail: keep hard-bounce rate below 0.08%; above 0.10% triggers deliverability restrictions.
- Microsoft/Outlook: informal threshold is around 2%, but reputation damage begins well below that.
- Best-practice operational target: <2% hard-bounce rate across all sends.
- Catch-all domains account for 15–35% of B2B contact lists; mishandling them is the #1 source of unexpected bounce spikes.
The three verification methods and when each applies
Not all verification is created equal. Each method has a different accuracy ceiling and a different cost structure.
SMTP verification
SMTP verification opens a connection to the recipient's mail server—using the same handshake your sending infrastructure uses—and checks whether the server accepts the address without actually delivering a message. The sequence is: DNS lookup → MX record resolution → SMTP EHLO → RCPT TO probe → server response parsing.
Accuracy ceiling: High for standard mailboxes. SMTP verification can reliably confirm whether an address exists on a correctly configured mail server.
Limitations: A growing percentage of enterprise mail servers block or throttle SMTP probes to prevent exactly this kind of list cleaning. Microsoft 365 tenants and Google Workspace organizations increasingly return 250 OK responses regardless of whether the mailbox exists—making raw SMTP verification unreliable for those domains without additional layering.
When to use it: Best suited for smaller, targeted lists where you have time to probe slowly, or as one signal in a multi-method pipeline rather than as the sole determinant.
Catch-all detection
A catch-all domain is configured to accept email for any address at that domain—anything@company.com will return a 250 OK even if the specific mailbox doesn't exist. This is common in enterprise environments (estimated 30–45% of Fortune 1000 domains) and makes naive SMTP probing nearly useless for those addresses.
Catch-all detection identifies these domains during the verification pass and classifies the addresses separately rather than marking them as "valid." From there you have three practical paths:
- Accept and suppress: Mark catch-all addresses as "risky" and exclude them from cold sequences. Cleanest approach if you have enough volume that losing 15–25% of your list doesn't crater reply counts.
- Accept and throttle: Include catch-all addresses in sends but monitor bounce rates per domain cluster. Cap daily volume to those domains and kill sends if bounce rate on that cluster exceeds your threshold.
- Accept and sample: Send a single low-stakes touchpoint to a sample of catch-all addresses per domain, track actual delivery behavior, and use that signal to calibrate how aggressively to suppress the full set.
The third approach—sampling—is the most data-efficient. Over a few months it builds a domain-level deliverability model that's more accurate than any static vendor classification.
API-based verification
API-based verification layers proprietary data on top of SMTP probing: real-time delivery records from partner networks, historical bounce data from shared infrastructure, machine-learning models trained on millions of prior verification outcomes. The top vendors—ZeroBounce, NeverBounce, Kickbox, MillionVerifier—all operate in this space.
Why it matters for catch-alls: Vendors with broad sending partner networks can often distinguish between a catch-all address that has actually received mail before and one that has never had a genuine delivery. That historical delivery signal is something pure SMTP probing can never produce.
Vendor comparison: ZeroBounce, NeverBounce, Kickbox, MillionVerifier
All four vendors return a classification—typically valid / invalid / catch-all / unknown / disposable / abuse / do-not-mail—but they differ meaningfully in accuracy on edge cases, catch-all handling, real-time API performance, and pricing structure.
| Vendor | Catch-all handling | Batch pricing (per 1K) | Real-time API latency | Best fit |
|---|---|---|---|---|
| ZeroBounce | Separate classification + AI-scored sub-status | ~$0.80–$1.00 | 300–600ms avg | Lists with high catch-all density; best additional-data coverage (name, geo, gender inference) |
| NeverBounce | Catch-all flagged, no sub-scoring | ~$0.30–$0.80 | 200–400ms avg | High-volume batch workflows; clean API with good CRM integration library |
| Kickbox | Catch-all flagged + Sendex confidence score (0–1) | ~$0.50–$1.00 | 250–500ms avg | Decision-making workflows that need a numeric confidence score rather than a binary result |
| MillionVerifier | Basic catch-all flag | ~$0.10–$0.30 | 400–800ms avg | Cost-sensitive bulk cleanup of cold databases; lower accuracy ceiling on ambiguous addresses |
Practical recommendation: Run a dual-vendor approach for new lists. Use MillionVerifier for the initial pass to remove obvious invalids cheaply, then run the remaining "risky" and "unknown" addresses through Kickbox or ZeroBounce for higher-confidence classification. Total blended cost drops to $0.20–$0.40 per verified address at scale while preserving accuracy on edge cases.
Verification timing: verify-on-enrich vs. verify-before-send
The question of when to verify is as important as how.
Verify-on-enrich
Contacts are verified at the moment they enter your database—typically as part of an enrichment pipeline run against a prospect list. The advantage is that your CRM always reflects current validity status. The disadvantage is that you're paying to verify contacts you may never contact, and addresses verified 90+ days ago may have changed state by the time you send.
When to use it: Justified when your ICP list is stable and your time-to-first-touch is short (under 30 days). Also appropriate when downstream systems (scoring, routing, nurture enrollment) depend on verified status to make decisions.
Verify-before-send
Contacts are verified in a batch run 24–72 hours before a campaign launches. You only pay to verify addresses you actually intend to use, and the verification reflects current state rather than state from months ago.
When to use it: Best for large-volume campaigns where a meaningful percentage of your list has been sitting for 60+ days. Also the right pattern when you're pulling contacts from a legacy database that wasn't verified at ingestion.
The operational tension: Real-time verification at send time (verifying each address as the email is queued) adds latency to your sending infrastructure and creates dependencies on vendor uptime. Batch verification 48 hours prior is the most common production pattern for outbound campaigns above 5,000 contacts.
Verify-on-enrich for ICP accounts you expect to contact within 30 days. Verify-before-send for any list segment that has aged more than 60 days since last verification. Re-verify everything on a 90-day rolling cadence regardless of prior status.
Batch vs. real-time verification
Batch verification
Upload a CSV or trigger an API job; get results back in seconds to minutes depending on list size and vendor. Most vendors process 100K records in under 10 minutes. Cost is lowest in batch mode. The tradeoff is that contacts verified in a batch run may already be stale by the time they're used.
Throughput benchmarks: Expect 10,000–50,000 verifications per minute from major vendors in batch mode. For lists under 500K, batch verification adds negligible time to your campaign-prep workflow.
Real-time verification
Used at two points: inbound form validation (block or warn on invalid/risky emails before the record is created) and point-of-send validation within an outbound platform. Real-time verification at the form level is high-ROI—it prevents dirty data from entering your system in the first place.
Latency requirements: Real-time API calls need to complete in under 1 second to avoid degrading form UX. ZeroBounce and NeverBounce both meet this threshold for valid addresses; catch-all resolution may take longer.
Do not use real-time verification as the sole gate at send time. If the vendor API is degraded, you either block all sends or bypass verification—neither is acceptable. Real-time send-time verification works as an additional layer on top of prior batch verification, not as a replacement.
Cost per verification across vendors at scale
At 100K verifications per month:
- MillionVerifier: ~$20–$30
- NeverBounce: ~$50–$80
- Kickbox: ~$60–$100
- ZeroBounce: ~$80–$100
At 1M verifications per month, all vendors offer volume pricing. ZeroBounce and Kickbox both have enterprise tiers that reduce per-verification cost significantly—negotiate directly.
The correct framing is not "cost per verification" but cost per prevented bounce. If your unverified list has a 5% hard-bounce rate and you're sending 50,000 emails per month, you're generating 2,500 hard bounces. At $0.10 per contact-record replacement plus the deliverability reputation cost of those bounces, the true cost is orders of magnitude higher than verification fees.
Acceptable bounce rate thresholds by mailbox provider
| Provider | Published threshold | Practical ceiling | Consequence of breach |
|---|---|---|---|
| Google / Gmail | 0.10% hard bounce | Stay below 0.08% to avoid risk zone | Sender restrictions; bulk mail deferral or rejection |
| Microsoft / Outlook.com | Not formally published | Industry consensus ~2%, reputation damage starts earlier | Filtering, deferral, eventual block listing |
| Yahoo / AOL | Not formally published | Similar to Microsoft; watch complaint rate as leading indicator | Bulk folder placement, potential block |
| Corporate / self-hosted | Varies by admin policy | Hard to generalize; monitor per-domain bounce clustering | Domain-level block by IT team |
The practical operational target across all sends is under 2% hard bounce rate, which provides meaningful safety margin against the Gmail threshold and generally preserves reputation with other providers. For campaigns targeting Google Workspace heavy industries (tech, startups), target under 0.5%.
Re-verification cadence for aging lists
Email addresses do not maintain their state indefinitely. Role-based addresses (info@, sales@, support@) change hands frequently. People change jobs—B2B contact data has an estimated 30% annual turnover from job changes alone.
Recommended cadence:
- 90-day re-verification: Any contact that hasn't been sent to in 90 days should be re-verified before re-engagement. This catches the highest-churn segment.
- 180-day hard cutoff: Contacts unverified for more than 180 days should be treated as unverified regardless of prior status. Re-verify before any send.
- Post-campaign hygiene: After each campaign, immediately suppress hard bounces and remove them from your master list. Do not retry hard bounces in subsequent campaigns.
- Soft bounce monitoring: Three or more consecutive soft bounces on the same address is a strong signal of a defunct mailbox. Move to re-verification queue, not immediate suppression.
For lists acquired from third-party sources or built from scraped data, run verification before any import—not after. The cost of cleaning dirty data downstream (suppression list updates, CRM record correction, bounce-triggered deliverability damage) vastly exceeds the cost of pre-import verification.
Verify at ingestion
Run API verification as part of every enrichment pipeline. Gate CRM import on verification status.
Verify before send
Batch re-verify any segment older than 60 days, 24–72 hours before campaign launch.
Suppress and audit
Immediately suppress hard bounces. Flag soft-bounce clusters for re-verification within 7 days.
90-day re-certification
Any contact not sent to in 90 days returns to "unverified" status and must be re-run before re-engagement.
Connecting verification to your broader data quality stack
Verification is one layer of a broader data quality architecture. It answers "is this address deliverable?" but not "is this the right person at the right company with the right title?" Those questions require enrichment.
The correct sequencing is: enrich first (fill in firmographic and contact data), then verify (confirm the email is deliverable), then score and route. Running verification before enrichment means you may discard addresses that would have been confirmed valid after domain correction or contact deduplication.
If you're running a multi-vendor waterfall enrichment pipeline, integrate verification as a post-waterfall step—after all enrichment sources have had a chance to contribute a contact record—rather than verifying at each individual waterfall stage.
FAQ
What's the difference between a hard bounce and a soft bounce for verification purposes?
A hard bounce (SMTP 5xx response) indicates permanent rejection: the address doesn't exist, the domain doesn't accept mail, or the server has permanently blocked your IP. A soft bounce (SMTP 4xx) is a temporary failure: the mailbox is full, the server is unavailable, or rate limits are in effect. Verification vendors classify addresses based on expected delivery behavior, not on a specific bounce event. Hard-bounce addresses should be suppressed immediately; soft-bounce addresses warrant re-verification after a short delay before suppression.
Should we verify addresses purchased from data vendors?
Always. Even reputable data vendors have verification data that is weeks to months old by the time you receive it. Run your own verification pass against any purchased list before it touches your sending infrastructure. This is also a useful benchmark for evaluating vendor data quality—high hard-bounce rates on freshly delivered data are a signal to renegotiate or switch vendors.
How do we handle addresses that consistently classify as "unknown"?
Unknown addresses are ones where verification couldn't reach a conclusion—the server timed out, the probe was blocked, or the response was ambiguous. The safest approach is to treat unknowns the same as catch-alls: exclude from cold outbound, or include only in low-volume campaigns with close bounce monitoring. Running unknown addresses through a second vendor often produces a classification the first vendor couldn't reach.
Does email verification help with spam complaint rates?
Indirectly. Verification reduces bounces, which prevents one class of deliverability damage. Spam complaints are driven by sending irrelevant content to people who didn't opt in or have forgotten they did—verification doesn't address that. You need targeting precision and message relevance to keep complaint rates low. Verification is necessary but not sufficient for inbox placement.
What bounce rate should we target for cold outbound specifically?
Cold outbound campaigns should target under 1% hard bounce rate, not the 2% ceiling. Google's 0.08% threshold applies to complaint rates, but their hard-bounce guidance is also strict. For cold campaigns hitting Google Workspace domains heavily, run verification within 48 hours of send and target under 0.5%. The tighter target gives you headroom if your data quality degrades faster than expected between verification and send.
Contact verification at scale is infrastructure, not a one-time cleanup project. The teams that maintain sub-2% bounce rates aren't doing anything exotic—they've built verification into every stage of their data lifecycle: at ingestion, before each campaign, and on a rolling cadence for aging records. The cost is measurable and predictable. The alternative—uncontrolled bounce rates that trigger mailbox provider restrictions—is both unpredictable and significantly more expensive.
If you're auditing your current verification architecture or building it from scratch, our data enrichment service includes verification pipeline design as a core component. To assess your current sending infrastructure's deliverability health before optimizing your verification stack, start with our free deliverability checker.
Ready to build a verification architecture that keeps your bounce rates below 2%? Talk to our team.
