Email Verifier — syntax, MX, disposable and role checks

A domain that can receive mail has to say so in public DNS, with an MX record, and a domain that has sworn off mail says that too, with a null MX. Those records are the first thing checked here. You get one row per address telling you whether the domain can actually receive mail, whether it's a throwaway like Mailinator, and whether the address is a shared inbox such as info@ or sales@. It's the pass you run before a send so bounces don't wreck your sender reputation.

Nothing is ever emailed. You don't supply a login, an API key, a mailbox or a proxy.

What it can tell you, and what it can't

It can tell you the syntax is malformed, the domain has no MX records at all, the domain is on a disposable-provider list, the local part is a role account, or the domain is a free consumer provider like gmail.com.

It can't tell you a specific mailbox exists. Nothing that doesn't send mail can. A domain with perfectly good MX records still rejects individual recipients, runs a catch-all, or blocks probes outright. So valid here means "syntax passed and the domain accepts mail". It is not a deliverability guarantee, and the actor won't pretend otherwise.

What you get back

One row per address:

Field	What's in it
email	The normalised address (lowercased, trimmed).
status	valid, risky, invalid or unknown. valid means the address is worth keeping in a list, not that the mailbox exists. See mailboxVerified if that is the question you are asking.
mailboxVerified	true only when a mail server accepted this exact recipient. false when one permanently refused it. null when nobody could ask. On Apify's runners this is null on every row — outbound port 25 is blocked there, so the probe never completes. Run the actor on your own machine to get a real answer.
confidence	0–100 heuristic score behind that status.
reason	Why: mx_valid, no_mx_record, invalid_syntax, disposable_domain, role_account, smtp_recipient_accepted, smtp_recipient_rejected, dns_inconclusive.
syntaxValid	Boolean.
domain	Domain part.
mxFound	true, false, or null when DNS itself was inconclusive.
mxRecords	Array of { priority, exchange }, sorted by priority.
isDisposable	On the built-in throwaway-domain list.
isRoleAccount	info@, sales@, admin@, support@ and friends.
isFreeProvider	Gmail, Outlook, Yahoo and the rest.
smtp	null unless you turn the probe on; otherwise { status, smtpCode, reason }.

A real example from a run:

{
  "ok": true,
  "email": "info@apify.com",
  "status": "risky",
  "mailboxVerified": null,
  "confidence": 88,
  "syntaxValid": true,
  "domain": "apify.com",
  "mxFound": true,
  "mxRecords": [
    { "priority": 1, "exchange": "aspmx.l.google.com" },
    { "priority": 5, "exchange": "alt1.aspmx.l.google.com" }
  ],
  "isDisposable": false,
  "isRoleAccount": true,
  "isFreeProvider": false,
  "smtp": null,
  "reason": "role_account"
}

risky there is the right answer: the domain is fine, but info@ is a shared mailbox, and shared mailboxes are where cold email goes to die.

Input

{
  "emails": ["person@example.com", "info@example.com", "bad@@example.com"],
  "checkSmtp": false,
  "smtpTimeoutMs": 5000,
  "maxConcurrency": 10
}

Field	Default	Notes
emails	—	The list. Duplicates are lowercased and collapsed, so you're only billed once for the same address.
checkSmtp	false	Turn on the bounded SMTP probe. Read the section below first.
smtpTimeoutMs	5000	Per connection. Hard-capped at 8000 so a run can't hang on one dead MX.
maxConcurrency	10	1–25 checks in flight. Lower it if you want gentler DNS traffic.

Leave emails empty and you get a single labelled _sample: true row showing the output shape. That row is free.

About the SMTP probe

With checkSmtp: true the actor opens TCP port 25 on the top-priority MX host and sends EHLO, MAIL FROM and RCPT TO. It never sends a message body.

Be realistic about it. Apify's own runners block outbound port 25, so in the cloud the probe never connects and mailboxVerified comes back null on every row — measured across eight mail hosts, including self-hosted ones. Run the actor locally and the probe works normally. Beyond that, the big providers deliberately refuse to confirm or deny a recipient even when you can reach them.

When the probe cannot reach a verdict the smtp object says inconclusive and the row keeps whatever the DNS evidence earned it. An inconclusive probe never gets upgraded into a deliverability claim.

The reply code decides which of those it is:

Reply	What it means	smtp.status
250 at RCPT TO	the server accepted this recipient	accepted
5xx at RCPT TO	the server permanently refused this recipient	rejected
5xx earlier	the server refused us, not the mailbox	inconclusive, server_refused_probe
4xx anywhere	temporary: greylisting, rate limiting, try later	inconclusive, temporary_failure

That last row matters more than it looks. Greylisting is the standard reply to an unfamiliar sender, and a greylisted address is usually a perfectly good one.

Limits

• DNS runs over DNS-over-HTTPS so cloud behaviour stays consistent; a DNS timeout returns mxFound: null and status: unknown rather than a false invalid.
• Catch-all domains are indistinguishable from working mailboxes over SMTP. They come back inconclusive.
• The disposable-domain list is built in. It's good, it isn't every throwaway service on earth.
• 25 concurrent checks is the ceiling.

Billing

Two charges. A $0.001 run-start fee each time a run begins, and a per-verification fee for every completed check.

Per verification it's $0.00199 ($1.99 per 1,000).

Sample rows, diagnostic rows, duplicates and runs that return nothing are never charged the per-verification fee. An invalid-syntax address is a completed check and is billed once. No residential proxy is involved, so nothing is metered by the gigabyte.

Responsible use

Only run addresses you're allowed to process. What comes back is a list-cleaning signal. It isn't consent and it isn't permission to send.