Notix
Learn

Verifying an address is not the same as verifying a person.

An email verification API tells you whether mail could be delivered to an address. It cannot tell you whether anyone will read it. This page separates the two, says exactly what Notix offers for each, and names the one thing it does not have.

What an address check can tell you

Every verification service runs some subset of five checks. Each one answers a narrower question than its name suggests.

Address checks, what they tell you and what they miss
CheckWhat it tells youWhat it misses
SyntaxThe address is shaped like an address: one @, a local part, a domain with a dot.Nothing about whether the mailbox exists. Most typos are valid syntax.
MX recordThe domain publishes a mail server, so mail can at least be attempted.Whether that server accepts this local part. Catch-all domains accept everything.
Disposable domainThe domain belongs to a throwaway-mailbox service.New disposable domains appear daily; a list is always a little behind.
Role addressThe local part is a role (info@, admin@, noreply@), not a person.Some roles are read by a person every day. It is a signal, not a verdict.
Mailbox probeAn SMTP conversation up to RCPT TO, without sending, to see if the server rejects the address.Gmail, Yahoo and catch-all domains answer yes to everything. Repeated probes get your IP blocked.

Put together, these checks are good at rejecting what is obviously wrong and poor at confirming what is right. A list that passes all five still bounces; a list that fails the disposable check is still worth refusing at sign-up.

Verifying the person instead

A one-time code proves what no address check can: a human opened the mailbox and typed what was in it. Two calls, and the disposable and risk checks run on the first one before a code exists.

POST /v1/verify/send, then POST /v1/verify/check
curl -X POST https://app.usenotix.dev/api/v1/verify/send \
  -H "Authorization: Bearer $NOTIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "to": "user@example.com", "appName": "Acme", "clientIp": "203.0.113.10" }'

# 201 { "id": "ver_abc123", "status": "pending", "attemptsRemaining": 5,
#       "risk": { "score": 0, "level": "LOW", "reasons": [] } }

curl -X POST https://app.usenotix.dev/api/v1/verify/check \
  -H "Authorization: Bearer $NOTIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "id": "ver_abc123", "code": "482913" }'

# 200 { "id": "ver_abc123", "verified": true, "status": "verified" }

The send call scores the request. A disposable domain or a burst of requests from one address or IP answers 422 RISK_REFUSED with the reasons, so your sign-up form can ask for a different address instead of creating a dead account. The full limits, the SMS channel and the risk modes are on the OTP page.

What Notix has, and what it does not

A verification API for people

POST /v1/verify/send and /v1/verify/check, by email or SMS, with expiry, attempt limits and risk scoring handled on the platform. Disposable domains are refused before a code is generated.

A pre-send check for messages

POST /v1/deliverability/check scores an email before it goes: an unverified from domain, marketing without an unsubscribe link, a raw-IP link or a spam score of 10 block the send. See the deliverability check.

No bulk list validation

There is no endpoint that takes a list and returns which addresses are valid. Hard bounces and complaints go on the suppression list on receipt, so an old list cleans itself as you send, and you can import a suppression list from a previous provider.

When to verify what

  • At sign-up: a code. It catches typos, disposable addresses and bots in one step, and every address that survives is one a person confirmed.
  • Before a campaign: the message, not the addresses. Run the deliverability check on the email; let suppression keep the addresses that already bounced out of the send.
  • On an imported list: double opt-in on the contact book, so the first email asks for a confirmation and only the confirmed addresses receive anything else.

The API reference for the verification endpoints is in the docs.

What is an email verification API?
An endpoint you send an address to and get back signals about it: whether the syntax is valid, whether the domain has a mail server, whether the domain is disposable, whether the local part is a role like info@, and sometimes whether the receiving server would accept the mailbox. It answers 'could mail be delivered here' with varying confidence. It never answers 'will a person read it'.
Does Notix have a bulk email verification or list-cleaning API?
No. There is no endpoint that takes a list of addresses and returns which are valid. Notix checks a message before it goes out (POST /v1/deliverability/check) and verifies a person with a one-time code (POST /v1/verify/send and /v1/verify/check, which refuse disposable domains before a code exists). For an existing list, the suppression list and bounce handling do the cleaning as you send.
Should I verify addresses at sign-up or before a campaign?
At sign-up, verify the person: send a code and require it. That catches typos, disposable addresses and bots in one step, and every address on your list is then one a human confirmed. Before a campaign, verifying addresses again adds little; the useful pre-send step is checking the message itself for the findings that get mail refused, and letting suppression keep hard-bounced addresses out.
Why do verification services say an address is valid and it still bounces?
Because most checks stop before the mailbox. Syntax and MX say the domain can receive mail, not that this local part exists. Catch-all domains accept any address at the SMTP stage and reject or drop it later. Large providers answer yes to probes to stop address harvesting. The only certain signal is the bounce, which is why a hard bounce suppresses the address automatically.
What happens to an address that hard-bounces?
Notix puts it on your team's suppression list with the reason HARD_BOUNCE and the email that caused it. Later sends to it are recorded as SUPPRESSED and never attempted, across transactional and marketing mail. You do not need a separate verification pass to keep a dead address from being tried again.
Is a disposable email address always a problem?
For a sign-up that gates a free tier or a trial, usually yes: the mailbox will be gone in an hour and the person will not be back. For a receipt to someone who has already paid, no. The verification API lets you set the risk mode per team, from signals only to strict, and you can allow specific domains that the list would otherwise flag.

Send your first email in five minutes.

Verify a domain, copy an API key, make one call. The free plan does not ask for a card.