Most email lists rot quietly. Addresses are mistyped at capture, domains lapse, people leave companies, and a share of every list was disposable from the moment it was collected. None of that is visible until a send goes out and the bounce rate does the telling.
This validator reads a list and separates what is provably bad from what is worth sending to. It checks syntax, resolves the domain and its mail exchange records, recognises disposable providers and role accounts such as info@ or sales@, and marks free-provider addresses. Every address comes back with a 0 to 100 send-risk score, a recommended action, and the reason codes behind both.
It needs no API key and sends no mail. Duplicates are removed before validation, so a list with repeats is not charged twice for the same address.
Inputs
- emailsarray
- Addresses to validate, passed directly.
- csvUrlstring
- Link to a CSV file. The email column is detected automatically.
- inputDatasetIdstring
- The dataset from a previous Actor run. This is what lets the validator sit downstream of any tool that produces addresses.
- emailFieldstring
- Column name, for the cases where automatic detection cannot tell which column holds the address.
- concurrencyinteger
- How many addresses are checked in parallel.
Outputs
- decisions
- One row per address: score, action, reason, status and flags. The view to export straight to a sending tool.
- results
- Every column, including provider, DNS findings and full reason codes.
- evidence
- The individual signals behind each decision, for when a verdict needs to be explained rather than trusted.
- summary
- Run statistics and counts by recommended action.
- 31 fields per address
- Including the signals individually (syntax, DNS, MX, catch-all), the reason codes, and the engine, score and policy versions that produced the verdict. Versioning the decision is what makes a result from today comparable with one from six months ago.
Delivered as Apify dataset, CSV URL, dataset from a previous run.
What it does not do
It does not confirm that an individual mailbox exists. That is a design choice and a platform fact at once: mailbox probing is unreliable and is treated as abusive by many providers, and Apify blocks outbound port 25 in any case, so no run on the platform can attempt it.
It therefore removes only addresses that are provably bad. An address that survives validation is plausible, not guaranteed deliverable, and the score says so rather than rounding up.
Deep mode and SMTP probing appear in the input schema but have no effect on Apify. Every row comes back with smtp_probing_used set to false.
It does not send mail, and it does not warm domains or manage sending reputation.
Where it is used
- Cleaning a purchased or inherited list before the first send, when bounce rate is the thing that decides whether a domain stays deliverable.
- Running downstream of a scraper or lead finder, so contact data is qualified in the same pipeline that collects it.
- Auditing an existing CRM segment to find how much of it has decayed since it was captured.
- Calling it from an agent, so an address is validated mid-task rather than handed to a human as a list to check.
Can be composed with
- YouTube Creator Finder produces email addresses, which this accepts as an input.
These are separate programs. Neither calls the other, and this one works on its own. A composition is something you or an agent wire up, not something that happens behind the scenes.
From an agent
It runs as an Apify Actor, so any MCP client can call it through Apify's hosted server at mcp.apify.com. Nothing extra was built for this. It is not loaded by default, so an agent either finds it through Apify's search tool or is given the name:
salomon-dot-labs--bulk-email-validator
The description a model reads before deciding to call it is the same sentence that heads this page. Every input listed above is optional, so a model can start it with far less than a full configuration.
Worth knowing when you wire it up: the call returns a pointer rather than the rows. An agent gets the dataset id, the item count and the available field names, then fetches the results in a second step. That is how Apify exposes every Actor, not something particular to this one, and it means budgeting two round trips per answer.
It runs on Apify. Inputs, output schema and pricing are all on the listing, and a run can be started from the browser without writing any code.
Open on Apify