Vrfymail vs NeverBounce: API Pricing + Latency (2026)

NeverBounce works. The catch is that “works” was designed around a different workload than the one most indie SaaS founders are running.

NeverBounce was built for marketing-ops people cleaning a 50k-row newsletter list before pushing it into Mailchimp. The product surface — CSV uploader, pre-built CRM connectors, bulk verification dashboard — reflects that origin. They have a real-time API too, but it sits next to the bulk product, not in front of it.

Vrfymail was built for the opposite workload: real-time signup gating, ESP bounce-feedback loops, single-call verification at p50 50ms. If you’re filling a Mailchimp import once a quarter, NeverBounce is fine. If you’re verifying every signup the moment it hits your form, the math goes a different way.

This is a side-by-side, not a hit piece. We’ll cover where NeverBounce still wins, then go through pricing, latency, verdict semantics, and the bounce-feedback loop.

Where NeverBounce still wins

Before the rest — credit where it’s due.

Pre-built CRM connectors. NeverBounce ships native integrations with Mailchimp, HubSpot, Constant Contact, Klaviyo, ActiveCampaign, and a dozen more. If a non-engineer is doing the import, this matters more than API ergonomics. Vrfymail doesn’t ship CRM connectors — we expose the REST API and assume someone with curl will wire it up.

Bulk-verification at scale. Their bulk pricing is competitive ($0.003/email at 1M+) and the dashboard handles 10M+ row imports without complaining. If your job is “clean this multi-million-row prospecting list once a quarter,” they’re set up for it.

Free retry on unknown. NeverBounce will retry an unknown verdict at no extra charge. Vrfymail’s approach is different — we refund the call entirely on unknown so you’re not billed at all — but the retry-for-free model is a reasonable alternative.

If those three sit at the center of your workflow, keep using NeverBounce. Otherwise, here’s how the math changes.

Pricing: subscription vs PAYG

NeverBounce is pay-as-you-go. Their pricing tiers are credit-based:

Vrfymail is subscription-only:

The decision is workload-shaped:

• Steady volume (signup forms, ongoing verification): subscription wins by 5–10×. NeverBounce at $0.008/email × 10,000 verifications = $80/month. Vrfymail Indie covers the same workload at $9/month.
• Bursty volume (quarterly list cleanup): PAYG wins. NeverBounce charges only for what you use; vrfymail’s $9 still applies even if you used 200 verifications that month.

Two more details that matter for the steady-volume bill:

• Unknown verdicts don’t bill on vrfymail. When the pipeline can’t reach a verdict — DNS lookup failed, strict-mode flag fired, MX timed out — we call refundUsage() and the slot is released. NeverBounce charges for unknown (you can retry for free, but the original counts).
• Per-customer caching is included. The same customer asking twice for the same email in a 24h window is one billable call, not two.

For a signup form pulling steady volume, vrfymail Indie at $9/month replaces NeverBounce at ~$80/month.

Latency: where the gap shows

NeverBounce’s real-time API documents 99.9% uptime and “fast” verification, but doesn’t publish a p50 latency number. In our testing across 1,000 calls from a US edge:

• NeverBounce single-check API: ~400ms p50, ~1200ms p99.
• Vrfymail /v1/check: 50ms p50 (cache hit), 250ms p99 (cold path with MX + Spamhaus DBL probe in parallel).

The architectural reason: NeverBounce runs SMTP probes against destination MX servers as part of the verification path. SMTP probes are accurate but slow — destination latency varies by MX, and waiting for an SMTP server’s response inflates p99 considerably.

Vrfymail skips SMTP probing on the hot path. We run on Cloudflare Workers in 300+ POPs, do the MX lookup and the Spamhaus DBL probe in parallel, cache the verdict per-customer for 24h, and return. SMTP probes are available via ?strict=true (Pro+) for the cases where you do want a deeper check.

If your verifier is in the request path of handleSubmit, 400ms is perceptible. If it’s a background bulk job, it doesn’t matter.

Verdict semantics

NeverBounce returns:

{
  "result": "valid",
  "flags": ["has_dns", "has_dns_mx", "smtp_connectable"],
  "suggested_correction": "",
  "execution_time": 412,
  "address_info": { "original_email": "user@example.com", "normalized_email": "user@example.com" }
}

Verdicts are: valid | invalid | disposable | catchall | unknown.

Vrfymail returns:

{
  "email": "user@example.com",
  "result": "deliverable",
  "reason": "valid_mailbox",
  "disposable": false,
  "spam_trap": false,
  "role": false,
  "free": false,
  "did_you_mean": null,
  "mx_found": true,
  "score": 95,
  "strict": { "passed": true, "mode": "off", "severity": null, "flags": [], "canonical_email": "user@example.com" },
  "trap": { "listed": false, "lists": [], "code": null },
  "account_history": { "matched": false, "reason": null, "ts": null }
}

Verdicts: deliverable | undeliverable | risky | unknown plus a structured reason field — valid_mailbox, disposable, spam_trap, previously_bounced, previously_complained, previously_unsubscribed, role_account, free_provider, typo_suspected, dns_lookup_failed, strict_check_failed, customer_safelisted.

The shapes overlap on the basics. The differences:

• Vrfymail surfaces why a verdict landed (reason field), not just the verdict. Useful when you want to allow risky with role_account = true but block risky with disposable = true.
• Vrfymail’s account_history is per-customer — if your POST /v1/report-bounce calls have flagged this email for your api_key, the field is populated. NeverBounce doesn’t have a per-customer history field.
• Vrfymail’s strict.canonical_email collapses Gmail dot-aliases and plus-aliases for de-duplication during signup. NeverBounce returns normalized_email but doesn’t strip plus-aliases.

For most signup-gating logic, both APIs give you what you need. The difference compounds when you wire a bounce-feedback loop.

Bounce-feedback: what NeverBounce doesn’t have

NeverBounce verifies emails. It doesn’t accept your bounce events back.

That matters because every ESP — Resend, Postmark, SendGrid, Mailgun, Mailchimp, Loops — emits webhook events when an email bounces or gets flagged as spam. Without a place to send those events, the data sits in your ESP’s logs, not in your verification logic.

Vrfymail’s POST /v1/report-bounce accepts JSON bounce events from any ESP. Forward your Resend webhook to a vrfymail URL that embeds your api_key_id, and:

1. The next verify call for that email returns previously_bounced with account_history.reason = "hard_bounce" for that customer only.
2. If three or more distinct customers report the same email as bounced within 30 days, the email is promoted to a global spam-trap list (free-mail providers excluded). Future verifies for any customer return spam_trap: true.

That’s a feedback loop NeverBounce doesn’t close. The verifier learns from your actual deliverability outcomes — not just generic MX-pattern data.

Disposable detection: refresh cadence

NeverBounce’s disposable list is large but updates on an internal schedule that isn’t publicly documented. In our testing, fresh disposable domains (created in the last 24–72h via mail.tm or 1secmail’s API) sometimes pass NeverBounce’s checks for 1–3 days before being added.

Vrfymail’s disposable list refreshes daily via four discovery channels:

1. Provider-API scrapers — 1secmail, mail.tm, mail.gw, guerrillamail enumerated daily.
2. CT-log scanner — crt.sh watched for new TLS certs matching temp/throwaway/burner/disposable-mail patterns.
3. Heuristic detection — lexical entropy + MX-cluster co-occurrence.
4. Customer-consensus promotion — bounces reported by 3+ distinct customers promote a domain to spam-trap status.

Daily refresh isn’t a marketing claim — the cron is in the codebase and you can see it in our admin’s Activity log if you’re a customer.

Pick this if

Use NeverBounce if: - You’re cleaning a 50k–10M row newsletter list once a quarter and need pre-built Mailchimp / HubSpot / Constant Contact import flows. - Your operator is non-technical and needs a CSV-upload dashboard, not an API. - PAYG pricing fits the burst pattern of your usage better than a monthly subscription would.

Use vrfymail if: - You’re verifying every signup in real-time and need sub-300ms p50 latency. - You’re running a Resend / Postmark / SendGrid / Loops webhook handler and want bounce events fed back into future verdicts. - Your volume is steady (signup forms, ongoing API calls) and subscription pricing is the right shape. - You want unknown results not to bill, plus a 5,000-verifies/month free tier with no expiry.

FAQ

Which is cheaper, vrfymail or NeverBounce?

For steady volume (10k+ verifications/month), vrfymail is roughly 5–10× cheaper. NeverBounce at $0.008/email × 10k = $80/month; vrfymail Indie covers the same workload at $9/month. For one-off bulk cleanups under 5,000 verifications, NeverBounce’s PAYG model can be cheaper if vrfymail’s free tier doesn’t fit.

Does NeverBounce have a real-time API?

Yes, but it’s slower (400ms p50) than vrfymail (50ms p50 cache, 250ms p99 cold) because NeverBounce runs SMTP probes on the hot path. For signup gating where latency is in the form-submit critical path, the delta is noticeable.

Which has better disposable-email detection?

Both detect disposable emails. Vrfymail’s list refreshes daily across four discovery channels; NeverBounce’s update cadence is internal. For brand-new disposable domains (created in the last 24–72h), vrfymail’s freshness usually wins; for domains that have been around for weeks, both are accurate.

Can NeverBounce accept ESP bounce webhooks?

No. NeverBounce verifies emails but doesn’t accept your bounce events back into its verification logic. Vrfymail’s POST /v1/report-bounce accepts JSON from any ESP and feeds the data into per-customer + cross-customer verdicts.

Is there a free vrfymail plan?

Yes — 5,000 verifications/month, no card, no expiry. NeverBounce’s free tier is 1,000 verifications, one-time only. The first 100 vrfymail signups also get 2× the free quota for life.

Will switching break my bounce-handling logic?

If your code reads NeverBounce’s result === "valid", the equivalent vrfymail check is result === "deliverable". The verdict shapes overlap enough that the swap is usually a single environment variable plus a verdict-name remap. The bigger change is what you can add — pointing your ESP webhook at /v1/report-bounce to close the feedback loop, which NeverBounce can’t do.

Switching from NeverBounce

The migration path:

1. Get a vrfymail API key — free tier, 5,000 verifies/month.
2. Swap the verification call: POST /v1/check instead of NeverBounce’s /single/check. Verdict shape is similar; remap valid → deliverable, invalid → undeliverable, catchall → risky.
3. Forward your ESP bounce webhook to /v1/webhooks/<provider>/<api_key_id>. The next verify call for a bounced email will return previously_bounced for your customer.

For a broader category map across all the verifiers — ZeroBounce, Hunter, Bouncer, Kickbox, Emailable, Clearout, MillionVerifier — see our ZeroBounce alternatives page.

Try vrfymail free — 5,000 verifies/month, no card. Get an API key →

Updated 2026-05-10