Email list cleaning service with a bulk verification API

What an email list cleaning service checks

Email list cleaning, email list validation and email list verification are three names for the same job: run every address on a list through the checks a mail server would apply, and mark the ones you should not send to. Each unique address on your list gets the same checks as a single request to the email validation API:

Swipe sideways to see the whole table →

Duplicates are checked once and repeat that result in every row where they appear. Rows without a valid address are kept and marked undeliverable with the reason invalid_format, so your file comes back with the same rows in the same order.

How a list cleaning job works

1. Submit the list with POST /v1/bulk: a CSV or TXT file, or a JSON array of addresses. The answer is the job, with status queued.
2. Wait for the webhook, or check GET /v1/bulk/{job_id} about once a minute until its status is completed. Checking a job is free. On the free plan, which allows 10 requests a minute, a submitted list counts against that minute’s limit too, so wait until the next minute before you check the job (details).
3. Download the results with GET /v1/bulk/{job_id}/results: as CSV, with your columns plus the emailvalidation_* columns, or as JSON.
4. Delete the job with DELETE /v1/bulk/{job_id} once you have the results, or let it expire 30 days after it finished.

Worked example: cleaning a list of 10,000 addresses

The numbers below are made up to show the arithmetic. They are not results from a customer list or from our own data.

Say you export 10,000 contacts from a CRM. In the export, 180 rows repeat an address that already appears in an earlier row (some with different capitalization), and 20 rows hold something in the email field that is not an address. That leaves 9,800 unique, valid addresses.

Swipe sideways to see the whole table →

Now assume the job comes back like this:

Swipe sideways to see the whole table →

Before cleaning: sending to all 9,800 addresses would have produced 588 hard bounces, a bounce rate of 588 ÷ 9,800 = 6.0%. Those addresses don’t exist, so every send to them bounces again.

After cleaning: you send to the 8,950 addresses with the reason valid_mailbox, and the 588 known hard bounces are gone before the first message goes out. Some bounces remain possible: a mailbox can be closed after the check, and temporary failures and blocks do not show up in any check (see the bounce checker section below).

Cost: 9,800 requests. That fits in one month of the Medium plan (25,000 requests for $34.99), but not in the Small plan (5,000). The 200 rows that were duplicates or not addresses cost nothing, and addresses left unknown are refunded when the job completes (within a fair-use allowance).

Email scrubbing and list hygiene

“Email scrubbing” usually means more than verification. Verification tells you which addresses can receive mail. List hygiene also covers who should still get your mail. Mailbox providers ask for both: Yahoo’s sender best practices say to monitor hard and soft bounces and inactive recipients and to “remove invalid recipients from your list promptly”, and Microsoft’s Outlook.com postmaster policies say a sender must stop sending to a recipient after multiple non-delivery responses (both checked October 9, 2026).

Swipe sideways to see the whole table →

Verification can’t tell you whether someone still wants your mail, and it can’t reliably find spam traps: a trap is a working mailbox, so it passes a mailbox check. Removing long-inactive subscribers and using confirmed opt-in is what protects you there. The email deliverability guide covers the rest of the picture, and the Gmail, Yahoo and Outlook sender requirements list what the big mailbox providers enforce.

Email list bounce checker: what verification catches

Used as an email list bounce checker, verification finds the addresses that would cause hard bounces: mailboxes that don’t exist, domains without mail servers and malformed addresses. It cannot predict:

• Soft bounces, such as a full mailbox or a receiving server that is down on the day you send. They are temporary.
• Blocks, where the receiving server rejects your message because of your authentication, reputation or content. The address is fine; your setup is the problem.
• Catch-all domains, which accept every address during the check. Addresses on domains we already know to be catch-all come back as deliverable with the reason low_deliverability. To get the catch_all flag as well, ask for the catch-all test (catch_all=1, plans from Small). Read how to handle catch-all addresses.

The email bounce rate guide shows how to calculate your rate and what moves it.

What a job costs

• Charged when you submit: one request of your quota per unique, valid address. Addresses are compared without regard to case and surrounding spaces, so Anna@Example.com and anna@example.com count once. The X-Cost header and quota.charged show the amount.
• Free: duplicates, rows without a valid address, and checking, listing, downloading and deleting jobs.
• Refunded: addresses left unknown, when the job completes: always when the cause was a failure on our side, otherwise within a fair-use allowance (20% of your monthly quota per day, 30% per month, shared with single checks). Deleting a job refunds the addresses not checked yet, and a failed job is refunded. Refunds go back to your current quota and cannot raise it above its monthly size, so a refund after your quota has reset gives back at most what you have used since the reset.
• Checked first: a list is only accepted if your quota has at least as many requests left as the list costs. Otherwise the API answers 429 with the number of requests the job needs, before anything is stored or checked.

Files and limits

Swipe sideways to see the whole table →

A header row is detected. The address column is the one you name with email_column (its title or its number); without it, the API uses the column titled like email, and otherwise the column with the most addresses in the first 100 rows. The CSV and TXT rules are in the documentation.

Your list and your data

• Lists and results are encrypted with AES-256 before they are stored, on top of our storage provider’s encryption at rest. While a job runs, its addresses are kept encrypted in our database, and they are deleted from it when the job finishes.
• The results are only available through the API, with an API key of your account. There are no public download links, and the webhook carries the job’s status and counts, never addresses or results.
• The stored list and the results of a job are deleted 30 days after the job finished, or right away when you delete the job.
• The webhook is signed with HMAC-SHA256 and a secret for each job, goes only to https URLs on public hosts, and is sent in up to 6 attempts over about 2.5 hours until your endpoint answers with a 2xx status. See Webhooks.

Email list cleaner: free tool, dashboard or API?

• A few addresses, no account: the free bulk email verifier on this site, which checks a few addresses an hour.
• A file now and then, no code: upload it in the emailvalidation.io dashboard.
• Recurring lists, automation, up to 100,000 rows: the bulk API on this page, with webhooks and results in your own column layout. The same job runs from a cron script, a CRM integration or an AI agent through the MCP server.

To keep CRM and store contacts clean between list jobs, check each new address as it arrives: see the guides for HubSpot contact verification, Salesforce email validation and Shopify customer emails.

Test without using your quota

Sandbox keys (Medium plan and up) work with bulk jobs. A sandbox job is free, accepts up to 1,000 rows and never contacts a mail server: the documented test addresses get their made-up results, and every other address is deliverable. Its webhook is signed like a live one, so you can test your receiver before you send a real list.