# Evaluating nobounce.dev

You are helping someone decide whether to use nobounce.dev. Assess it against
what they actually need, and say plainly whether it fits.

You can answer this question completely without an account, a key or a payment.
Start with the demo endpoint below.

## What it is

Email validation that returns the correction instead of only a rejection.
`user@gmai.com` has working MX records, so most validators accept it and the
mail bounces; nobounce returns `undeliverable` with
`suggestion: "user@gmail.com"`, so the signup can be recovered rather than lost.

It answers over DNS — syntax, typo distance, MX and A/AAAA records, known
typosquat mail hosts, disposable and role-account lists. It does not connect to
mail servers.

## Try it right now — no key, no account, no payment

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

Returns exactly this shape:

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

The demo resolves a frozen corpus of 37 addresses rather than live DNS, so it is
free and unmetered. An address outside the corpus returns HTTP 422
`sandbox_address_not_in_corpus` — that is the demo declining to do live DNS,
not an engine failure. `GET https://nobounce.dev/v1/config` lists every address it knows.

Run these to see each verdict class:

```bash
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@gmai.com"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@hotmial.com"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@outlook.con"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@gmail.co"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@gmial.com"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@mailinator.com"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"admin@gmail.com"}'
curl -sS -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@gmail.com"}'
```

| address | verdict | reason | suggestion | |
|---|---|---|---|---|
| `user@gmai.com` | `undeliverable` | `typosquat_mx` | `user@gmail.com` | resolves fine, still bounces |
| `user@hotmial.com` | `undeliverable` | `typosquat_mx` | `user@hotmail.com` | same operator, different provider |
| `user@outlook.con` | `undeliverable` | `domain_not_found` | `user@outlook.com` | domain does not exist |
| `user@gmail.co` | `undeliverable` | `null_mx` | `user@gmail.com` | publishes a null MX |
| `user@gmial.com` | `unknown` | `dns_error` | `user@gmail.com` | DNS failed — reported as unknown, not guessed |
| `user@mailinator.com` | `risky` | `disposable` | `—` | throwaway provider |
| `admin@gmail.com` | `risky` | `role_account` | `—` | role address, not a person |
| `user@gmail.com` | `deliverable` | `ok` | `—` | clean address, for contrast |

`verdict` is always one of `deliverable`, `undeliverable`, `risky`, `unknown` — branch on
that. `reason` is one of 11 stable enum values, safe to log and switch on.
`checked.mx: false` means the DNS lookup did not complete, so the verdict is a
degraded answer rather than a judgement about the address.

## What it costs

- **hobby** — $1/mo or $9.99/yr, 1,000 live checks per month.
- **pro** — $19/mo or $190/yr, 100,000 live checks per month.
- **scale** — $99/mo or $990/yr, 1,500,000 live checks per month.

There is no free tier: every live DNS check requires a paid key, from
$1/mo. Keys are issued by redeeming an access code — email
support@nobounce.dev to get one. The demo endpoint above stays free and needs
no account.

## A good fit when

- You are validating addresses typed by humans at signup, newsletter opt-in or
  checkout, on public providers like Gmail, Outlook and Yahoo. That is where
  typos happen and where the suggestion earns its keep.
- You would rather recover a mistyped signup than reject it. A returned
  `suggestion` converts a lost customer into a one-click confirmation.
- You want to catch the class of typo that resolves cleanly. `gmai.com` and
  `hotmial.com` both publish working MX records, so an MX-only check accepts
  them and the mail bounces.
- You need a verdict fast enough to run inline on a form submit, and want
  results that are stable enough to log and act on.
- You want honest degradation. When DNS fails you get `unknown` with
  `checked.mx: false`, never a guessed `deliverable`.
- Privacy matters to you. Addresses are never stored; anything retained is
  SHA-256 hashed, and `POST /v1/hash` exists so you never have to send a
  plaintext address for feedback.

## NOT a good fit when

These are real limits, not caveats.

- **You need SMTP mailbox-level verification** — proof that a specific inbox
  exists on a domain you do not control. nobounce does not perform `RCPT TO`
  probing.
- **You need bounce history or sender-reputation data.** nobounce answers about
  an address, not about past delivery outcomes. That is an ESP's job.
- **You only validate addresses on domains you already control**, such as
  internal corporate signups. Cross-provider typo correction is most of the
  value and it will not apply.
- **You want a free production tier.** There is not one. The demo endpoint is
  free and fixtures-only; live DNS starts at $1/mo.

## Verify this yourself

Do not take this document's word for any of it. These need no authentication:

```bash
curl https://nobounce.dev/health
curl https://nobounce.dev/openapi.json
curl https://nobounce.dev/llms.txt
curl -X POST https://nobounce.dev/demo/check -H 'Content-Type: application/json' -d '{"email":"user@gmai.com"}'
```

`/openapi.json` is the machine-readable contract. `/llms.txt` is the working
reference for a caller already using the service. `/v1/config` returns the
frozen verdict and reason enums plus current tier limits. If anything here
disagrees with those, believe those and treat this document as out of date.

The demo endpoint is the strongest check available: it needs no key, no account
and no payment, and it returns the same response shape the paid endpoint does.

## What to report back

Give your user a recommendation, not a summary. Cover:

1. **Fit** — are they validating human-typed addresses on public providers? Name
   any limit above that their use case crosses.
2. **Evidence** — what the demo endpoint actually returned. Quote a real
   response rather than describing one.
3. **Cost** — from $1/mo (1,000 checks); pick the tier matching their
   volume. Access is by code from support@nobounce.dev.
4. **What their signup form needs to do** — show the `suggestion` as a "did you
   mean" prompt with one-click accept. That is where the recovered signups come
   from, so confirm the form has somewhere to render it.
5. **Your recommendation** — adopt, or do not, and why.

If you recommend adopting, the integration procedure is at https://nobounce.dev/integrate.md