What is an email verification waterfall?
A waterfall asks more than one verification provider about the same address instead of trusting whichever one you signed up with. Teams build them because a single provider stopped being enough, and they go wrong in a predictable way.
The short definition
An email verification waterfall is a pipeline that sends one address to several verification providers — in sequence or in parallel — and combines their answers into a single decision. The name comes from the sequential version: try the cheap provider first, and only “fall through” to a more expensive one when the cheap one returns unknown.
Why anyone bothers
Two things happened at once. Per-check pricing collapsed from around $25 per 10,000 in 2019 to $0.00045–$0.01 per check today, so asking several providers stopped being expensive. And accuracy did not follow the price down: Microsoft-hosted mailboxes stopped answering SMTP probes truthfully, and catch-all domains never did.
So the check became a commodity while the judgement did not. Asking four commodity providers and looking at how much they disagree recovers information that no single one of them can report about itself.
Sequential or parallel
| Sequential | Parallel | |
|---|---|---|
| How it runs | Cheapest first, escalate on unknown. | Ask several at once, combine. |
| Cost | Lowest — most addresses stop at provider one. | Higher, unless you gate what reaches it. |
| Latency | Worst case is the sum of every hop. | Worst case is the slowest single provider. |
| What you learn | Only the last answer. Agreement is invisible because you stopped asking. | The spread — which is itself a signal about the address. |
The sequential form is cheaper and throws away the most useful thing a waterfall produces. If provider one says valid and you stop, you never learn that providers two and three would have disagreed.
Where waterfalls go wrong
- Majority voting. Three providers saying
validis not three independent opinions — they often use overlapping data and the same broken SMTP probe. Counting votes treats correlated guesses as evidence. - Labels, not probabilities. Combining
valid,unknownandcatch-allinto a fourth label loses the one thing you needed, which is how confident to be. - No calibration loop. Without feeding real bounces back, the combined score is an opinion about an opinion. Nothing in the pipeline knows whether it has ever been right.
- Ungated fan-out. Paying four providers to confirm that a syntactically invalid address is invalid, or to re-answer a question you asked yesterday.
The part that is actually hard
Fan-out is easy — it is a Promise.all. The hard part is turning disagreeing labels into a number that means what it says: calibrating against observed bounces so that 0.31 means roughly 31 in 100, and reporting an interval so you know how much to trust it before you act.
That requires outcome data, a bucketing scheme with enough volume per bucket to be meaningful, and the discipline to label an uncalibrated answer as uncalibrated rather than shipping a prior dressed up as a measurement.
Sortance is that waterfall as one API call
A local gate resolves what it can for free, a cache resolves what it has seen before, and only what remains reaches the provider pool — in parallel, so the disagreement survives. The output is a calibrated bounce_probability with a confidence_interval, the disagreement figure, and an actor_class. One key, one POST.
If you are already running your own waterfall, the comparison page is the honest version of when to keep it.