Bulk Email Deliverability Check — MX, SPF, DMARC

Check a list of email addresses at the domain level: MX records, SPF policy strength, DMARC enforcement, disposable providers, free-mail domains, role accounts and syntax. Every result states plainly that no SMTP connection was made, so a clean address means the domain can receive mail and is not a claim that a specific mailbox exists. Built by PAOE.

Each item is processed individually and charged as its own event, so you pay only for what the run actually delivers. Results are written to the run's dataset as one JSON object per item, ready to download as JSON, CSV or Excel, or to pull through the Apify API.

What it checks

For each address: syntax and local-part validity, whether the domain publishes MX records and can receive mail at all, whether it is a null MX that refuses all mail, SPF policy strength (including +all, which authorises the whole internet), DMARC enforcement level, whether the domain is a disposable/throwaway provider, whether it is a free consumer mail provider, and whether the address is a shared role account such as info@ or sales@.

Pricing

Event	What it covers	Price
email-checked	email checked (primary)	$0.01 per event

Volume tiers reduce the price automatically on higher Apify plans: Bronze 15% off, Silver 25% off and Gold or above 40% off the listed free-tier price. The charge is per item processed, not per run.

Input

Field	Type	Required	Default	Description
addresses	array	yes	["someone@example.com"]	Addresses to check. Accepts one per line, or comma-separated in a single string. Each address checked is one charged event.
maxAddresses	integer	no	500	Hard cap on how many addresses are checked in one run.

Example input:

{
  "addresses": [
    "someone@example.com"
  ],
  "maxAddresses": 500
}

Output

One JSON object per item in the run's dataset. Every result carries the input it came from plus the fields this Actor measures, so the output can be joined back to your own data without guessing which row is which. The final dataset entry is a summary object with the run's totals.

Typical use cases

• Clean a lead or signup list before sending, to cut bounces.
• Separate business domains from free-mail and disposable addresses.
• Find role accounts that should be replaced with a named contact.

Limitations

No, and it never claims to. The checks are domain-level and rely on DNS, not an SMTP conversation, so no individual mailbox is probed. A clean result means the domain can receive mail and its policy is sane. Every record states this in a note field and the summary reports verification_level: domain_and_syntax with mailbox_probed: false, so a downstream system cannot mistake the result for mailbox verification. DKIM is not checked, because that needs a selector DNS cannot guess.

Does it confirm a specific mailbox exists?

Every limitation above is reported per item in a findings entry with a level of fail, warn, info or ok, a machine-readable code and a concrete action. If something cannot be checked it is reported as such rather than assumed to be fine.

Can it run on a schedule?

Yes. Save a task from this Actor with your inputs, then set a schedule on the task. Scheduled runs recur with the same inputs, which is the intended way to use it for ongoing monitoring.

Why not just open an SMTP connection?

SMTP probing from a shared cloud IP is unreliable and often blocked, and a false negative would wrongly discard a good address. These checks are deterministic and reproducible, and the output says exactly what was and was not verified.

Notes

If a site returns something unexpected, open an issue on the Actor's page with the URL and the input used, and it will be looked at.

Related Actors

• Domain & HTTPS Security Audit

Keywords

email verifier, email validation, MX record check, SPF check, DMARC check, disposable email detection, bulk email cleaner, lead list cleaning.