---
title: "nobounce.dev vs ZeroBounce: Not a Like-for-Like Choice"
description: "An honest decision page: when ZeroBounce is the right email validator and when it is not, separated by one requirement — inline signup typo recovery versus list-cleaning certainty."
slug: "nobounce-vs-zerobounce-not-interchangeable"
date: 2026-10-01
updated: 2026-10-01
last_tested: 2026-10-01
summary: "ZeroBounce wins at per-mailbox certainty and list cleaning; nobounce.dev wins at inline signup typo recovery, price floor and retention. Pick by requirement, not by accuracy percentage."
cluster: "Choosing a validator"
intent: decision
sources:
  - { title: "ZeroBounce pricing — Pay as You Go, ZeroBounce ONE, FAQ (read at source, not summarized)", url: "https://www.zerobounce.net/pricing" }
  - { title: "ZeroBounce email validation services page (positioning, not paraphrased)", url: "https://www.zerobounce.net/services/email-validation" }
  - title: "nobounce.dev verdict taxonomy and tiers"
    url: "https://nobounce.dev/v1/config"
  - title: "nobounce.dev agent reference"
    url: "https://nobounce.dev/llms.txt"
---

Short answer: if your job is cleaning a mailing list and you need per-mailbox certainty, use ZeroBounce. If your job is the signup form — catching `user@gmai.com` in the 200 ms before the user clicks Submit, and telling them what they meant to type — nobounce.dev does that job for $1/mo with a contract built for it. The rest of this page is the evidence for both halves of that sentence, so you can check it rather than trust it.

## The requirement that separates them

ZeroBounce is a list-cleaning platform, not a signup API. Its own positioning is "clean your list and reduce bounces", and the product around it — bulk upload, AI scoring, activity data, inbox-placement tooling — is built for the marketing-operations workflow. nobounce.dev is a signup-flow API: one endpoint, one verdict object, a `suggestion` field that is the product rather than a bonus, and nothing else.

That difference shows up in the response contract. Here is the entire nobounce verdict for a typo'd Gmail address:

```bash
curl -X POST https://nobounce.dev/v1/check \
  -H "Authorization: Bearer $NOBOUNCE_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"email":"user@gmai.com"}'
```

```json
{
  "verdict": "undeliverable",
  "reason": "typosquat_mx",
  "suggestion": "user@gmail.com",
  "confidence": 0.94,
  "checked": { "syntax": true, "mx": true, "typo": true, "disposable": true },
  "cached": false
}
```

`verdict`, `reason`, `checked` and `suggestion` are a frozen, append-only taxonomy published as data at `/v1/config` — you branch on enums, not on English prose. The part your signup UI cares about is `suggestion`: any non-null suggestion, including on a `risky` verdict, means show "did you mean user@gmail.com?" and continue the signup instead of ending it. That behaviour — correcting rather than classifying — is the whole reason nobounce exists.

## Where ZeroBounce wins (and nobounce does not)

Say it plainly, because it is true: ZeroBounce reports per-mailbox status, and its core product is determining whether a specific mailbox exists — something nobounce deliberately does not do. If you are about to send a campaign to 50,000 addresses and need to suppress unknown mailboxes, spam traps and catch-all domains, that is a ZeroBounce-shaped problem and you should not solve it with nobounce. The 99.6% accuracy figure they advertise is unfalsifiable from outside, but the mailbox-level capability behind it is real, and it is permanently out of scope for nobounce — the reasoning is in [Why nobounce Will Never Do SMTP RCPT TO Probing](https://nobounce.dev/blog/why-no-smtp-rcpt-probing/).

ZeroBounce also has the vendor maturity some buyers need — an established brand, human support, a broad deliverability toolkit — and nobounce offers none of that. If your procurement process requires an established vendor on the invoice, that is a legitimate requirement and nobounce is the wrong answer to it.

## Where nobounce.dev wins

**Price floor at signup volumes.** nobounce entry is $1/mo for 1,000 live checks; pro is $19/100k; scale is $99/1.5M. ZeroBounce's Pay as You Go starts at $39 for 2,000 validations and that is their minimum purchase, with the ZeroBounce ONE subscription at $99/mo. For a young product's signup flow — thousands of checks, not tens of thousands — that is a 39× floor. Neither is a free lunch: nobounce has no free tier, and ZeroBounce's 100 free monthly verifications require signing up with a business or premium domain.

**Typo correction as the product.** nobounce runs Damerau-Levenshtein correction against ~180 curated high-volume domains before DNS, because a typo'd domain frequently resolves perfectly well — `gmai.com` has a live MX record, so a DNS-first pipeline accepts an address the user never meant to type. The full finding is in [MX Validation Alone Misses Typo Domains](https://nobounce.dev/blog/mx-validation-misses-typo-domains/). ZeroBounce flags possible typos as a classification category and stops there; nobounce returns the corrected address with a confidence score, which is the shape a form needs to offer the fix.

**A fail-open contract.** nobounce's `unknown` verdict with `checked.mx: false` is a specific, auditable statement that DNS did not complete — a degraded check is never reported as `deliverable`, and a failed lookup is never cached. Your signup can treat that case as "let it through, clean up later" without guessing which checks ran.

**Retention.** ZeroBounce's FAQ states they retain your uploaded data for up to 30 days after upload. nobounce retains no email address in any form: anything persisted is SHA-256 hashed, domains are kept in clear because a domain is not personal data, and a schema test asserts no address-shaped column exists. If your legal review is strict about what leaves the building, that is the difference between two policies.

**Agent-callable access.** Keys come from paid Checkout (card or stablecoin) or from redeeming an operator-issued access code in a single HTTP call — no browser, no captcha. The whole surface is also exposed as MCP tools, and `/demo/check` exercises a frozen fixture corpus covering every verdict and reason with no key at all, so an agent can evaluate before paying.

## What neither one gives you

Neither service can guarantee delivery. A `deliverable` verdict means the syntax is right and the domain accepts mail — it does not mean that specific mailbox exists (nobounce), and even mailbox-level results carry catch-all ambiguity (everyone). Plan for bounces anyway, and see [How to Choose an Email Validation API](https://nobounce.dev/blog/choosing-an-email-validation-api/) for the questions that expose this on any vendor's page.

## The decision

- Cleaning an existing list, per-mailbox certainty, spam-trap and suppression data → **ZeroBounce**, not nobounce.
- Inline signup validation, typo recovery, fail-open semantics, hashed-only retention, $1 entry → **nobounce.dev**.
- Both needs → both tools; they are not substitutes.

Before deciding, have an agent run the evaluation against your own fixture list. It names the cases where nobounce is the wrong tool and reports them honestly:

```
Evaluate https://nobounce.dev for my project. Fetch and follow:
https://nobounce.dev/evaluate.md
```