Fast email verification API. Real-time, 50ms p50.
vrfymail runs on Cloudflare Workers in 300+ cities. MX lookups and DNSBL probes fire in parallel, never serialized. No cold starts, no regional round-trips. A verify call from your signup form is invisible inside handleSubmit.
Where 50ms comes from, where 250ms cap comes from
Cache hit path: pure D1 reads, no external network. Cold path: MX + DBL probes in parallel, total ~250ms p99.
# What runs in 50ms
API key resolve 1 D1 read ~0.5ms
Syntax check CPU ~0.1ms
Disposable lookup 1 D1 read ~0.5ms
Account history 1 D1 read ~0.5ms
Spamhaus DBL cached 0 0ms
MX cached 0 0ms
Worker overhead routing ~1ms
Total (cache hit) ~50ms (incl. network)
# Cold path adds (in parallel, not serialized)
MX probe (DoH) DNS lookup +100-200ms
Spamhaus DBL probe DQS query +50-150ms
Total (cold path) ~250ms p9950ms is invisible. 500ms is a workaround.
For real-time signup gating, latency isn't a vanity metric. A 50ms verdict is invisible inside a form-submit roundtrip — your user clicks Submit, the form moves to the success state, they never know there was a check. A 500ms verdict shows up as a perceptible pause and pushes you toward client-side workarounds (optimistic accept, async verify on the server, "verify after the fact").
The workarounds defeat the purpose. The point of real-time verification is blocking bad addresses before they hit your database. If your verifier is too slow to do that synchronously, you're back to running cleanup batches at 3am.
The mechanical reason vrfymail is faster: MX probe and Spamhaus DBL probe fire in parallel on cold paths. Most legacy verifiers serialize them (do MX, get result, do DBL, get result), turning a 200ms parallel-worst-case into a 400ms sum.
- vrfymail ~50ms p50 cache, ~250ms p99 cold. Cloudflare edge, parallel probes.
- ZeroBounce 200-500ms typical. Regional infrastructure.
- NeverBounce Not published. Built for batch, not real-time.
- Hunter ~800ms typical with SMTP probe stage.
The first request and the millionth see the same baseline.
Cloudflare Workers use V8 isolates, not container cold-starts. There's no "first request to this region" tax. The worker is always warm at every POP — your verify call lands at whatever POP is nearest your user, processes there, returns from there.
For a signup form in Sydney, the request never crosses the Pacific. The Sydney POP runs the verifier, does the D1 read (D1 replicates globally), and returns the verdict. The MX and DBL probes themselves may still need to reach external DNS servers — that's the cold-path budget. But the worker itself? Always warm.
All the checks, in 50ms
Every /v1/check runs disposable detection (272K+ domains), Spamhaus DBL probe, B2C strict-mode flags, role-account detection, MX checks, and your per-customer bounce overlay. One call, every signal, 50ms p50.
Edge email verification, answered
- What does '50ms p50' actually mean in practice?
- p50 (the median) is what half your requests see — typically the cache-hit path. p99 (the 99th percentile) is the cold-path worst case. For vrfymail: ~50ms p50 on a cache hit (D1 reads only, no DNS, no DBL probe), ~250ms p99 on a cold path (MX + DBL probes run in parallel, never serialized). Most production signup forms see 80%+ cache hits after the first hour of traffic.
- Where are the Cloudflare Workers POPs?
- Cloudflare's edge is in 300+ cities across 100+ countries. Your verify request lands at the POP nearest to your user, processes there, and returns from there. No region-hopping, no transcontinental round-trip. For an API call from a US East signup form, the verdict comes back from a US East POP in single-digit milliseconds of network time on top of the ~50ms processing.
- How does running MX and DBL probes in parallel actually save time?
- Naive verification serializes: do MX lookup, get result, then do DBL lookup, get result, then return. Each probe is ~100-200ms cold; serialized that's 200-400ms total. vrfymail fires both at the same time using Workers' Promise.all primitive — total wait time = max(MX, DBL), not sum(MX, DBL). The cold path is ~250ms p99 instead of ~400ms.
- Are there cold starts?
- No. Cloudflare Workers don't cold-start the way AWS Lambda does — the V8 isolate model means the worker is always warm at every POP. The first request to a POP and the millionth request to that POP see the same baseline latency. The 'cold path' in our docs refers to the verdict path that has to hit external DNS / DBL probes, not the worker cold-starting.
- What about latency for verifies from outside the US?
- Same architecture, same edge POPs. A signup form running in Sydney hits a Cloudflare POP in Sydney; the request to vrfymail processes at the Sydney POP and returns from there. The MX and DBL probes themselves may still need to reach US-anchored DNS servers (Spamhaus DBL is global but DNS resolution paths vary by region), but processing and most cache hits are POP-local.
Edge speed. Real-time gating. One call.
5,000 verifies/month free, no card. Paid plans start at $9/mo — see pricing.
Get my API key