Email Verify — syntax, MX, disposable & role detection

Clean an email list before you send to it. Give the Actor a list of addresses; get back a row per address with a 0–100 deliverability score and the reasons behind it.

No API key. No account with a third-party verification vendor. Runs on your Apify account.

What it checks

Check	What it catches
RFC 5322 syntax	Typos, missing TLDs, doubled @, leading/trailing dots, over-length local parts
MX records	Domains that cannot receive mail at all — the single biggest source of hard bounces
Disposable domains	60+ throwaway providers (Mailinator, Guerrilla Mail, 10MinuteMail, YOPmail …)
Role accounts	admin@, info@, support@, noreply@ and 30+ others — deliverable, but they hurt engagement rates and often trip spam filters

Output

One dataset row per address:

{
  "email": "support@apify.com",
  "valid": true,
  "score": 55,
  "syntaxValid": true,
  "domain": "apify.com",
  "isDisposable": false,
  "isRoleAccount": true,
  "mxValid": true,
  "mxRecords": ["aspmx.l.google.com (priority: 1)"],
  "reason": null,
  "checkedAt": "2026-07-27T17:20:00.000Z"
}

A SUMMARY record is written to the key-value store with totals for valid, bad-syntax, no-MX, disposable and role addresses.

How the score works

• 0 — syntax is invalid. Nothing else is checked and no DNS query is made.
• 10 — syntax is fine but the domain has no MX records. It cannot receive mail.
• 70 — baseline for a syntactically valid address on a domain that accepts mail.
• −40 disposable domain · −15 role account
• ±30 if the optional SMTP probe runs and the mailbox is accepted / rejected

valid is true when the domain has MX records, the domain is not disposable, and the score is at least 50. Role accounts stay valid but score lower — they are genuinely deliverable, so the decision to keep them is yours.

Input

{
  "emails": ["support@apify.com", "someone@mailinator.com", "bad@@format"],
  "checkSmtp": false,
  "maxConcurrency": 10
}

• emails (required) — addresses to verify. Wire this to another Actor's output to clean scraped leads in place.
• checkSmtp — see the honest limitation below. Default false.
• smtpTimeoutMs — per-address SMTP timeout. Default 10000.
• maxConcurrency — parallel DNS resolutions, 1–50. Default 10.

Honest limitations

Read this before you rely on the output.

SMTP mailbox probing is off by default and will usually not work in the cloud. Outbound port 25 is blocked on most cloud networks, Apify's included. With checkSmtp: true you will typically get smtpReached: false — which tells you nothing about the mailbox. The option exists for self-hosted runs where port 25 is open. It is not a defect in the Actor; it is how cloud networking works, and any tool claiming reliable cloud-side SMTP verification is either using a relay service or is not doing what it says.

Even a working SMTP probe is not proof. Many servers accept every RCPT TO and bounce later (catch-all). Greylisting returns a temporary 4xx on first contact. Treat smtpAccepted: false as a signal, never a verdict.

This does not detect catch-all domains, spam traps, or whether a human still reads the mailbox. It removes addresses that provably cannot receive mail, plus the two categories that most reliably damage sender reputation. That is the large majority of list rot, and it is what it claims to do — nothing more.

The disposable-domain list is static. New throwaway providers appear constantly. It covers the well-known ones and is not exhaustive.

Typical use

1. Scrape or export leads.
2. Run this Actor over the address column.
3. Drop valid: false, and decide separately whether you want isRoleAccount: true.
4. Send.

Cutting hard bounces protects your sending domain's reputation, which is far more expensive to repair than to preserve.

Local development

npm install
node --test test.mjs      # 14 tests, no network required

The verification logic lives in lib.js with injectable DNS and SMTP dependencies, so the suite runs fully offline.

MIT licensed.