How fast is email verification? Three honest answers exist, and they time three different jobs. One address checked live through an API (an application programming interface, the connection your site uses to ask another service a question) comes back in well under a second when the mailbox is straightforward. A whole list is measured in minutes per 10,000 addresses. A deep check, the kind that deliberately waits out a stalling mail server, can spend a minute on one difficult address and still be the right call. Sales pages quote whichever of the three reads best and let you assume it covers your situation.
Before comparing stopwatch figures between vendors, it helps to know what the stopwatch is timing.
What a verifier is doing while you wait
A verification check is a short conversation with somebody else’s mail server, and most of the elapsed time belongs to that server, not to the verifier.
For a single address, the sequence runs like this:
- Syntax and known-domain checks. Milliseconds. Pattern matching against rules and reference lists, all of it local.
- DNS and MX lookups. DNS is the domain name system, the internet’s address book. An MX record (mail exchanger) is the entry that says which server handles mail for a domain. Cached lookups are near-instant. Obscure or broken domains take longer, and a dead domain often has to time out before anyone can call it dead.
- The SMTP conversation. SMTP (simple mail transfer protocol) is the language mail servers speak to each other. The verifier opens a connection, introduces itself, and asks whether one specific mailbox exists, without delivering a message.
- Whatever the far end decides to do. Answer at once, stall, throttle, or refuse to say.
Step four is where the time actually goes. Some servers reply in a fraction of a second. Others hold the line open for several seconds before saying anything useful. Plenty of them use greylisting, a deliberate temporary rejection that tells any sender to come back later, which means getting a truthful answer requires waiting and asking again.
Then there are the addresses that cannot be settled in one pass:
- Catch-all domains accept mail for every address, real or not, so the mailbox-level question has no clean answer. Probing one costs extra time and still ends in a judgment call.
- Unknowns happen when a server refuses to commit. A serious service retries those on a schedule rather than guessing, and retries cost wall-clock time.
- Rate limits. Big providers throttle anyone who asks about too many addresses at once. Asking politely is slower than asking fast, and asking fast gets you blocked.
How fast is email verification, mode by mode
A single live check: comfortably under a second
For one address on a normal domain, latency (the delay between asking a question and getting the answer) usually lands somewhere around half a second. That is quick enough to run inside a form submission without a visitor noticing anything happened.
What moves that number: physical distance to the mail server, whether the DNS answer is already cached, and whether the domain belongs to a giant provider with predictable behavior or to a small self-hosted server having a slow morning. Averages hide the tail. A quoted half-second is a typical case, and some share of addresses will take several times longer. A form that freezes for eight seconds is a lost signup even when the average looks excellent.
If you are the one wiring it up, the response format and the timeout behavior matter more day to day than the raw number, and the API documentation is where both live.
A bulk job: minutes per 10,000 addresses
Bulk verification is not one check repeated 10,000 times in a queue. It is thousands of conversations running in parallel, paced so that no single mail provider gets hammered into blocking you. Throughput (how much work finishes per unit of time) is therefore governed by the slowest and strictest servers on your list rather than by the vendor’s hardware.
Minutes per 10,000 addresses is the realistic scale. A clean list of common consumer domains finishes at the fast end of that. A list carrying dead domains, throttling corporate servers, greylisting and catch-alls sits at the slow end, and the gap between those two lists is wide.
Which mode you need for a given job is a different question from how fast each one runs, and we worked through that decision in real-time vs bulk email verification.
A deep check: slower on purpose
The third speed confuses people, because here the slowness is the feature. A deep check waits out greylisting, retries the unknowns, and probes catch-all domains instead of shrugging at them.
Reoon’s own docs describe the split plainly as Quick Mode and Power Mode. Quick Mode is “built for speed”, runs at “~0.5 seconds”, covers syntax, disposable addresses, MX records and role accounts, and states openly that it “does NOT verify individual inbox status”. Power Mode is “built for accuracy and detailed results”, adds the inbox-level signals and the detailed status categories, and takes “Seconds to 1+ minute (avg ~3s for 90%)”. The guidance attached to the two is refreshingly blunt: “If a human is waiting on the screen, use Quick Mode”, and “If your sender reputation is on the line, use Power Mode.”
That is the whole trade in two sentences. Speed and certainty pull against each other on hard addresses, which is why verifier accuracy claims deserve the same careful reading as speed claims.
Email verification speed at a glance
| Mode | Typical time scale | What limits it | When it matters |
|---|---|---|---|
| Live single check via API | Under a second | DNS lookups, one SMTP round trip, network distance | Somebody is waiting on a form |
| Bulk list job | Minutes per 10,000 addresses | Provider rate limits, retries, share of dead and catch-all domains | Cleaning a list before a campaign |
| Deep or power check | Seconds to over a minute on a hard address | Deliberate waiting: greylisting delays, retries, catch-all probing | Sender reputation is on the line |
Why “instant” is the wrong word for bulk
“Instant” is fair shorthand for a single live check. Applied to a file of 50,000 addresses it is marketing. Nobody can make a remote mail server answer faster than it wants to, and nobody can skip a greylisting delay without guessing at the result.
Bulk throughput claims vary widely between vendors, and nearly all of them describe good conditions: a tidy list, familiar domains, no unusual throttling, a quiet hour. Read any bulk speed figure as “under ideal conditions on a clean list”, then ask what happens to yours.
Two consequences follow. Plan campaign timing with margin: if your list takes twenty minutes on a good day, do not schedule the send for eighteen minutes after the upload. And judge a service by its slow cases. Everybody looks fast on gmail.com addresses.
Your list sets part of the clock
A job’s duration depends on what you upload nearly as much as on who you upload it to. The direction of the effect is reliable even though the size of it varies by list:
- Lists heavy with dead or parked domains spend time on lookups that end in timeouts.
- Corporate and self-hosted domains tend to throttle harder than the large consumer providers, so batches of B2B addresses generally run slower.
- A high share of catch-all domains adds probing work on top of the normal check.
The practical version: your first clean of a neglected five-year-old list will take noticeably longer than the routine quarterly pass on the same list a year from now. That is expected.
Four questions that get a straight answer
Sales pages quote averages. These four get past the average.
- What is the typical per-address latency on the plan I would actually buy, and what does the slow tail look like? A median is not a promise. Ask what the ninety-fifth percentile does.
- What throughput per hour should I expect on a bulk job, and what kind of list was that measured on? The second half of the question carries the weight.
- What happens to addresses that come back unknown, are they retried automatically, and does the job wait for them? A service that returns fast guesses will always win a pure speed contest against one that retries patiently.
- Does speed hold at peak times? Monday morning and the week of Black Friday look nothing like 3am on a Tuesday.
A vendor who answers all four in specifics has told you something the numbers cannot.
Where the published numbers sit
Reoon puts both of its figures in plain sight on the email verifier page: “Live API validation in 0.5 seconds” for the live check, and for lists, “Generally, it can take around 8-12 minutes to bulk verify a set of 10,000 mixed-quality email addresses.” The phrase doing real work in that second sentence is “mixed-quality”, an acknowledgment that what you upload moves the clock. Advertised accuracy is 99%+, and the trade described above still applies: the deeper mode spends more time per difficult address in exchange for a firmer answer.
The only speed test that means anything is the one you run on your own data. Create a free account, which comes with free verification credits every day and no card, then upload a small sample of your real list and time it yourself. Daily credits are sized for testing rather than for cleaning an entire database in one sitting, and a sample is exactly what you need to see how your particular addresses behave.
FAQ
Is instant email verification real?
For one address at a time, close enough. A live check typically finishes in under a second, fast enough that nobody waiting on a signup form notices it happened at all. For a whole list, the word oversells it. A bulk job is thousands of separate conversations with other people’s mail servers, and those servers set the pace. Minutes per 10,000 addresses is the honest scale.
Why did my bulk job take longer than the estimate?
Usually the list is the reason rather than the service. Dead domains have to time out before they can be called dead, corporate mail servers throttle hard, greylisting forces a wait-and-retry cycle, and catch-all domains need extra probing before anyone can assign them a status. A first clean of an old, never-verified list runs slower than a routine pass on a list you maintain. Peak-hour load adds a little more.
Does faster email verification mean less accurate results?
On easy addresses, no. A real mailbox at a major provider answers quickly and clearly either way, so speed costs you nothing there. The trade appears on hard addresses: greylisting delays, servers that refuse to commit, catch-all domains. A quick answer in those cases is an educated guess, while a slower deep check waits, retries and probes before it commits to a status.
How fast should a verification API be for a signup form?
Aim for a response well under a second on typical addresses, and give the timeout you configure as much thought as the average you are quoted. Two hundred extra milliseconds cost you nothing a visitor can feel; eight seconds of frozen form costs you the signup. Set the integration to fail open, letting the form through if the check ever stalls.
