How Long Does Bulk Email Verification Take, and Why It Varies

Bulk email verification takes anywhere from minutes to a day or more, and list size is only part of the reason. The verifier's own rate limit sets the floor; the recipient servers decide the rest. Greylisting, per-domain throttling and slow servers add a long tail, and that tail is what makes the last few percent of a list take longest.

That is an unsatisfying answer if you have a campaign going out tomorrow, so this post breaks the time down into its parts, shows how to estimate a lower bound for your own list, and explains why a tool that finishes suspiciously fast deserves a closer look.

Where the time actually goes

Each address needs a short SMTP conversation with someone else's mail server, and that server sets the pace. A mailbox check is a DNS lookup for the domain's MX record, a connection to that server on port 25, and a RCPT TO question at which the conversation stops, without sending a message. We explained the steps in how to check an email without sending.

For a responsive server, that takes moments. The variation comes from servers that are not responsive, on purpose or otherwise:

Factor	What happens	Effect on time
Verifier rate limit	The tool caps how many probes it opens per minute	Sets the minimum total time
Greylisting	The server refuses the first attempt with a temporary reply	Adds minutes to hours for affected addresses
Provider rate limiting	The server slows or defers repeated connections from one source	Addresses on big domains queue up
Slow or silent servers	The verifier waits for a reply that comes late or never	Each one holds a slot until it times out
Catch-all detection	The verifier also tests a random address on each domain	Extra probe per domain, not per address
Repeats and duplicates	The same address or domain is checked twice	Wasted time, avoidable

Greylisting: the delay that is supposed to happen

Greylisting deliberately rejects the first attempt from an unfamiliar sender and accepts a retry later, so a verifier has to wait. RFC 6647 describes it as "providing temporarily degraded service to unknown email clients as an anti-abuse mechanism". It says the temporary reply should be 421 or 450, and that a retry should be accepted if it arrives within a window that "SHOULD be from one minute to 24 hours". The Postfix greylisting server postgrey defaults to a 300-second delay, so a retry sooner than five minutes is refused again.

For a verifier, that leaves two choices: report the address as unknown straight away, or come back later. Coming back later gives a real answer, but it means the list is not finished until the retries are. More on why that matters for results in accept-all vs unknown, and on the technique itself in the greylisting glossary entry.

Rate limits on the big providers

Large mailbox providers throttle sources that open many connections, and a list concentrated on one domain feels it most. Google's Gmail SMTP error reference lists several temporary replies of this kind, including:

421 4.7.28 Gmail has detected an unusual rate of email. To protect our users
from spam, email has been temporarily rate limited.
421 4.4.5 Server busy, try again later.
450 4.2.1 The user you are trying to contact is receiving email too quickly.

Those messages are written about mail delivery, but the same servers answer verification probes. A consumer list where a large share of addresses are gmail.com cannot be checked as fast as a list spread across thousands of small company domains, because a careful verifier spaces out its connections to any one provider rather than triggering those limits. Pushing harder does not help: a deferred probe produces no answer, only a retry.

Slow servers and timeouts

A server that answers slowly, or not at all, ties up the check until the verifier gives up on it. The SMTP standard, RFC 5321, recommends that a sending client wait up to 5 minutes for the initial greeting, 5 minutes for the reply to MAIL and 5 minutes for the reply to RCPT. Those timeouts are designed for delivering mail, where patience is the right default.

A verifier usually waits less, because a list of thousands cannot afford minutes per address. That is a trade-off with consequences: a shorter timeout finishes faster and returns more unknowns; a longer one returns more answers and takes longer. Neither is wrong, but you should know which your tool is making.

Why a list "sticks" near the end

The last few percent take longest because they are the addresses that were deferred, greylisted or timed out the first time. Every responsive server is done early. What remains is, by definition, the set of servers that would not answer on the first pass, waiting for its retry window.

This is normal, and it is the clearest sign a verifier is doing the job properly. A tool that reaches 100% at a steady pace, with no tail at all, is either checking a very easy list or not waiting for anything.

Faster is not automatically better

A verifier can finish quickly by skipping the hard addresses, so judge speed together with the share of unconfirmed results. The cheap ways to be fast are to give up on any server that does not answer immediately and report it as unknown, or to skip the SMTP step entirely and judge the domain. The second produces results that look complete and say "valid" for addresses nobody checked.

You can test for that in seconds. Verify a made-up address at a domain that rejects unknown recipients, such as Gmail. If the tool says valid, it never asked the mailbox. We walk through this and other checks in how to tell if your email verifier is lying.

How to estimate your own list

Divide your list size by your verifier's published throughput to get a lower bound, then allow for a tail. Most vendors publish either a rate or nothing; if yours publishes nothing, ask. As a worked example using our own published figure: SimpleVerifier's pricing page states a ceiling of 45 verifications per minute per account. At that rate, 10,000 new addresses need at least about 222 minutes, a little under four hours, before any greylisting retries. That is a floor, not a promise, because the recipient servers can only slow it down. Addresses confirmed within the previous 14 days are returned from cache without a new SMTP connection, so re-checking an overlapping list is quicker.

List size	Minimum at 10/min	Minimum at 45/min	Minimum at 200/min
1,000	100 min	22 min	5 min
10,000	16.7 h	3.7 h	50 min
100,000	6.9 days	37 h	8.3 h

The table is arithmetic, not measurement: list size divided by rate. Use your own tool's figure.

How to make it finish sooner

Most of the time you can save comes from not checking things twice and from starting early.

1. Remove duplicates and broken syntax first. Neither needs an SMTP check. See removing invalid and duplicate emails from a CSV.
2. Split off recently verified addresses. If part of the list was checked in the last week or two and has not bounced since, it does not need to be checked again before this send.
3. Start a day before you need the results, so greylisted and deferred addresses have time to be retried instead of being left as unknown.
4. Do not resubmit the same file while it is running. It doubles the connections to the same servers and makes throttling more likely.
5. Re-run only the unknowns afterwards, not the whole list.

Practical takeaway

Bulk verification time is mostly set by other people's mail servers. Work out the floor from your tool's published rate, expect a slow tail made of greylisted and throttled addresses, and leave a day of slack before a campaign. If a tool finishes very fast with almost no unknowns on a hard list, check that it actually asked the mailboxes.