Bulk Email Hygiene & MX Validator

Clean email lists before importing them into a CRM or permission-based campaign. The Actor accepts pasted addresses, JSON items, or an Apify dataset and returns one evidence-rich row per input.

What it checks

• deterministic email syntax and length limits
• international domain conversion to ASCII/Punycode
• MX records and the standards-compatible A/AAAA fallback
• explicit Null MX domains that accept no email
• disposable email domains
• common role accounts such as info, sales, and support
• common free email providers
• common provider-domain typos with a suggested correction
• duplicate addresses with the first source-row reference

Honest boundary

This Actor does not send email or connect to recipient mail servers. It does not claim that a mailbox exists, that a message will reach an inbox, or that an address is safe to contact. valid_domain means the syntax is valid and the domain publishes mail-receiving evidence. Temporary DNS failures are unknown, never silently converted to invalid.

Use only email data you are authorized to process. Compliance with consent, anti-spam, privacy, suppression, and outreach rules remains the user's responsibility.

Input

Choose exactly one source:

1. emails: one address per row.
2. items: JSON objects containing the field selected by emailField.
3. datasetId: a dataset in the current Apify account.

The Actor processes at most maxItems rows. Both source truncation and spending-limit truncation are explicit in the OUTPUT summary.

Output statuses

• valid_domain: syntax passed and MX or fallback address evidence exists.
• risky: domain evidence exists, but the address is disposable, role-based, or contains a likely provider typo.
• invalid: syntax failed, the domain explicitly accepts no email, or it has neither MX nor fallback address records.
• unknown: the DNS answer was temporarily unavailable or timed out.

Every dataset row includes mailboxChecked: false and the claim boundary so downstream automations cannot mistake domain hygiene for mailbox verification.

Pricing design

The intended Store model is pay per event with one visible email-checked event per emitted dataset row and a small Actor-start event. No paid third-party API is used. Platform usage should be passed through or priced with enough margin to avoid owner-funded runs.

Privacy and security

• Input email addresses are read from the run's own Apify storage.
• No recipient is contacted and no email is sent.
• No paid verification API, tracking service, analytics endpoint, or vendor-operated remote backend receives the list.
• Logs contain only aggregate counts and settings, not individual email addresses.
• The run dataset contains the user's requested row-level results; Apify storage retention and deletion controls apply.

Automation

After publication, Apify provides Store discovery, input UI, API/MCP access, execution, storage, metering, billing, and payout records. Ongoing work is limited to evidence-based maintenance and support.