Waterfall email verification means running an address through more than one verifier in sequence, usually passing along only the results the first tool couldn't settle. It grew out of waterfall enrichment, the approach popularized by tools like Clay, where you query several data providers in turn until one returns an email.
The idea is attractive: if one verifier is good, two should be better. Sometimes that's true. Often it just means paying twice for the same answer. This post explains how the maths works, which results are worth a second opinion, and how to set up a waterfall that pays for itself.
Two kinds of waterfall
People use the term for two different things, and it helps to separate them.
Enrichment waterfall. You have a name and a company and need an email. Provider A has nothing, so you ask provider B, then C. Each provider may also tell you whether its email is "verified".
Verification waterfall. You already have the email. Verifier A returns a result. For some subset of results, you send the address to verifier B for a second check.
This post is about the second kind, though it applies to the first: whatever came out of the enrichment waterfall still needs one independent verification before you send.
When a second verifier changes the answer
A second check is only useful if it can produce a different, better answer than the first. Walk through the categories:
| First result | Can a second verifier improve it? | Why |
|---|---|---|
| Deliverable | Rarely | The mail server already confirmed the mailbox. A second check asks the same server the same question. |
| Undeliverable (mailbox not found) | Rarely | The server said the user doesn't exist. Another tool gets the same answer. |
| Undeliverable (dead domain, syntax) | No | DNS and syntax don't change between tools. |
| Unknown (timeout, temporary error) | Yes, sometimes | The second attempt happens later, from different infrastructure, and may get through. |
| Risky: catch-all | Limited | The server accepts every address. A second SMTP check sees the same thing. Some vendors add other signals, with varying accuracy. |
| Risky: anti-spam block | Sometimes | Another verifier's IPs may not be blocked by that server. |
The pattern is clear. Definite answers from the mail server don't get better with repetition. The value of a second verifier is concentrated in the results that were uncertain because of the conditions of the check, not the address itself.
The maths of stacking
Suppose verifier A and verifier B each make some errors. If their errors were completely independent, running both and only sending when both say deliverable would cut false positives sharply. In reality their errors are not independent. Both connect to the same mail server, which gives both the same answer. If the server accepts everything (catch-all) or lies (accepts at RCPT, bounces later), both verifiers get fooled in the same way.
So a waterfall reduces errors that come from flaky conditions (timeouts, greylisting, IP-based blocks), and does little about errors that come from how the server behaves. That's the reason to target the second pass at unknown and specific risky results instead of running the whole list twice.
Costs to weigh
Running everything through two verifiers doubles your verification cost per lead. For most cold programs, verification is a small line item next to data and tooling, so that may be fine. But a few other costs are easy to miss:
- Time. Each step adds latency, especially for bulk jobs on slow mail servers.
- Complexity. Two result vocabularies to map, two sets of API errors, two places for a pipeline to break.
- Conflicting answers. If A says deliverable and B says unknown, what do you do? Without a rule, people make it up per campaign.
- Server load. Mail servers notice repeated probes. Hitting the same domain from several verification services in quick succession can make blocks more likely, not less.
A sensible waterfall setup
If you decide a second pass is worth it, keep it narrow:
- Verify everything once with your main verifier.
- Keep deliverable addresses and send them.
- Drop undeliverable addresses and add them to your suppression list. Don't spend money re-checking them.
- Recheck unknowns later. Many unknowns resolve on a second try after some time has passed, with the same verifier. Try that before paying a second vendor.
- Send remaining unknowns and anti-spam-blocked results to a second verifier if the volume justifies it.
- Handle catch-all separately. Decide by segment and risk tolerance rather than by vendor. Our catch-all framework covers the options.
- Write down the conflict rule. For example: send only if at least one verifier says deliverable and neither says undeliverable.
In Clay or a similar tool, this looks like a conditional column: run the second verifier only when the first result's category is unknown, or risky with a specific reason.
What to look for in the first verifier
The better your first pass, the less you need a second. A few things make a big difference:
- A reason with every result. "Risky" alone doesn't tell you whether to send. "Risky: server accepts every address" and "Risky: disposable" lead to different decisions, and the reason is what lets a waterfall route correctly.
- Honest handling of slow servers. A verifier that gives up after a few seconds produces more unknowns. One that waits, retries, and lets you fetch the result later produces fewer.
- Clear catch-all detection. A per-domain probe tells you the domain accepts everything, so you can treat those addresses as a group.
SimpleCold returns a category and a plain reason for every address. For slow servers, the API answers within about 12 seconds or returns a processing status that you can check again within 30 minutes without using another credit. Servers that never give a clear answer come back Risky with the status no_response, which is the natural input for a second pass. That gives you a straightforward routing key for the narrow second pass described above.
The short version
Stacking verifiers on a whole list mostly buys you the same answer twice. A targeted waterfall, one that sends only unknowns and certain risky results to a second check, can recover some leads cheaply. Start with one good verifier, retry unknowns before reaching for a second vendor, and measure bounces by step.
For setup details on the cold email side, see how to verify emails before cold outreach.
