Clay changed how B2B prospecting works. Instead of buying a static list from one enrichment provider, you can now waterfall through Apollo, Hunter, Dropcontact, Clearbit, and a dozen other sources, simultaneously filling in email addresses from whichever source has the highest confidence match.
The problem is that high confidence in Clay’s enrichment context does not mean deliverable. A “found” email address with 90% confidence from one provider may still be a corporate address that lapsed three months ago when the contact changed jobs. Or a catch-all domain address that the enrichment tool cannot confirm at the mailbox level.
Clay’s waterfall logic is excellent at finding emails. It is not an email verification tool. This guide explains why that distinction matters and how to build verification into your Clay workflow so that what you send is actually deliverable.
How Clay’s Waterfall Enrichment Works
Clay’s enrichment system runs multiple data providers in sequence or in parallel. For each contact row, it attempts to find an email address through the first configured provider. If that provider has no match or low confidence, it moves to the next provider and so on down the waterfall.
This approach maximises hit rate, the proportion of contacts for which an email address is found. It does not optimise for deliverability. A match at step 7 of a 10-step waterfall from a less precise enrichment source carries different accuracy characteristics than a match at step 1 from a primary provider.
Clay assigns a confidence score to found emails based on the source and match logic. Scores above 80% are generally considered reliable. Scores below 80% should be treated with scepticism. But even high-confidence addresses from the best providers have a meaningful invalid rate when you look at actual bounce data.
Why Enrichment Accuracy Varies by Provider
The underlying enrichment providers differ in how they populate their databases. Some crawl LinkedIn profiles and professional directories at regular intervals. Others use email format guessing (firstname.lastname@domain.com) combined with SMTP verification at the time of query. Others rely on data contributions from CRM integrations.
Each approach has accuracy trade-offs. Crawled data is stale; the accuracy of a profile crawled six months ago reflects the address validity at the time of crawl, not today. Format-guessing with real-time SMTP is more current but subject to catch-all false positives. CRM-contributed data varies in quality based on the hygiene practices of the contributing organisations.
Why “Found” Does Not Mean “Deliverable”
An email address can be “found” and correctly formatted yet fail delivery for several reasons that enrichment tools do not detect.
Job change invalidation: The contact has left the organisation since the enrichment data was last updated. The address no longer exists on the company’s mail server. The enrichment database has not yet reflected the departure.
Domain deactivation: The company has shut down, been acquired, or migrated to a different email domain. The original domain no longer processes email.
Mailbox-level closure: The specific mailbox was deactivated when the contact moved roles internally from a company email to a subsidiary email, for example, and the original address is no longer active even though the domain and company still exist.
Catch-all domain acceptance: The enrichment provider found the address via SMTP query, but the domain is configured as catch-all. The 250 OK response from the mail server does not confirm the specific mailbox exists; it confirms only that the domain accepts all incoming email. The enrichment tool cannot distinguish valid from invented on a catch-all domain.
Independent testing of major enrichment platforms consistently shows 10–25% of “found” emails as invalid or catch-all when run through a full SMTP verification layer. For Clay waterfall outputs that reach across multiple providers, the aggregate invalid rate can be higher in the lower-confidence rows.
The Specific Verification Gaps in Waterfall Data
The Staleness Gap
Clay’s waterfall pulls from provider databases. Those databases are updated on provider-specific schedules,s typically monthly to quarterly for major providers, less frequently for smaller ones. An address found at step 3 of your waterfall may reflect data that is 4–6 months old.
B2B address decay at the corporate domain level runs at 2–3% per month for high-churn industries. A six-month-old database record carries 12–18% of that decay. On a Clay export of10,000 contacts with an average enrichment data age of 5 months, you could be looking at 1,500–2,000 invalid addresses from staleness alone.
The Catch-All Distortion
Catch-all domains those configured to accept all incoming email are common in B2B environments, particularly at mid-size companies with custom IT setups. ZeroBounce estimates approximately 30% of B2B domains use catch-all configurations.
When an enrichment provider queries a catch-all domain’s mail server, it receives a 250 OK response for any address,, mat real or invented. The provider reports the address as “found.” Clay marks it as enriched. You export it to your sequencing tool.
Without verification, you send to catch-all addresses at the same rate as confirmed-valid addresses. The bounce rate from this segment will be materially higher than from your confirmed-valid contacts.
The Low-Confidence Tail
Clay’s waterfall often fills the last 20–30% of a list from lower-confidence sources. These rows have the highest invalid rates. They are also the hardest to identify without running them through independent SMTP verification because the confidence score from Clay reflects enrichment match confidence, not deliverability confirmation.
How to Verify Clay Exports Before Sending
The most reliable approach is exporting your Clay table and running the full contact list through a dedicated email verification service before importing to your sequencing tool (Instantly, Lemlist, Outreach, Smartlead, or similar).
Step 1: Export from Clay
Export your enriched table as a CSV. Include the email address column and, if available, the enrichment confidence score column.
Step 2: Segment by Confidence Score
Separate contacts into high-confidence (above 80%) and low-confidence (below 80%) segments if Clay’s confidence score is available. This allows you to apply different verification logic to each segment.
Step 3: Run Full Verification
Upload both segments to your email verification provider. Run full bulk verification syntax, MX record, SMTP, catch-all detection, disposable detectand ion, and risk classification.
Step 4: Apply Results
- Valid addresses: import to your sequencing tool
- Invalid and disposable: suppress permanently
- Catch-all: move to a separate segment; see below for handling guidance
- Unknown: re-verify after 48 hours; treat as catch-all if still unresolved
Step 5: Cross-Reference with Confidence Score
If you have Clay confidence scores, compare them to verification results. If low-confidence addresses are failing verification at a significantly higher rate than high-confidence ones, you have data to support changing your waterfall configuration,n perhaps stopping the waterfall at a higher confidence threshold or removing a low-performing provider.
Building Verification Into Clay Workflows Directly
Clay supports outbound HTTP requests and API integrations within table workflows. This means you can trigger a verification API call from within Clay as part of your enrichment waterfall, adding a verification step that runs immediately after an email address is found.
The In-Clay Verification Pattern
Configure a Clay column that makes an API call to your email verification provider’s endpoint, passing the enriched email address as the parameter. The API returns the verification classification. Clay stores the result in a new column: Verification Status.
Use Clay’s filter logic to exclude rows where Verification Status is “invalid” or “disposable” from the export or the subsequent push to your sequencing tool.
This approach means your list is verified at the point of enrichment rather than as a separate post-export step. It reduces workflow steps and ensures verification is never accidentally skipped.
Considerations for In-Clay Verification
API rate limits: your verification provider’s API rate limit applies. For large Clay tables running waterfall simultaneously across many rows, you may need to configure the API column to run sequentially rather than in parallel to avoid rate limit errors.
Cost: each API call consumes a verification credit. Factor this into your verification budget when building in-Clay workflows for large-scale prospecting tables.
Response time: in-Clay API calls add time to the waterfall run. For tables of 10,000+ rows, add 15–30 minutes to your expected enrichment completion time.
Handling Catch-All Results in Clay-Sourced Lists
Clay-sourced B2B lists typically have catch-all rates of 25–40%. This is the segment that requires the most nuanced handling.
Option 1: Exclude All Catch-All Addresses
The simplest approach. Exclude catch-all classified addresses from all sends. This eliminates the catch-all bounce risk but removes a significant proportion of your total addressable audience, because any of them are rare, active inboxes at legitimate organisations.
For cold email domains with no established reputation, this is the recommended approach. The bounce risk from catch-all addresses is too high for a domain that cannot absorb reputation damage.
Option 2: Use Probabilistic Scoring to Differentiate
If your verification provider offers probabilistic catch-all scoring, ring a confidence level indicating whether a specific catch-all address is likely to be a real, active mailbox; use it to segment your catch-all population.
Include high-confidence catch-all addresses in sends when your domain reputation is High in Postmaster Tools. Exclude low-confidence catch-all addresses from all sends. This approach recovers a portion of the catch-all audience while managing the bounce risk.
Option 3: Secondary Enrichment Before Sending
For high-value prospect rows where you want to maximise certainty before sending, use a secondary enrichment tool like ZeroBounce’s Verify+ or a similar confirmation service that sends a test message to the address to confirm delivery. This converts catch-all unknowns to confirmed valid or invalid at a higher cost per address.
Key Takeaways
- Clay’s waterfall enrichment maximises email address hit rate. It does not verify deliverability. “Found” and “deliverable” are different things.
- Independent testing shows 10–25% of enriched B2B emails as invalid or catch-all when run through full SMTP verification, even from high-quality providers.
- The three primary verification gaps in waterfall data are: staleness (enrichment databases are months old), catch-all distortion (domains accepting all mail regardless of mailbox existence), and the low-confidence tail (lower-ranked waterfall results with inherently lower accuracy).
- Verify Clay exports before import to any sequencing tool. Segment by confidence score, run full verification, apply results by classification, and cross-reference with confidence data to improve future waterfall configuration.
- You can build verification directly into Clay workflows via API columns, eliminating the separate export-verify-reimport step. This requires configuring rate limits and factoring API costs into your prospecting budget.
- Catch-all addresses from Clay-sourced lists require specific handling based on domain reputation and campaign type. Cold email domains should exclude them. Established domains can use probabilistic scoring to include high-confidence catch-all addresses selectively.
Frequently Asked Questions
Yes. Even Apollo, which maintains one of the largest and most frequently updated B2B contact databases, produces invalid addresses due to staleness and catch-all domain limitations. Apollo itself recommends verifying before sending for cold email specifically. A recent benchmark showed approximately 12–18% invalid rates on Apollo-sourced lists when run through full SMTP verification.
Clay offers basic email validation through some of its integrated enrichment providers. This is typically format and domain-level checking, not full SMTP verification at the mailbox level. For cold email where a single bounce above 1% on a new domain can cause significant reputation damage, full SMTP verification through a dedicated provider is necessary.
Within 24 hours of deployment. Do not verify on download day and send three weeks later — the list will have decayed. Clay lists, particularly those assembled from multiple providers, should be verified immediately before the first email in any sequence. For multi-step sequences running over 30 days, verify the not-yet-contacted segment at the 30-day mark before the later steps deploy.
Bulk verification of a 10,000-contact list typically takes 30–90 minutes through a dedicated provider. The workflow cost is one step between export and import to your sequencer. In-Clay API verification adds time during the table build phase but removes the separate export-verify step. Either way, the time investment is minimal compared to the reputation cost of sendingunverifiablee data
Conclusion
Clay is a powerful prospecting tool. Combining it with dedicated email verification makes it a responsible one.
The waterfall approach solves the hit rate problem of finding an email address for the maximum proportion of your target contacts. Email verification solves the deliverability problem, confirming that those found addresses are actually valid before you stake your sending domain on them.
Build verification into your Clay workflow as a standard step. Either as a post-export process or as an in-Clay API column that runs during enrichment. The cost is $0.003–$0.008 per address. The protection is the sender reputation your entire outreach programme depends on.
