Validate email lists before outreach with syntax checks, public domain mail-server checks, disposable-domain flags, role-account detection, and a simple deliverability risk score.
Use this Apify Actor when you have a lead list, recruiting list, newsletter export, CRM upload, or enrichment dataset and want to quickly separate safer emails from risky ones before sending campaigns.
What does Email MX & Deliverability Verifier do?
Email MX & Deliverability Verifier checks each email address you provide and returns a structured dataset with the most useful deliverability signals.
It can:
- ✅ Normalize and deduplicate email addresses
- ✅ Detect invalid email syntax
- ✅ Parse the mailbox domain
- ✅ Check whether the domain has MX mail records
- ✅ Check an A-record fallback when no MX record is present
- ✅ Flag common disposable or temporary email domains
- ✅ Flag role accounts such as
info@,support@, andadmin@ - ✅ Assign a practical risk level:
low,medium,high, orunknown - ✅ Add a clear verification outcome:
READY,RISKY,INVALID, orUNKNOWN - ✅ Return machine-readable reason codes for filtering and automation
- ✅ Save a run summary with completed and pending work when a bounded run ends early
Who is it for?
This actor is useful for teams that work with email lists regularly.
- 📈 Sales teams can clean prospect lists before sending sequences.
- 🧲 Lead generation agencies can add validation signals to scraped or purchased leads.
- 👥 Recruiters can check candidate contact lists before outreach.
- 🛒 E-commerce operators can audit customer or partner exports.
- 🧪 Data enrichment teams can add email-quality columns to downstream workflows.
- 🧰 No-code operators can validate lists from Apify datasets, CSV exports, or pasted text.
Why use it?
Bad email lists waste time, damage sender reputation, and create noisy CRM data.
This actor gives you fast, explainable checks that are easy to export and combine with other data. It does not claim that an inbox exists, but it helps identify addresses that are clearly malformed, risky, disposable, role-based, or attached to domains without visible mail routing.
What checks are included?
The first version focuses on safe public signals.
- Syntax validation
- Domain extraction
- MX record check
- Optional A-record fallback check
- Disposable-domain check
- Role-account check
- Risk-level assignment
- Reason-code output
What is not included?
This actor does not log into email providers and does not require private credentials.
It also does not perform mandatory SMTP mailbox probing in version 1. SMTP probing can be slow, blocked by mail servers, inaccurate due to catch-all domains, and potentially intrusive at scale. The actor instead focuses on stable public signals that are suitable for batch workflows.
Data returned
| Field | Description |
|---|---|
email |
Original email string after trimming |
normalizedEmail |
Lowercase normalized email when syntax is valid |
validSyntax |
Whether the address has valid email syntax |
domain |
Parsed domain from the address |
mxFound |
Whether MX mail records were found |
mxRecords |
MX records with priority and exchange host |
aRecordFallbackFound |
Whether an A record exists when no MX was found |
isDisposable |
Whether the domain is a known temporary mailbox provider |
isRoleAccount |
Whether the mailbox is a role account |
riskLevel |
low, medium, high, or unknown |
outcome |
Plain outcome: READY, RISKY, INVALID, or UNKNOWN |
reasonCodes |
Machine-readable reasons such as MX_FOUND or INVALID_SYNTAX |
error |
A safe, actionable message when verification could not finish for that row; otherwise null |
checkedAt |
ISO timestamp for the check |
Input settings
| Setting | JSON key | Type / default | Description |
|---|---|---|---|
| Email addresses | emails |
array, default ["support@example.com","sales@gmail.com","bad-email","test@mailinator.com"] |
Paste email addresses to validate. Duplicates are normalized and checked once per run. |
| CSV or pasted text | csvText |
string | Optional pasted CSV, newline, comma, semicolon, or whitespace separated email list. |
| Input dataset ID | datasetId |
string | Optional Apify dataset ID to read email addresses from. |
| Dataset email field | datasetEmailField |
string, default "email" |
Field name containing email addresses when datasetId is used. |
| Check MX records | checkMx |
boolean, default true |
Look up public DNS MX records for each valid email domain. |
| Check A-record fallback | checkARecordFallback |
boolean, default true |
If no MX record exists, check whether the domain has an A record as a weak fallback signal. |
| Flag disposable email domains | includeDisposableCheck |
boolean, default true |
Flag common temporary or disposable mailbox providers. |
| DNS provider | dnsProvider |
string, default "google" |
DNS-over-HTTPS provider. Google is currently supported. |
| Maximum concurrency | maxConcurrency |
integer, default 20 |
Number of email addresses to verify in parallel. Keep low for small test runs. |
| Work budget | maxRuntimeSecs |
integer, default 270, range 60–270 |
Time available for DNS work before the Actor saves completed rows and stops starting new checks. |
| Runtime safety margin | runtimeSafetySecs |
integer, default 30, range 30–120 |
Time reserved for saving completed rows and the run summary. Keep this lower than maxRuntimeSecs. |
Input options
You can provide email addresses in three ways.
emails— a direct array of email strings.csvText— pasted text containing email addresses separated by commas, semicolons, spaces, tabs, or new lines.datasetId— an Apify dataset ID plus the field name that contains emails.
You can combine these options in one run. Duplicates are normalized and checked once.
Example input
{
"emails": [
"support@example.com",
"sales@gmail.com",
"bad-email",
"test@mailinator.com"
],
"csvText": "example",
"datasetId": "example",
"datasetEmailField": "email",
"checkMx": true,
"checkARecordFallback": true,
"includeDisposableCheck": true,
"dnsProvider": "google",
"maxConcurrency": 20,
"maxRuntimeSecs": 270,
"runtimeSafetySecs": 30
}
How to run it
- Open the actor on Apify.
- Paste a few email addresses into the input.
- Keep the default checks enabled.
- Start the run.
- Open the dataset when the run finishes.
- Filter by
riskLevel,validSyntax,mxFound, orreasonCodes. - Export the results to CSV, JSON, Excel, or API.
Output example
{
"email": "support@example.com",
"normalizedEmail": "support@example.com",
"validSyntax": true,
"domain": "example.com",
"mxFound": true,
"mxRecords": [
{ "priority": 0, "exchange": "." }
],
"aRecordFallbackFound": false,
"isDisposable": false,
"isRoleAccount": true,
"riskLevel": "medium",
"outcome": "RISKY",
"reasonCodes": ["ROLE_ACCOUNT", "MX_FOUND"],
"error": null,
"checkedAt": "2026-07-03T00:00:00.000Z"
}
Understanding risk levels
low means the address syntax is valid, the domain has mail routing, and no major risk flags were detected.
medium means the address may still be usable, but it has a caution flag such as a role mailbox or weak fallback domain evidence.
high means the address is clearly invalid, disposable, or attached to a domain without useful mail-routing signals.
unknown means a DNS check failed, so the actor could not confidently classify deliverability.
Tips for better results
- Start with 10–20 emails to confirm your workflow.
- Use
datasetIdwhen validating output from another Apify actor. - Keep
checkMxenabled for most production runs. - Keep
includeDisposableCheckenabled for lead-gen lists. - Treat
riskLevelas a filtering signal, not a legal or compliance decision. - Review
reasonCodeswhen building automated rules.
Integrations
You can use the results in common automation workflows.
- Export to Google Sheets or Excel for manual review.
- Feed low-risk emails into CRM import workflows.
- Send high-risk rows to a cleanup queue.
- Combine with lead scrapers to validate contacts before sales outreach.
- Use Apify webhooks to trigger the next step after a run succeeds.
- Read the dataset from the Apify API in your backend.
API usage
Run Email MX & Deliverability Verifier from your own code with the Apify API.
Node.js
import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const input = {
"emails": [
"support@example.com",
"sales@gmail.com",
"bad-email",
"test@mailinator.com"
],
"csvText": "example",
"datasetId": "example",
"datasetEmailField": "email",
"checkMx": true
};
const run = await client.actor('fetch_cat/email-mx-deliverability-verifier').call(input);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);
Python
from apify_client import ApifyClient
import os
client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("fetch_cat/email-mx-deliverability-verifier").call(run_input={
"emails": [
"support@example.com",
"sales@gmail.com",
"bad-email",
"test@mailinator.com"
],
"csvText": "example",
"datasetId": "example",
"datasetEmailField": "email",
"checkMx": true
})
items = client.dataset(run["defaultDatasetId"]).list_items().items
print(items)
cURL
curl -X POST "https://api.apify.com/v2/acts/fetch_cat~email-mx-deliverability-verifier/runs?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"emails":["support@example.com","sales@gmail.com","bad-email","test@mailinator.com"],"csvText":"example","datasetId":"example","datasetEmailField":"email","checkMx":true}'
Use with AI agents via MCP
Email MX & Deliverability Verifier can be used by AI assistants through the hosted Apify MCP server.
Claude Code setup
claude mcp add --transport http apify "https://mcp.apify.com?tools=fetch_cat/email-mx-deliverability-verifier"
Claude Desktop, Cursor, or VS Code JSON config
{
"mcpServers": {
"apify": {
"url": "https://mcp.apify.com?tools=fetch_cat/email-mx-deliverability-verifier"
}
}
}
Example prompts
- "Run Email MX & Deliverability Verifier with this input JSON and summarize the dataset."
- "Export the latest Email MX & Deliverability Verifier results to a table I can review."
- "Schedule this Actor for monitoring and tell me what changed between runs."
Limits and reliability
The actor checks public signals and is suitable for batch workflows.
Very large runs depend on the number of email addresses and current DNS response times. The Actor saves completed rows progressively. If the work budget is reached, RUN_SUMMARY records the number of pending addresses and a resumeInput payload you can use for the remaining work. If you see UNKNOWN outcomes or unknown risk levels, retry those rows later or lower concurrency.
Legality and responsible use
Only validate email addresses you are allowed to process. Follow applicable privacy, anti-spam, and data-protection laws, including rules for consent, retention, and outreach.
This actor provides technical validation signals. You remain responsible for how you use the data.
Support
Report bugs, wrong output, blocked runs, or missing fields from the Actor page. Include the Apify run ID or run URL, your input JSON, what you expected, what the Actor returned, and one reproducible public URL so the issue can be tested quickly.
Privacy and data handling
This Actor only requests the permissions needed to run the input you provide. It uses your input (such as URLs, search terms, identifiers, filters, and limits) only to fetch the requested public data from the relevant source site or API for this Actor, then writes results to your Apify dataset/key-value store.
Data may pass through Apify platform services and Apify Proxy during the run, and requests are sent only to the target site or public data provider required for this Actor's results. FetchCat does not send your inputs or outputs to advertising networks, data brokers, or model-training services, and does not retain run data outside Apify storage after the run except when you explicitly share run details for transient support debugging.
You are responsible for using this Actor lawfully, respecting the target site's terms, and avoiding unnecessary personal or sensitive data in inputs. Review the output before storing, sharing, or combining it with other data.