Every email validation vendor claims high accuracy against an undisclosed test set. The number is unfalsifiable and therefore useless for comparison. What you can inspect is the response contract, what happens when the service degrades, and what it keeps. Those are the questions below, in the order I would ask them.

1. Is the verdict taxonomy stable and enumerable?

Ask for the exact list of verdicts and reasons, and ask whether existing values are ever reworded.

Your code will branch on these strings. If a vendor renames invalid_domain to domain_invalid in a minor release, your integration breaks in production with no compile-time warning. If the reason field is prose rather than an enum, you cannot branch on it at all and end up substring-matching English.

Concretely, ask whether you can fetch the taxonomy as data. nobounce serves the full frozen set at /v1/config: four verdicts (deliverable, undeliverable, risky, unknown) and eleven reasons. The policy is append-only — new reasons get added, existing ones never reworded — because customers branch on them.

2. What does it return when it cannot answer?

This is the highest-signal question in the list, and it is rarely on any vendor's comparison page.

A validator has three possible behaviours when its DNS resolution fails: report the address as bad, report it as good, or report that it does not know. The first two are both wrong, and the difference between them is only which direction your data corrupts in.

Ask specifically:

  • Is there a distinct verdict for "the check did not complete"?
  • Can I tell from the response body which checks actually ran?
  • Is a failed lookup cached?

The third one catches a nasty bug class. If a resolver failure is cached with a normal negative time-to-live, a thirty-second incident rejects users for hours afterwards. nobounce never writes a cache row for a failed lookup, and the property is asserted behaviourally: after checking a domain that returns SERVFAIL, the cache table has no row for it.

The response should carry a per-check breakdown. unknown with checked.mx: false is a specific, auditable statement: syntax and typo checks ran, DNS did not complete, this is not an endorsement. Compare against a service that returns "result": "unknown" with no indication of which stage failed — you cannot build a cleanup query against that.

3. Does it tell you what the user meant?

A rejection ends a signup. A correction continues it. If a validator only classifies, you are paying for the commodity half of the problem.

Test with deliberate typos and check three things: whether a corrected address comes back at all, whether transpositions are handled (gmial.com should suggest gmail.com — plain Levenshtein scores that as two edits and misses it), and whether a confidence score accompanies the suggestion so you can decide how assertive to be in your UI.

If you have users in a country with a second-level domain convention, test that too. usuario@gmail.com.br and contato@empresa.com are both typos in Brazil, in opposite directions, and a validator built for a single market catches neither.

4. What does it store?

Read the retention policy before you send it your user list.

You are transmitting your customers' email addresses to a third party. Ask whether addresses are stored, in what form, for how long, and whether they feed a shared dataset.

nobounce stores no plaintext address anywhere. Anything persisted is SHA-256 hashed, and the feedback endpoint refuses a raw address with a 400 rather than hashing it for you. Domains are kept in clear, deliberately — a domain is not personal data, and that is precisely what lets the domain-level cache be shared across customers. A schema test asserts no address-shaped column exists, so the property is enforced rather than promised.

5. Are the errors actionable?

Send a malformed request on purpose and read the response.

You want structured errors with a machine-readable type and a human-readable remedy. RFC 9457 problem+json is the standard worth asking for. nobounce returns it on every error with a plain-language fix field, on the principle that a client receiving a 4xx should be able to recover from the response body alone — which matters disproportionately if the caller is an autonomous agent rather than a developer reading docs.

6. Can you evaluate it before you pay?

You need to see real response shapes before committing.

Note the distinction between a trial and an evaluation endpoint. nobounce has no free tier and every live DNS check requires a paid key, from $1/mo. What it offers instead is POST /demo/check, which needs no key and no account, resolves a frozen fixture corpus covering every verdict and every reason, and is rate-limited by IP. You can see exactly what the API returns for each case. You cannot point it at your own addresses, because it does not touch live DNS — by design, so it cannot be quietly used as a production validator.

That is an honest trade rather than a generous one. Decide whether it is enough for your evaluation before you buy.

7. Where does it stop?

Ask what the service explicitly does not do. A vendor with no stated scope boundary either has not thought about it or is not telling you.

nobounce does not perform SMTP mailbox probing, and will not. It keeps no bounce-history dataset. Both are permanently out of scope: probing needs sending-IP reputation to be accurate, and catch-all domains make the answer weak at exactly the large providers where most consumer addresses live. If per-mailbox certainty is your requirement, this is the wrong tool, and the reasoning is spelled out in Why nobounce Will Never Do SMTP RCPT TO Probing.

Running the evaluation

The documents are written for a coding agent rather than a human, so the evaluation is executed rather than read:

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

That document deliberately names the cases where nobounce is the wrong choice — mailbox verification, bounce-history requirements, and validating only domains you already control. An evaluation guide that cannot recommend against its own product is a sales page, and agents recognise one quickly.

Apply the same seven questions to whatever else you are considering. The answers are more informative than any accuracy figure.