

Bulk verify email quality, identify valid, business, and risky emails, and improve contact data quality and outreach results.
Email Verification Tool turns a batch of email addresses into structured verification results in a single run. Paste your list, and each address is checked against a configured verification service for business/company/webmail type, format validity, disposable, catch-all, greylist and gibberish risk, plus a final sendability status — returned as clean rows you can filter, analyze, or load into your CRM.
Compared with testing addresses one by one in a browser tab, this makes verification repeatable, parallel, and exportable: the platform runs the batch with per-address concurrency, and every result comes back as structured data you can keep using.
| Field | What it tells you |
|---|---|
email | The address that was checked |
isValidFormat | Whether the address format is valid |
isBusinessEmail | Whether it is classified as a business email |
isCompanyEmail | Whether it is classified as a company email |
isWebmail | Whether it uses a free webmail provider |
isDisposable | Whether it comes from a disposable email provider |
isCatchall | Whether the domain appears to accept catch-all mail |
isGreylist | Whether the mailbox or server appears to use greylisting |
isGibberish | Whether the local part looks like gibberish |
sendStatus | Final sendability status from the verification service |
To make the most of a batch, Email Verification Tool gives you:
email field, so a large list verifies in parallel.The list of email addresses to verify — one address per line. This is the tool's only input.
Recommended: provide well-formed, real addresses and mix sources (a business mailbox, a webmail address) so you can see the type classification and risk flags work across cases.
Avoid addresses with stray spaces, no domain suffix, or a broken @ — those are rejected by the local format check before any request is made, so they never reach the verification service.
Format: one address per line, shaped like name@example.com. The local part and the domain must not start or end with a dot, and must not contain ..; surrounding whitespace is trimmed automatically.
The snippet below is the run input (the input.parameters.custom payload):
Results appear in a table with the 10 columns described above. You can sort, group, and filter — for example, keep only rows where sendStatus is valid.
isBusinessEmail, isCompanyEmail, and isWebmail classify the address — handy for telling B2B contacts apart from free-mail users before you route a campaign.
isValidFormat reflects whether the format is valid; sendStatus is the verification service's final sendability verdict (e.g. valid, invalid, unknown).
isDisposable, isCatchall, isGreylist, and isGibberish flag addresses that often cause deliverability trouble.
How does it work?
You paste a list of addresses. The worker validates each one's format locally, sends one GET request per address to the verification service configured for this worker, parses the response, and pushes one structured row per address. Requests use a fixed 300-second timeout, and only GET endpoints are supported.
Can I verify a large batch at once?
Yes. The email input is an array — add one address per line. The run is split on the email field (concurrency), so the platform verifies addresses in parallel. The script itself has no built-in cap; the practical ceiling is your list size and whatever limits your verification service applies.
How do I speed up verification?
Because concurrency is keyed on email, putting your whole list in a single run lets the platform verify addresses in parallel instead of serially. Keep the list in one run and stay within the verification service's rate limits. There are no optional enhancement switches to turn off — the levers are list size and upstream capacity.
What happens to malformed addresses?
They are skipped locally before any request. The worker rejects addresses that don't match name@example.com, or whose local part or domain starts or ends with a dot or contains ... Skipped addresses are logged, not sent to the verification service.
What if the verification service fails or times out?
One bad request doesn't sink the run. A network error, a timeout (300 seconds), or an upstream error (code != 0) is recorded for that address, and the rest still get verified. If every request fails, the run produces no rows. For safety, the worker never logs the upstream URL, credentials, or raw response contents.
What do the boolean flags mean?
They are the verification service's classifications, passed through one-to-one: type flags (isBusinessEmail, isCompanyEmail, isWebmail), risk flags (isDisposable, isCatchall, isGreylist, isGibberish), format (isValidFormat), and the final sendStatus. Exact semantics follow whichever service is configured — the worker does not reinterpret them.
Does it send test emails?
No. The worker only issues a GET request to the configured verification endpoint with each address as a query parameter. It does not send mail or trigger signups itself.
Can I integrate it with other apps?
Yes. Results export in 8 formats — CSV, JSON, JSONL, XLSX, XLS, XML, HTML, RSS — and the platform supports webhook callbacks, MCP, and n8n workflows.
Can I use it as an API?
Yes. Use the CoreClaw REST API to run it programmatically.
The base URL is https://openapi.coreclaw.com, all paths start with /api/v2, and you authenticate with Authorization: Bearer YOUR_API_KEY (the legacy api-key header and ?token= query still work).
Typical flow:
GET /api/v2/workers/{workerId}/input-schema to fetch the input schema (or GET /api/v2/workers/{workerId} for full details). workerId is a slug or owner~name path; version defaults to latest.POST /api/v2/workers/{workerId}/runs to start a run — pass is_async, and put the scraper input in input.parameters.custom. Set a callback_url to receive a callback instead of polling.data.run_slug.GET /api/v2/worker-runs/{runId} to check status (use the run_slug as {runId}).GET /api/v2/worker-runs/{runId}/result for the result, or /result/export for a file export.Is verifying email addresses legal?
Verifying addresses you legitimately own or collected with consent is common practice. Make sure you comply with the privacy and anti-spam regulations that apply to you (e.g. GDPR, CAN-SPAM) and with the terms of the verification service you use.
Found a bug, or want a new output field? We'd love to hear from you — reach out at support@coreclaw.com.