How fast is bulk email verification?

Published turnaround for 100,000 addresses, read on each vendor's own site on 2026-09-24, runs from 7 minutes at Emailable to 45 to 60 minutes at ZeroBounce and under 2 hours at DeBounce. Each figure describes that vendor's test file, not yours. Two lists of the same size can finish hours apart.

A run has two stages with very different costs. DNS lookups are cached per domain, so 10,000 addresses across 400 domains need only 400 queries, and that part is close to instant. Our page on bulk verification shows what goes in and what comes back.

The SMTP stage is where the time goes. Each check is a network round trip to someone else's mail server, run in parallel across domains but held to a few at a time per domain. Hammering one host triggers the throttling that ruins the answers.

So why does bulk email verification take so long on some lists? Greylisting servers refuse the first try on purpose and expect you back after a wait, commonly 1 to 15 minutes. Microsoft throttles repeated connections, and slowing down gets better answers than pushing through. Those servers form the slow tail at the end of a business list.

The fastest way to finish a run is to stop retrying and guess. A verifier that skips the second attempt returns sooner, with more addresses left unresolved, and that's a trade made on your behalf. When you compare vendors, ask what they do when a server asks them to wait. Waiting is slower, and it's the correct move.

Say list A is a consumer list: 50,000 addresses across 1,200 domains, with most of them at five big mailbox providers. List B is a business list of the same size, spread across 31,000 company domains. They have the same row count, and the jobs have almost nothing else in common.

List A needs 1,200 domain lookups and talks mostly to a few giant mail systems. For list B the count is 31,000 lookups, and every company mail server is a stranger with its own habits. Some answer in a fraction of a second. Others greylist, which means they refuse the first try and expect you back after a wait that's often five minutes or more.

So list B has a long tail. The first 90% of its answers can arrive quickly while the last few percent trickle in, waiting on servers that asked for patience. Cutting the tail off makes the job look faster and turns real answers into unknowns.

The expensive mistake is scheduling the campaign for the hour after the upload. When the job runs long, someone cancels it at 90% and mails the unchecked rest, and the hardest addresses go out unverified. Submit the list the day before. A finished job that waits overnight costs you nothing.

Partial results help if you use them well. Start building segments from the verdicts that are already in, and leave the send until the job completes.

Ask a vendor three things about speed. What happens when a server returns a temporary refusal? How many times do they retry, and across how long? And is there a setting that trades coverage for speed, with a default you should know about?

A speed quoted alone deserves the same doubt as an accuracy figure quoted alone, because both depend on the list behind them. With ZapBounce you don't have to watch the clock: poll GET /v1/jobs/{id} and your system sees the status change to completed the moment the job finishes.