Email Verifier - Honest Deliverability Check

Give this Actor a list of email addresses and it tells you what is provably wrong with them, what looks risky, and — just as clearly — what it could not determine. One row of output is one address.

The honest part, up front

Real mailbox verification requires an SMTP conversation with the receiving mail server (RCPT TO). Port 25 is closed on the Apify platform. We measured it twice: once in an earlier run on the platform, and again while building this Actor.

So this Actor never tells you an address is valid, because it cannot know. Every record carries two fixed fields that say so:

"smtpChecked": false,
"mailboxVerified": null

The best verdict it will ever give is deliverable_domain — the domain accepts mail, the mailbox is unknown.

If you have seen another Apify email verifier return "smtp_valid": true or "reason": "SMTP mailbox exists", that claim cannot be produced from inside this platform. We would rather lose the comparison than repeat it.

What it does check

Check	What it proves
Syntax	Malformed addresses. Definitive.
MX records	Domain has no mail server → mail cannot be delivered. Definitive.
Disposable providers	Temp-mail services, checked before MX because their MX records usually work fine.
Role accounts	info@, support@, sales@ — flagged, never dropped.
Placeholder locals	someone@, test@, yourname@ — template-looking addresses, flagged, never dropped.
Free providers	Gmail, Outlook, Yahoo and friends.
Tagged addresses	john+newsletter@ — the tag is separated out.
Typos	gmial.com → gmail.com.
Mail provider	Google Workspace, Microsoft 365, Zoho, Proton…

That last one is not in any competing Actor's output, and it costs nothing extra: the provider is already inside the MX records we fetched.

Status values

Status	Meaning
invalid_syntax	Not an email address. Certain.
no_mx	The domain has no mail server. Certain: mail cannot be delivered.
disposable	A temporary-mail provider.
deliverable_domain	The domain accepts mail. The mailbox was not checked.
unknown	The DNS lookup failed, or MX checking was turned off. No information.

unknown matters more than it looks. A DNS timeout is not the same as "no mail server", and treating it as one would make you delete a working address. Those two outcomes are kept apart on purpose.

Score

Every record has a score from 0 to 100. It is a judgement, not a measurement — a convenience for sorting. The reasons array is the honest version: it lists every individual finding (syntax_ok, mx_ok, role_account, possible_typo, disposable_provider, mx_lookup_failed, …) so you can apply your own rules.

Input

Field	Default	What it does
emails	—	The addresses to check
inputDatasetId	—	Read addresses from another Actor's dataset instead
emailField	email	Which field holds the address (dotted paths work)
checkMx	true	Look up mail servers. One DNS query per domain, cached
suggestTypos	true	Suggest fixes for near-misses of common providers
skipInvalidSyntax	false	Leave malformed addresses out of the results
incremental	false	Skip addresses this task already returned
previewOnly	false	Report what would be billed, check nothing

inputDatasetId chains this Actor onto anything that produces emails — including a scraper run from an earlier step in the same workflow.

Output

{
  "email": "john@stripe.com",
  "input": "  John@Stripe.COM  ",
  "normalized": true,
  "domain": "stripe.com",
  "localPart": "john",
  "tag": null,
  "status": "deliverable_domain",
  "score": 85,
  "reason": "domain_accepts_mail",
  "reasons": ["syntax_ok", "mx_ok", "mx_provider_known"],
  "syntax_valid": true,
  "domain_exists": true,
  "mx_found": true,
  "mx_records": ["aspmx.l.google.com"],
  "mxProvider": "Google Workspace",
  "is_disposable": false,
  "is_role_based": false,
  "is_free_provider": false,
  "is_placeholder": false,
  "has_tag": false,
  "did_you_mean": null,
  "smtpChecked": false,
  "mailboxVerified": null,
  "verified_at": "2026-08-16T12:00:00.000Z",
  "contentHash": "…"
}

Field names in the first group match the widely used email verifiers on Apify, so an existing spreadsheet, Make scenario or Zapier step keeps working. The extra fields are additions, not replacements.

Billing

One event: email-verified, charged per delivered record.

Never billed:

• malformed addresses (syntax is checked before anything is charged)
• addresses skipped by incremental mode
• anything at all in preview mode

Speed and cost

MX lookups are one DNS query per domain, cached for the whole run — a list of 1,000 addresses across 150 domains does 150 lookups, not 1,000. On the platform a lookup takes single-digit milliseconds. No proxy, no browser, nothing is scraped.

Frequently asked

Why won't it just say valid or invalid? Because from inside this platform that would be a guess wearing a confident label. What can be proven is proven; what cannot is reported as unknown. You get the underlying findings and decide your own threshold.

Can it detect catch-all domains? No. That requires SMTP, so instead of returning a fabricated catch_all field, it returns none.

Is no_mx reliable enough to delete an address? Yes — that is the one negative this Actor is confident about. A domain with no MX record cannot receive mail. Note it is distinct from unknown, which means the lookup itself did not succeed.

Does it send email? No. Nothing is sent, and no mailbox is contacted.

Why is test@mycompany.com not reported as malformed? Because it isn't. It looks like a placeholder, and that is worth knowing, so it comes back with is_placeholder: true — but calling valid syntax "invalid" would make you delete an address that may well be someone's real inbox. Flags describe; they do not decide for you.

What does mxProvider distinguish? Consumer mailboxes from business ones. gmail.com resolves to Gmail's consumer servers and is reported as Gmail; a company on Google Workspace resolves to different servers and is reported as Google Workspace. Same company, different products, and for outreach the difference matters.