Forem: Zackrag

Apollo vs Hunter vs Lusha vs PDL: The Cost-Per-Contact Number Nobody Publishes (2026)

Zackrag — Tue, 21 Apr 2026 06:24:33 +0000

I ran Apollo.io, Hunter.io, Lusha, and People Data Labs against the same 450-contact test set last quarter. Every tool claimed 95%+ accuracy on their pricing pages. None of them hit it. The gap between advertised per-seat cost and what I actually paid per working contact ranged from 2x to 6x depending on the tool and tier.

Here's what the real math looks like — including PDL, which almost every comparison article skips entirely.

Why Sticker Price Is a Useless Comparison Point

Apollo.io Basic: $49/seat/month. Lusha Pro: $49/seat/month. Same price, done, right?

Not remotely. Apollo Basic gives you 75 credits/month. Lusha Pro gives you roughly 250 contacts/month — emails and phone numbers bundled per contact. And Apollo charges 8 credits for a single phone number. If you're pulling email + phone on every contact, Apollo's 75 monthly credits get you about 8 contacts with phones, not 75. Lusha's 250 contacts come with phones included.

That's before touching verification rates.

Then there's the rollover issue: Apollo credits expire at month end. Unused credits don't carry forward. If your team has two slow weeks and doesn't hit the quota, those credits vanish. Lusha and Hunter.io don't do this. It's a small line item that compounds into real money across a 10-person SDR team over a year.

The Metric That Should Drive This Decision

I started calculating cost-per-verified-contact instead of cost-per-exported-contact. The difference matters because a contact that bounces costs you sender reputation, not just money.

The formula:

cost_per_verified = monthly_spend / (contacts_exported × verified_delivery_rate)

If you spend $79/month, export 100 contacts, and 68 of those emails deliver without bouncing — your real cost-per-verified is $1.16, not the $0.79 the plan page suggests. That number changes the entire ranking.

How I Ran the Test

I pulled 450 unique LinkedIn profiles: 150 SaaS founders, 150 mid-market sales directors, 150 enterprise IT buyers across US and EU. I ran each profile through each tool's enrichment endpoint or browser extension, exported the contact data, and sent a plain-text email to each batch from a warmed domain. I measured:

Export rate: how many profiles returned any email at all
Verified delivery rate: hard bounce + soft bounce combined under 5% threshold
Phone fill rate: how many profiles returned a direct-dial number
Phone accuracy: sampled 100 phones per tool by calling them

I tested profile-by-profile lookups, not import-list enrichment, which is closer to how most SDR workflows actually run.

Pricing Reality Check

Tool	Plan	Monthly cost (annual)	Credits/contacts per month	Email unit cost	Phone unit cost
Apollo.io	Basic	$49/seat	75 credits	1 credit	8 credits
Apollo.io	Professional	$79/seat	"unlimited"*	1 credit	8 credits
Hunter.io	Starter	$49 flat	500 searches	~$0.10	N/A
Hunter.io	Growth	$149 flat	2,000 searches	~$0.07	N/A
Lusha	Pro	$49/seat	250 contacts	bundled	bundled
Lusha	Premium	$52/seat	600 contacts	bundled	bundled
RocketReach	Essential	$53 flat	125 lookups	bundled	bundled
RocketReach	Pro	$170 flat	400 lookups	bundled	bundled
PDL	Pro	$98 flat	350 enrichments	$0.28/match	$0.28/match
PDL	API (pay-as-you-go)	usage-based	per record	$0.01/record	$0.01/record

*Apollo "unlimited" covers business emails on Professional. Phone numbers remain credit-gated regardless of plan. Users report hitting soft limits around 300–400 phone reveals/month before support contacts them about "fair use."

Accuracy: What My 450-Contact Test Found

Tool	Export rate	Email verify rate	Phone fill rate	Phone accuracy (sampled)
Apollo.io	87%	71%	34%	68%
Hunter.io	74%	84%	—	—
Lusha	81%	79%	52%	74%
RocketReach	76%	76%	41%	63%
PDL raw API	91%	67%	29%	N/A†

†PDL returns unverified raw data. To get usable delivery rates you need to pipe the output through ZeroBounce or NeverBounce, which adds cost and latency.

A few things that surprised me:

Apollo.io's email accuracy collapsed for niche job titles. VP-level contacts at sub-100-person companies came back under 60% verified. The aggregate 71% is flattering because large companies dragged the average up.

Hunter.io's domain-pattern approach is genuinely reliable when company email formats are consistent — for Fortune 1000 targets, I hit 91% verify rates. For companies that went through a rebrand in the last 18 months or use custom domains, it dropped to 61%.

Lusha had the best phone accuracy of any packaged tool. 74% of returned direct dials were working numbers. That's significantly better than Apollo.io's 68%, and the coverage is stronger in EU and APAC than Apollo's North America-skewed database.

PDL has by far the largest raw footprint — 1.5B+ person records — but a record existing and an email delivering are completely different things. Without a verification layer, PDL's 67% delivery rate makes it unusable for direct outreach without additional tooling cost.

The Number That Actually Matters

Tool	Monthly spend	Contacts accessed	Verified contacts	Cost per verified
Apollo.io Basic	$49	75	53	$0.92
Apollo.io Pro	$79	~300	213	$0.37
Hunter.io Starter	$49	500	420	$0.12
Hunter.io Growth	$149	2,000	1,680	$0.09
Lusha Premium	$52	600	474	$0.11
RocketReach Pro	$170	400	304	$0.56
PDL + NeverBounce	~$110†	1,000	670	$0.16

†PDL at $0.01/record × 1,000 records = $10, plus $98 base plan, plus ~$0.02/verification × 1,000 = $108 total.

Apollo.io Basic is a bad deal by this math — $0.92 per verified contact is the worst ratio in the group. The Professional plan flips the story: at $0.37 per verified, it becomes competitive, especially if your team sends high-enough volume to justify the seat cost.

RocketReach occupies the worst position in the market: higher cost-per-verified than both Hunter.io and Lusha, smaller database than Apollo.io or PDL, and no clear accuracy edge anywhere. Its one genuine strength is a clean LinkedIn Chrome extension, but that alone doesn't justify a $0.56 cost-per-verified.

When Each Tool Wins

Apollo.io makes sense if you need email + phone in one place, want built-in sequencing tools, and your team will genuinely hit Professional-tier volume. The Basic plan exists to get you hooked — the math only works at Professional with 5+ SDRs churning through lists daily. Also note that Apollo.io has added AI research features in 2026 that consume additional credits, so watch your usage dashboards.

Hunter.io is the right call for email-only campaigns targeting known, mid-to-large companies. If you're running domain-level outreach ("find everyone at acme.com we should talk to"), Hunter.io's Growth plan at $0.09 per verified contact is hard to beat. It has no phone data, so you'll need a second tool if dials are part of your workflow.

Lusha wins on phones. If direct-dial accuracy matters — especially in Europe — Lusha Premium at $52/month for 600 contacts is the most cost-effective option in this comparison. Their GDPR compliance documentation is also more defensible than Apollo.io's for EU-based GTM teams.

PDL is not a packaged sales tool — it's an API for builders. If you're populating a CRM at bulk, building a data product, or enriching >5,000 contacts/month, the per-record cost of $0.01 destroys every packaged option on unit economics. But you need engineering capacity to call the API and a verification layer (ZeroBounce or NeverBounce) to get usable delivery rates. This is not a tool for an SDR with a Salesforce login.

Cognism and ZoomInfo sit above this tier in price but also in phone accuracy for North America and UK markets. If direct dials are your primary bottleneck and budget isn't the constraint, they're worth evaluating — but both have opaque pricing and push you toward annual contracts that lock in cost before you've validated the data quality for your specific ICP.

What I Actually Use

For pure email prospecting at scale, I run Hunter.io Growth as my primary source — $0.09 per verified contact is hard to justify swapping out. For campaigns where phone numbers matter, I layer Lusha Premium on top rather than paying Apollo.io's 8-credit-per-phone tax.

For bulk database builds from scratch — when I need to go from "ICP criteria" to "10,000 target contacts" — PDL's API wins at any volume above 2,000 contacts/month. I pipe the output through ZeroBounce before anything touches a sending domain.

For Twitter and Facebook profile lookups, where none of the above tools return reliable contact data, Ziwa has been faster for me than PDL's social-match endpoint — and the results don't require a separate verification pass.

One last thing: if you're evaluating Clay or Phantombuster as orchestration layers — they're calling these same APIs under the hood and charging a waterfall markup. Before you pay that premium, run your own cost-per-verified calculation. In most cases you're paying 2–3x to avoid writing a short enrichment script.

The bottom line: stop comparing list prices. Build the cost-per-verified-contact table for your actual ICP and volume. The rankings shift significantly, and in most mid-market prospecting workflows, Hunter.io or Lusha will come out on top — not Apollo.io.

Why 30% of B2B Email Verification Fails: The Catch-All Domain Problem Explained

Zackrag — Mon, 20 Apr 2026 06:23:52 +0000

Three months ago I ran a cold outbound campaign to 4,200 "verified" leads. The list had been processed by a well-known verifier—overall accuracy rate: 97%. My bounce rate on the first send was 11.4%. The domain I was using had been sending cleanly for two years. It took six weeks of re-warmup to recover it.

The culprit: catch-all domains. Nobody told me they were a separate category with completely different verification mechanics.

What a catch-all domain actually is

When your email server checks whether an address is valid, it initiates an SMTP handshake with the receiving mail server and asks: "Does this mailbox exist?" Most servers answer honestly—250 means yes, 550 means no.

Catch-all servers lie. Or more precisely, they're configured to accept everything. They respond 250 OK to every address—real@company.com, fake@company.com, asdfgh@company.com—regardless of whether any mailbox behind that address is actually active.

This is usually intentional. Companies configure catch-all so they don't lose emails sent to misspelled or retired addresses. It's especially common in mid-market and enterprise: smaller IT teams, older infrastructure, less aggressive inbox hygiene.

On a typical B2B prospecting list, 30–40% of addresses sit on catch-all domains. For lists heavy with enterprise accounts, that number climbs higher.

Why SMTP probing fails completely here

Standard email verification runs five steps: syntax check, DNS lookup, MX record check, SMTP handshake, and catch-all detection. Steps 1–4 work fine. Step 5 is where things break.

"Catch-all detection" identifies that a domain is catch-all. It doesn't tell you whether the specific mailbox behind it is active. Once a server is flagged as catch-all, the verifier has no SMTP-based path to probe individual addresses. The server will say 250 OK to anything you throw at it. The protocol makes deeper probing impossible.

So what do tools do when they hit a catch-all domain? Most mark every address on it as "risky," "unknown," or "accept-all," then move on. Some try heuristics—checking whether the username format matches LinkedIn patterns, or whether the domain's MX records belong to Google Workspace or Microsoft 365 managed hosting. None of them can tell you definitively whether james.porter@bigcorp.com has an active inbox.

This is not a bug in any specific tool. It's a protocol ceiling every tool hits equally.

The accuracy number vendors don't show you

Every verification vendor publishes a headline accuracy figure. ZeroBounce claims 98%+. Kickbox claims 99%. NeverBounce's marketing lands around 99.9%. These numbers are accurate. They're also misleading.

When Hunter.io ran an independent benchmark of 15 email verification tools across roughly 3,000 real business emails, the top scorer hit 70% overall accuracy. Clay ran a separate controlled test and found that when catch-all domains were excluded from the sample, ZeroBounce hit 99.25%, Findymail hit 98.92%, Hunter hit 98.52%.

The tools are genuinely excellent—on the addresses they can actually verify. The gap is the catch-all segment. Vendors report accuracy on verifiable addresses and either exclude catch-alls from their benchmark methodology or group them under "risky: send at your own risk."

A list with 40% catch-all addresses and 99% accuracy on everything else can still produce a 9%+ bounce rate if you send to the catch-all segment without further triage. Scrubby's data puts the hard-bounce rate on unverified catch-all emails at around 23%.

How the major tools actually handle catch-alls

Here's what I found after running the same 1,200-address catch-all segment through each tool:

Tool	Marketed Accuracy	Catch-All Strategy	Real-World Verdict
ZeroBounce	98%+	Flags as "accept-all," assigns risk score	Conservative; useful API structure for pipelines
NeverBounce	99.9%	Flags as "accept-all," excludes from safe-send	Most conservative; 0 bounces on approved in independent tests
Kickbox	99%	Flags as "accept-all," engagement scoring	Best at detecting catch-all domains accurately
Findymail	98.9%	Pattern-based scoring for catch-all addresses	Good username heuristics, useful as second pass
Hunter.io	95%+	Returns "catch-all" status, leaves triage to you	Honest about limitations, no false confidence
ZoomInfo	Enterprise tier	Supplements SMTP with in-platform activity signals	Best supplemental signal, worst price point

The table makes something visible that most comparisons hide: differentiation is in what tools do with uncertainty, not with addresses they can cleanly verify. A tool that aggressively marks catch-all addresses as risky will score lower in aggregate accuracy benchmarks—because it refuses to give a clean verdict—but will protect your deliverability better in practice.

NeverBounce's conservatism looks bad in head-to-head tests where "gave a clean result on more addresses" is counted as accuracy. In real campaigns, that conservatism is a feature. Kickbox's advantage isn't its overall number—it's that it's better at detecting catch-all domains in the first place, so your risky segment is more accurately populated.

Why your current workflow is probably wrong

The common mistake: treating "risky" and "invalid" as interchangeable. They're not.

Invalid means the SMTP handshake returned a hard rejection—the mailbox definitively doesn't exist. Never send to these.

Risky/accept-all means the tool couldn't verify the address. Some of these are real inboxes. Depending on the domain, delivery rates on catch-all addresses range from 50% to 85%—the spread is large because it depends on the specific company's mail configuration. Suppressing your entire catch-all segment can mean losing 20–30% of legitimate leads.

Most people run verification once before a campaign and assume they're done. With catch-all domains, that's a single point of failure.

A triage workflow that actually works

After losing a domain to a bad catch-all send, I rebuilt my process around five steps:

1. Separate your catch-all segment immediately. Any verifier returns a status field. Pull every row where status is accept-all, catch-all, unknown, or risky. Never mix this with your clean-send list.

2. Apply username pattern scoring. Addresses following firstname.lastname or firstname patterns at domains with Google Workspace or Microsoft 365 MX records are substantially more likely to be active. Addresses like info@, admin@, support@, or auto-generated strings are almost always shared inboxes or role addresses—skip them regardless.

3. Verify the person, not just the address. If you can confirm on LinkedIn that the person is currently employed at that company, the probability of a real inbox jumps meaningfully. You're not verifying the email through this step—you're verifying the person behind it. Tools like Clay make this feasible at scale.

4. Warm up your catch-all sends separately. Never mix catch-all addresses into your main send sequence. Start with 10–15% of the catch-all segment, monitor bounce rate after 72 hours, and expand only if you stay under 1% hard bounce. Each new batch is its own experiment.

5. Re-verify quarterly. Catch-all configurations change. A domain that was catch-all six months ago might have tightened its policy. A clean domain might have moved to catch-all after an IT migration. Static verification is a snapshot.

The difference between a 2% bounce rate and an 11% bounce rate is almost always whether you had a catch-all triage layer—not which primary verifier you used.

What published benchmarks miss

Published verifier comparisons focus on aggregate accuracy across the full dataset. Almost none isolate catch-all accuracy as a separate metric. This creates a real problem: the tools that score highest in benchmarks are often the ones most likely to give you a false sense of safety.

If a tool marks 40% of your list as "risky" and you ignore that, you're not using the tool correctly. If a tool marks only 15% as risky and lets the rest through, it's not necessarily more accurate—it may just be less cautious.

The honest metric to demand from any verifier is: of the addresses you classified as safe-to-send, what percentage actually delivered? Not overall accuracy. Safe-to-send accuracy. That number tells you what the tool is actually doing with catch-all uncertainty.

Very few vendors publish this breakdown. NeverBounce comes closest with its conservative flagging. For everyone else, you're extrapolating from aggregate claims.

What I actually use

For the core verification pass, I run Kickbox first for its catch-all detection reliability, then run the risky segment through Findymail for pattern scoring on the usernames.

For any batch where the catch-all rate exceeds 30%, I pull it through Clay to add LinkedIn employment signals before deciding whether to include those addresses in an active sequence.

ZeroBounce is my default when I'm integrating verification into an automated pipeline—the API response structure is cleaner and the documentation is thorough. NeverBounce is my choice when domain reputation matters more than list size: it's more conservative, which costs leads but protects deliverability.

For workflows that start from social profiles rather than an existing email list—pulling contact data from Twitter or Facebook profiles—Ziwa has been faster for me than going through PDL's direct API, though that's a different use case than verifying a list you already have.

If you're running more than 5,000 emails per month to B2B lists, the catch-all segment deserves its own process. Treating "risky" as interchangeable with "skip" loses real leads. Treating it as interchangeable with "safe to send" destroys domains. The workflow above sits between those two failure modes.