Email Verification API for Real-Time Checks

What every call checks

Each address goes through the same steps, cheapest first: a syntax error or a domain with no mail server never costs a mailbox check.

Syntax and typos

Address rules from RFC 5321 and 5322, internationalized domains, and a suggested correction when a popular domain is misspelled.

Domain and MX

The domain must exist and accept mail: MX records, or an address to fall back to, and no null MX (RFC 7505) saying it never takes mail.

Mailbox check

We ask the receiving server whether it would accept mail for the address, then end the conversation before anything is sent.

Accept-all detection

Servers that take mail for every address are flagged, so an address nobody can confirm is reported as risky instead of guessed.

Disposable addresses

Temporary inbox services, recognised by known domains and by the naming patterns new ones use.

Role accounts

info@, sales@, support@ and other function mailboxes, read by several people or by nobody in particular.

Free webmail

Gmail, Outlook, Yahoo and other consumer providers, for scoring business leads.

Sender policy of the domain

SPF, DKIM and DMARC of the address's domain, from the same engine that monitors domains in EmailSecOps.

A status your code can branch on

Four statuses, a machine-readable reason, and the flags behind them. What a signup form usually does with each:

deliverable: The receiving server accepts mail for this mailbox. Accept it.
risky: An accept-all domain, a role account or a disposable address: the reason field says which. Decide by your own policy.
undeliverable: The mailbox or the domain does not exist, or the domain accepts no mail. Ask for another address, offering the suggestion if there is one.
unknown: The server did not answer in time or refused to be checked. Accept it and check again later.

signup.js · server side

const res = await fetch(
  `${API}/verify?email=${encodeURIComponent(email)}`,
  { headers: { Authorization: `Bearer ${process.env.EMAILSECOPS_TOKEN}` } },
);
const check = await res.json();

if (check.status === 'undeliverable') {
  return askAgain(check.suggestion); // "Did you mean …?"
}
if (check.status === 'risky' && check.disposable) {
  return askAgain(null);             // your policy
}
return createAccount(email);         // deliverable, unknown

One engine, three ways in

The API, the dashboard and your AI agent run the same checks and return the same statuses, on one team and one quota.

Single calls

Verify one address per request at signup, checkout or import, with a timeout you choose. Your team's API token, the same one the monitoring API uses.

Batch jobs and the dashboard

Send a whole list as one job and get a signed webhook when it finishes, or upload it in the dashboard with the bulk email verifier.

From your AI agent

Ask Claude or ChatGPT to verify an address or a list over the EmailSecOps MCP server, with the same quota as the API.

Why verify at the door

A typo caught on the signup form costs nothing; the same address in your list costs a bounce on every send until someone removes it.

Mailbox providers watch bounces and complaints when they decide where your mail lands; here is what Gmail, Yahoo and Microsoft require from bulk senders. Accept-all domains are the one case no check settles: how catch-all verification works.

Available today, on paid plans

Checks that need no mailbox connection already run on every paid plan: syntax, MX, provider, free, disposable and role flags, the domain's sender policy and a risk score. Call GET /api/v1/intel/email for one address or POST /api/v1/intel/emails with up to 100.

API reference See plans

How early access works

Step 1
Request access
Tell us what you would verify and roughly how many addresses a month. The form fills in the questions for you.
Step 2
We enable your team
Early-access teams get the dashboard, bulk uploads and the API on their EmailSecOps team, in the order requests arrive.
Step 3
Shape what ships
Beta teams decide what comes next. Pricing is set before general availability, and beta teams hear it first.

Questions about the verification API

Can I verify addresses in real time on a signup form?+

Yes. Call the API from your form handler and act on the status: accept deliverable, ask again on undeliverable or when there is a suggested correction, and decide risky by your own policy. Call it from your server rather than the browser, so your API token stays secret.

What is the difference between email validation and email verification?+

The two terms are often used for the same thing. Strictly, validation checks that an address is well formed and that its domain can receive mail, while verification also asks the receiving server whether the mailbox exists. The API does both and says which check decided the result.

How should my code handle risky and unknown results?+

Treat risky as a policy decision: accept-all and role addresses often belong to real people, disposable ones rarely stay. Do not reject unknown results; the server did not answer, so accept the address and check it again later.

How is the verification API different from the free email address check?+

The free email address check answers from DNS alone: syntax, MX, provider, free, disposable and role flags and the domain's sender policy. Verification adds the mailbox check and accept-all detection, bulk lists with downloadable results, and an API with quotas for signup forms and imports.

When will the email verification API be available?+

It is in early access: teams are enabled in small groups, in the order requests arrive. Request access with your expected monthly volume. Meanwhile, paid plans can check addresses without the mailbox step through GET /api/v1/intel/email and POST /api/v1/intel/emails.

Join the email verification beta.

Tell us where you verify and how many addresses a month. We enable teams in small groups.

Request early access →

Early access · Nothing is sent to the addresses you check · Privacy

Email verification API for real-time checks