Short answer: bulk email verification means uploading a list file and getting it back annotated with a status for every row, rather than checking addresses one at a time. At 10,000 addresses a minute, a one-million-record list finishes in under two hours. The work that decides whether it was worth doing happens after the file comes back.
Before you upload
Verification is billed per address, so every duplicate is money you set on fire. Three steps first:
- Deduplicate. Lowercase everything first –
Sarah@Acme.comandsarah@acme.comare one mailbox. Decide how you treat Gmail dots and plus-addressing, sinces.chen@gmail.comandschen+news@gmail.comboth land in the same inbox. - Keep your columns. Export signup date, source, last open and last click alongside the address. The verifier returns a technical status; those columns are what let you make the judgement calls it cannot.
- Pull everything, not just the active segment. The damage usually lives in the parts of the database nobody looks at – an old trade show import, a list inherited from a predecessor, a form that never had validation on it.
Throughput and what it depends on
Bulk verification is not CPU-bound. It is bound by how fast receiving mail servers will talk to you. Large providers throttle aggressively, so real throughput depends on how many source IPs the service runs and how well it paces requests across them.
At 10,000 addresses a minute: 250,000 records in roughly 25 minutes, one million in under two hours. A service that is much slower than that is usually working from a thin IP pool, and a thin pool produces a second symptom – a high unknown rate, because throttled checks return no definitive answer.
Watch the unknown percentage in your results. It is the honest measure of engine quality, and you may be re-paying to check those rows later.
What comes back
| Status | Typical share | Action |
|---|---|---|
| Valid | 75-90% | Mail normally |
| Invalid | 5-15% | Delete and suppress permanently |
| Catch-all / risky | 3-25% | Segment, test in small batches |
| Unknown | 1-5% | Retry in a few days, then treat as risky |
| Disposable / role | 1-5% | Delete disposables, judge role addresses by use case |
The catch-all share swings hardest by audience. A consumer list dominated by Gmail, Outlook and Yahoo will show almost none. A B2B list built from small-company domains can run 20-30%, and how you handle that segment will matter more than anything else in the file.
Acting on a million-row result
Do not re-upload the cleaned file as a replacement list. Do this instead:
- Suppress, do not delete. Add every invalid address to a permanent suppression file. Deleting a record means a future import can reintroduce it, and mailing an address a provider already told you does not exist is one of the loudest bad-sender signals there is.
- Create a catch-all segment and leave it out of your main sends until it has earned its way back in.
- Layer engagement rules on top. An address can be perfectly deliverable and still be dead weight. No opens in 12 months on a monthly cadence goes to re-engagement, then suppression.
- Purge by source. If part of the list came from a purchase or a scrape, delete that segment whole. Verification does not make it safe – the traps and complaints survive.
- Fix capture so you are not repeating this in six months. Real-time API verification on signup forms stops bad addresses entering at all.
When to run a bulk pass
- Quarterly for most senders.
- Monthly if you send several times a week or run high-volume outbound.
- Before any list that has sat untouched for 90 days gets mailed again.
- Before migrating to a new ESP or sending domain. This is the most commonly skipped and most expensive omission – new sending infrastructure has no reputation to spend, and opening with a bounce-heavy send starts you in a hole.
Clean at volume: 250,000 emails for $100, one million for $350, two million for $720. CSV, TXT, TSV or XLSX in, the same columns back with a status on every row. Start with 100 free credits.
Leave a Reply