How Do You Set Up an Email-Finding Waterfall in Clay?

How do you set up an email-finding waterfall in Clay?

Start with a Clay table of people that includes first name, last name, and company domain. Add Clay's Work Email waterfall enrichment, map those columns as inputs, and decide how strict validation should be. Test on a small batch, check the results by hand, then run it on the full list and push only validated emails onward.

An email-finding waterfall tries several data providers in order until one returns a usable address. The idea is simple: no single provider finds everyone, so you chain them. Clay's documentation describes its Work Email waterfall as cascading across multiple providers in sequence and stopping as soon as a valid result is found.

This tutorial is for a founder or a small GTM team that already has a target list and wants reliable work emails for outbound without paying for every provider on every row. I will cover the setup, the settings that matter most, and the checks I run before any email reaches a sequence.

What do you need before you build the waterfall?

You need a Clay account, a clean list of people, and a clear idea of where the emails will go next. Each row should have a first name, a last name, and a company domain. Domains matter most. A wrong or missing domain wastes provider lookups and produces addresses at the wrong company.

Clean the list before you enrich it. Remove duplicates, trim stray spaces, and make sure domains are bare, such as "example.com," without "https" or "www." If you started from company names rather than domains, add a domain lookup step first and spot-check its results. A waterfall cannot fix bad inputs, it just spends credits on them.

Decide your destination too. If the emails will go into HubSpot or an outbound tool, know which fields they will land in and what checks run before sending. Planning this now prevents a pile of found emails with nowhere safe to go.

How do you add the Work Email waterfall to your table?

In your Clay table, add an enrichment and choose the Work Email waterfall. Map your first name, last name, and domain columns to the matching inputs. Then review the provider sequence Clay shows and the validation settings before you run anything. The output appears as a new column with the email it found.

Name the output column clearly, such as "Work email (waterfall)," so nobody confuses it with an email you imported. If your list already had some emails, keep them in a separate column. Mixing imported and found emails in one field makes it impossible to measure how well the waterfall performs.

Do not run the full table yet. Copy a small sample into a separate test table and run it there first. I usually start with twenty to fifty people from different companies so I can see how it behaves across a range of domains.

How strict should email validation be?

Strict enough to protect your sending domain. Clay's waterfall includes validation settings, including a "Require validation success?" option that only accepts an email when the validation provider explicitly confirms it as valid. For cold outbound, I would turn that on, because a bounce costs more than a missing email.

Catch-all domains are the tricky case. A catch-all server accepts mail for any address, so a validator cannot confirm whether a specific person exists. Clay's documentation describes strategy settings that differ in how they treat catch-alls. A more cautious setting excludes them, which lowers your find rate but also lowers your bounce risk.

My default for a new outbound domain is the cautious route. Once the domain has a track record and your bounce rate is low, you can test a less strict setting on a separate segment and compare results. Never loosen validation on your whole list at once.

How do you stop the waterfall from wasting credits?

Use the duplicate threshold setting. Clay's documentation describes a "Threshold for duplicate results" that stops the waterfall early if the same email keeps failing validation across providers. The default is zero, which disables it. Setting it to two or higher stops the waterfall after the same invalid email appears that many times.

This matters because several providers often guess the same address. If that address fails validation, there is little point paying more providers to return it again. The threshold cuts that loop short, which saves credits on exactly the rows least likely to produce a good email.

Clay's documentation also says you only pay credits for the provider that finds a match. Pricing details change, so check Clay's current pricing and your plan before running a large list. Running the small test batch first gives you a real cost per found email to multiply out.

How do you check the results before using them?

Read the test batch by hand. For each row, check that the email domain matches the company, the name part looks plausible, and the validation status is what you expect. Look at which rows came back empty and why. Patterns in the misses usually point to an input problem you can fix before the full run.

Common patterns include rows where the domain belongs to a parent company, people with hyphenated or multi-part names, and companies that use a different email domain from their website. Fix what you can at the input level, then rerun only the affected rows.

Track two numbers from the test: the share of rows that got a validated email, and the credits spent. Those two figures tell you whether the full run is worth it and give you a baseline to compare against later runs.

Where should found emails go next?

Into your CRM or outbound tool, but only after a final check. Filter to rows with a validated email, remove anyone on your do-not-contact list, and check for existing contacts or open deals so two reps do not reach the same person. Then push the clean rows to HubSpot or your sending tool.

Write the source onto each record, such as "Clay waterfall" and the date. When you later look at bounce rates or reply rates, you will want to know which emails came from this process. Without a source field, every email looks the same and you cannot tell which method works best.

Keep the Clay table as your audit trail. If a bounce or complaint comes in, you can trace the address back to the provider and the validation result. That makes it much easier to adjust settings instead of guessing.

How do you keep the waterfall working over time?

Re-run validation before each new send, not just once. Email addresses go stale as people change jobs. An email that validated three months ago may bounce today. A quick revalidation step before a list enters a sequence keeps your bounce rate low and your sending domain healthy.

Review results every month or so. Watch the find rate, the bounce rate on sent emails, and the credit cost per found email. If the find rate drops or bounces rise, check whether your inputs have changed, whether a different validation setting fits better, or whether your list has drifted toward harder segments.

Document your settings. Note which validation option you used, the duplicate threshold, and any input cleaning steps. When someone else runs the table later, or when you come back to it after a few weeks, those notes prevent a costly run with the wrong configuration.

What should you do next?

Clean a small list with first name, last name, and domain. Add the Work Email waterfall in Clay, turn on validation, set the duplicate threshold to two, and run a test batch. Review it by hand, fix input issues, then run the full list and push only validated, deduplicated, opt-out-checked emails onward.

If you want to think through provider order and cost before you build, read how to order an enrichment waterfall for cost versus coverage. Before any found email reaches a sequence, set up a do-not-contact list that every tool respects.

A good waterfall is one of the cheapest upgrades to an outbound system. If you want help building yours in Clay and connecting it to your CRM, reach out and let's chat.