Waterfall enrichment solves a real problem in B2B data: no single provider has complete coverage. Instead of accepting one database's blind spots, a waterfall enrichment setup sends each record through multiple providers in sequence. When one source cannot return a result, the next gets a chance.
That architecture can increase the number of contacts you recover. But there is an important distinction between finding more data and finding better data. A waterfall that stops at the first result has no built-in mechanism for determining whether the provider that answered first was actually the provider that made the strongest case.
That matters because providers do not hold the same evidence standard. One may return an address after generating a likely email pattern and getting an accepting SMTP response, while another analyzes further before calling the same address valid. The cascade therefore selects whichever provider says yes first, which is not necessarily the one with the strongest evidence.
Key takeaways
- Waterfall enrichment buys coverage. It queries data providers in a set order until one returns a result, which fills more records than any single database can.
- The first answer wins, not the best-supported one. A cascade that stops at the first hit favors the most permissive provider, because records it fills never reach a stricter one.
- Providers are far apart on identical data. In our 10,000-record benchmark on 251 catch-all domains, tools found between 4% and 98.2% of the same 500 real professionals, and one called 640 of 5,000 invented addresses valid (12.8%).
- Catch-all domains are where the gap matters most. They are common on company domains: our Fortune 500 census found 47% of primary domains were catch-all, and 69% were catch-all, gateway-fronted, or both.
- Let the waterfall find, and one verifier decide. Run every address through the same final check, whichever provider found it, and track each address’s source so bounces can be traced.
What waterfall enrichment is, and how single source differs
What is waterfall enrichment?
Waterfall enrichment is a data enrichment method in which multiple providers are queried in a set order, with the first provider to return a sufficiently confident result ending the run for that record.
The mechanic is sequential. A record might first go to Provider A, then move to Provider B if A cannot find an email, then to Provider C if B also fails. Importantly, the cascade can operate field by field rather than only record by record. An email address could resolve at the first provider while a phone number continues to the third.
The technique appears in products and workflows associated with platforms such as Clay, Apollo, ZoomInfo, FullEnrich, and BetterContact. The important distinction is that waterfall enrichment is a technique rather than a product. Its primary optimization target is fill rate.
That distinction is easy to lose, because a high fill rate looks like a quality metric on a dashboard. A filled field only tells you that some provider returned an answer, and says nothing on its own about the evidence behind it.
What is single-source enrichment?
Single-source enrichment uses one provider, one database, one integration, and one provenance trail to return data for a record. The limitation is structural rather than simply a question of database size. Every provider collects and maintains data differently, which creates its own blind spots across regions, industries, company sizes, job functions, and data freshness.
A larger database can reduce some gaps, but it cannot eliminate gaps caused by the underlying collection method. That is why a single-source architecture eventually reaches a coverage ceiling for any particular audience. Another source can expose information that the first source does not have.
Waterfall enrichment addresses that specific limitation. The question is what happens to the quality of the data once those sources are placed in a queue.
What a waterfall guarantees, and what it does not
Stacking providers fills more rows than relying on a single source. That is the waterfall's main advantage: when one provider cannot find a record, another gets a chance. However, the first result is not necessarily the most accurate. Once a provider returns an answer, the cascade stops without checking whether another source could produce a better-supported result.
This creates a selection effect. Some providers generate likely email patterns and accept a positive server response as sufficient evidence. Others go further to distinguish an accepting server from a confirmed mailbox. In a waterfall, the more permissive provider wins by default because records it fills never reach stricter providers.
Not every implementation is a plain cascade. ZoomInfo's Waterfall Enrichment, announced in February 2026, queries its sources in parallel and returns the highest-confidence result, and Clay's email waterfall can add a validation provider, such as Allegrow, that decides whether a result is good enough to stop on, with settings that range from conservative to accepting catch-alls. Both narrow the selection effect without removing it. Meaning the deciding standard moves from whichever provider answered first to whichever confidence score or validator the platform trusts, and that standard is the same variable our benchmark found to be far apart.
This also skews performance reports. A provider may appear to have the highest fill rate simply because it answers first, even if some of its results would have failed stricter checks. Without tracking which provider supplied each address, subsequent bounces cannot be traced back to their source.
Provider statuses add another complication. One service's "valid" may reflect different checks than another's, while labels such as "catch-all" or "unknown" can also vary. Combining them into a single CRM status hides those differences.
Ultimately, a waterfall answers one question well: Can another source fill this field? It does not guarantee an answer to the more important one: Is that address actually valid?
How far apart providers actually are
This is where the architectural argument becomes measurable. In our 2026 benchmark, the same dataset was sent through 11 email verification tools. The test contained 10,000 addresses across 251 domains, all deliberately selected as catch-all domains. It included 500 real professionals with roughly ten candidate email permutations each, plus 5,000 fictional addresses used as a control. The run took place in early August 2026. The results were far from interchangeable.
The real-contact spread is striking. Across the same 500 people, tested configurations found between 4% and 98.2% of real contacts, showing how dramatically results can differ on identical data.
The false-positive result shows the other side of the problem. One tool called 640 of the 5,000 invented addresses valid, or 12.8%. In a waterfall, putting a provider with that behavior early in the sequence means those invented addresses can stop the cascade before a stricter provider ever sees them.
The opposite failure is also significant. Half the tests, seven of fourteen, left 94% to 96.3% of the full dataset unresolved. In a waterfall, that means those providers contribute little coverage and simply pass most of their records further down the chain. They may still add latency and cost without materially changing the final dataset.
Our benchmark tested the tools side by side rather than in a cascade, so it does not measure provider order directly. The implication follows from the spread, though: with providers this far apart, reversing the same sources in a waterfall would likely produce different contact lists, false-positive rates and unresolved records. Two teams using identical sources can therefore end up with very different CRM data while their fill-rate reports look equally strong.
Why catch-all domains are where this breaks
Catch-all domains expose the weakness particularly clearly because the receiving server accepts mail for addresses whether or not a specific mailbox exists.
That removes the clean server-level signal a verifier would normally use. If the server responds positively to both real.person@company.com and fictional.person@company.com, an accepting SMTP response cannot distinguish the two. The provider has to use additional evidence or return an unresolved result.
This is precisely where provider standards diverge. A permissive system can interpret the accepting server as enough evidence to return a positive result. A more cautious system can recognize that the same server response proves only that the domain accepts mail, not that the individual mailbox exists.
And catch-all domains are not a small edge case in B2B data. Our study of all Fortune 500 primary domains found 235 of 500, or 47%, were catch-all. A total of 344 of 500, or 69%, were either catch-all, gateway-fronted, or both. The study is a point-in-time measurement of the Fortune 500 and was conducted in 2026, so these figures should be read as a snapshot rather than a permanent property of those companies.
That concentration matters because the architecture problem is not evenly distributed across a prospecting database. Catch-all servers and gateways are common across company domains and most concentrated at larger companies, which are often among the most commercially valuable records in a database.
A vendor may reasonably state that a basic verifier cannot conclusively confirm a mailbox on an accept-all domain. That is true for verification methods that depend on the server giving a mailbox-specific response. But it should not be confused with the claim that no verification system can ever resolve a catch-all address.
Allegrow's benchmark demonstrates that tools can differ dramatically in their ability to resolve these domains. On the same catch-all dataset, some configurations found hundreds of real contacts while others found fewer than 30.
Meaning catch-all domains are where the selection effect does the most damage: when the server gives every provider the same ambiguous signal, the provider's own evidence standard decides the answer.
How to run a waterfall without inheriting its weakest provider
If coverage is the reason you built a waterfall, abandoning it is not necessarily the answer. The better approach is to separate the job of finding an address from the job of deciding whether that address is valid.
Start by ordering providers according to the quality of the evidence they require, rather than simply putting the cheapest source first. Cheapest-first can minimize enrichment spend, but it can also maximize the share of records filled by the most permissive provider. That tradeoff only makes sense if a bad address costs less than another verification.
Next, add one independent verification step after the cascade. Every address should go through the same final check, regardless of which provider found it. This gives your CRM consistent Valid or Invalid statuses instead of combining different providers' definitions of "valid."
Set a clear policy for catch-all addresses rather than inheriting whichever label the first provider assigns. Also, track the source of every address so you can trace bounces and identify providers producing poor data.
Finally, limit the number of providers in your chain. Overlapping datasets can mean that additional sources increase costs and processing time without meaningfully improving coverage.
Allegrow can serve as that final verification layer. In our benchmark it found 491 of the 500 real professionals on catch-all domains and left 2.0% of the set unresolved. Teams running their waterfall in Clay can add it as the verification step through our Clay integration, so the platform finds the address and one consistent standard decides whether it is valid.
When a waterfall earns its place
The right question is not whether waterfall enrichment is inherently good or bad. It is what your workflow loses when a row remains empty compared with what it loses when a wrong address gets through.
A waterfall earns its place when coverage is genuinely the constraint. It becomes more useful when the list is large enough that even a few additional percentage points represent meaningful numbers of contacts, when the target market spans regions or segments with different data coverage, and when your operations team can normalize statuses and retain source information.
It is less compelling when the list is small enough to complete manually or when a single provider already covers the segment well. It can also be a poor trade when a bad address creates more damage than a missing one, particularly when outbound volume is high and sender reputation matters.
Provenance can change the calculation as well. If you need to explain where every contact came from, a multi-provider architecture requires more operational discipline. Without source tracking, the extra coverage can come at the cost of knowing why a record exists.
The same applies when you have already tested one provider against your actual ICP and found that it covers the segment consistently. In that situation, adding multiple sources may increase complexity without solving a meaningful coverage problem.
The decision therefore comes down to the economics of missing versus wrong data. The waterfall controls the first problem. Verification controls the second. Those are complementary functions, not substitutes.
Conclusion
Waterfall enrichment answers a coverage question well: when one provider cannot find a contact, another gets the chance, and that is a real advantage over a single source. The trouble starts when a successful match is treated as a successful verification, because the order of the waterfall, or the validator inside it, decides which evidence standard gets to define "valid".
That standard matters most on catch-all and gateway-fronted company domains, where the server gives every provider the same ambiguous signal. So keep the waterfall if coverage is what you need, and give one verifier the final word on every address, whichever provider found it.
If you have recently enriched a B2B list, start a 14-day free trial and run up to 1,000 of those addresses through Allegrow, including the catch-all contacts your waterfall marked valid, and see how many hold up as a conclusive valid or invalid. The trial also detects spam traps, disposable addresses and inactive mailboxes, and identifies each contact's primary email.
Frequently asked questions
What is waterfall enrichment?
Waterfall enrichment queries several data providers in a set order, passing a record to the next provider only when the previous one cannot return a result. It can run field by field, so an email may resolve at the first provider while a phone number continues down the chain. Its main goal is fill rate.
What is the difference between waterfall and single-source enrichment?
Single-source enrichment uses one provider and one provenance trail, so it inherits that provider’s blind spots. Waterfall enrichment stacks several providers to fill gaps one source cannot. It increases coverage, but it also mixes providers with different evidence standards into the same CRM fields.
Is waterfall enrichment more accurate than a single provider?
Not necessarily. It finds more contacts, but a cascade that stops at the first result favors the most permissive provider, because records it fills never reach stricter ones. Accuracy depends on the evidence standard of whichever provider answers first, which is why a final verification step matters.
Do I still need email verification after waterfall enrichment?
Yes. Providers label addresses valid on different evidence, and combining them into one CRM status hides those differences. Running every address through one verifier after the cascade gives you a consistent valid or invalid, which matters most on catch-all domains, where every provider receives the same ambiguous server signal.
How should I order providers in a waterfall?
By the quality of evidence each one requires, not just by price. Cheapest-first minimizes enrichment spend but can maximize the share of records filled by the most permissive provider. Track which provider supplied each address, and keep the chain short, since overlapping datasets can add cost without adding coverage.
.webp)