Clay

What Happens to the Catch-All Rows in Your Clay Table

20-40% of your Clay table comes back as catch-all after verification. Here's how to resolve those rows to deliverable or bounce — inside Clay, alongside your existing workflow.

You enriched your Clay table with email verification. Apollo, Hunter, or whichever native integration you used ran through the list and gave you results. Most rows came back clean — verified or invalid, clear answers you can act on.

Then there are the rows that came back as "accept-all" or "risky" or "unknown." Depending on the list, that's somewhere between 20% and 40% of your B2B contacts. These are catch-all domains — mail servers that accept every address whether the mailbox exists or not. The verification tool connected, asked "does this mailbox exist," the server said "yes" to everything, and the tool correctly reported that it couldn't tell the real addresses from the fake ones.

So those rows sit in your table. You either send to them and accept the bounce risk, or skip them and lose a chunk of your list. Neither is great. Sending to unverified catch-all addresses is the leading cause of bounce-rate spikes that damage sender reputation after a list that looked clean. Skipping them means 20-40% of your prospecting work produced contacts you can't actually reach.

Every native verification integration in Clay handles catch-all domains the same way: flags them and stops. That's not a limitation of any specific tool — SMTP-level verification structurally cannot resolve catch-all domains, because the server gives the same response for every address. The tools are doing the right thing by flagging them rather than guessing. The question is what you do with those flagged rows after.

Resolving Catch-All Rows Instead of Skipping Them

Filtrat.io resolves catch-all domains to a definitive answer — deliverable or will-bounce — for each individual address. Instead of "this domain accepts everything, we can't tell," you get "this specific mailbox is confirmed real" or "this specific mailbox will bounce," same as a regular verification result.

On a 10,000-row Clay table where 1,400 addresses sit on catch-all domains, that turns 1,400 unresolved rows into verified results you can send to with confidence or remove knowing they'd bounce. The 20-40% of your list that was in limbo becomes actionable.

This runs inside Clay as an HTTP API column — not a native one-click integration, but a template you import or a prompt you paste. The setup takes about 60 seconds and works alongside whatever native verification you already ran. You don't replace your existing verification — you add a column that handles the rows your existing tool couldn't resolve.

Two Ways to Set It Up

1. Import the ready-made template (fastest)

Open our shared Clay template, which has the HTTP column pre-configured — endpoint, headers, body mapping, timeout, retry settings. Add your API key, point the input column at your email field, and run. The template handles the configuration so you don't touch any settings manually.

2. Copy the prompt into a new HTTP column

If you want to add verification to an existing table rather than importing a new one, create an HTTP API column in Clay, open the Generate tab, and paste this:

Verify emails using filtrat.io REST API.
This is a POST request with a JSON body.
Do NOT use GET. Do NOT use query parameters.

Method: POST
URL: https://api.filtrat.io/v1/verify/email
Authorization: Bearer token.
Header value must start with the word Bearer followed
by a space and then the API key:
  Bearer YOUR_API_KEY

Body (JSON):
{
  "email": "/Email",
  "resolve_catchall": true,
  "skip_cache": false
}
The body MUST be sent as raw JSON.
"resolve_catchall" MUST be boolean true, not a string.

Response timeout: 90000 milliseconds.

From the response, extract these fields into separate columns:
- $.status → column name "Status"
- $.diagnosis → column name "Diagnosis"
- $.domain_intelligence.catch_all → column name "Catch-All"
- $.domain_intelligence.mx_provider → column name "MX Provider"
Do not add any fields beyond these four.

Replace YOUR_API_KEY with your key from the filtrat.io dashboard. Clay's AI configures the HTTP column from this prompt — endpoint, headers, body, field extraction.

After pasting, check these settings in the HTTP column config (Clay's AI usually applies them from the prompt, but not always):

Response timeout90000 ms (90 seconds)
Retry on failureOn
Max retries2
Status codes to retry429, 502, 503, 504
Rate limit — requests60
Rate limit — duration60000 ms

The 90-second timeout matters — catch-all resolution checks the individual mailbox, which takes longer than a standard SMTP ping. Clay's default timeout of 1 second will fail on every row.

Finding Emails, Not Just Verifying Them

The same setup works for email finding. If your Clay table has names and company domains but no email addresses, a second HTTP column can find verified emails using the finder endpoint:

Find business emails using filtrat.io REST API.
This is a POST request with a JSON body.
Do NOT use GET. Do NOT use query parameters.

Method: POST
URL: https://api.filtrat.io/v1/finder/search
Authorization: Bearer token.
Header value must start with the word Bearer followed
by a space and then the API key:
  Bearer YOUR_API_KEY

Body (JSON):
{
  "first_name": "/First Name",
  "last_name": "/Last Name",
  "domain_or_url": "/Domain",
  "skip_cache": false
}
The body MUST be sent as raw JSON.

Response timeout: 90000 milliseconds.

From the response, extract these fields into separate columns:
- $.email → column name "Found Email"
- $.status → column name "Email Status"
- $.confidence → column name "Confidence"
Do not add any fields beyond these three.

Same settings (timeout 90000, retries 2, rate limit 60/60000). The column returns the person's confirmed work email — the mailbox is verified before the result comes back. If no email can be confirmed, the row shows not-found and you're not charged for it.

The shared template includes both columns — verify and find — pre-configured.

How It Fits Alongside Your Existing Clay Workflow

This isn't a replacement for whatever verification you're already running. The typical setup is two passes:

First pass — your existing native integration

Apollo, Hunter, whatever you use. It handles the straightforward rows: valid addresses get confirmed, invalid ones get flagged, and catch-all domains get marked as unresolved. This is fast, one-click, and handles the majority of the list.

Second pass — the filtrat.io HTTP column

Running only on the rows your first pass left unresolved. Filter your table to the catch-all/accept-all/unknown rows, then run the filtrat column on that subset. Those rows go from "unknown, can't tell" to "confirmed deliverable" or "confirmed will bounce."

You end up with a table where every row has a definitive answer — the easy ones from your native integration, the hard ones from the catch-all resolution column. No rows left in limbo, no guessing on the 20-40% that catch-all domains represent.

What It Costs

Verification costs 0.5 credits per email. Catch-all resolution — the part that resolves the rows other tools flag as unknown — costs 3 credits per resolved address. If the catch-all can't be resolved, you're not charged. Found emails cost 12 credits per confirmed result. Not-found is free.

Example: 10,000-row list with 1,400 catch-all

Your first-pass native verification handles 8,600 rows at whatever that tool charges. The filtrat catch-all resolution column handles the remaining 1,400 at 3 credits each = 4,200 credits. The $10 Starter plan includes 12,000 credits — enough to resolve the catch-all segment of a 10,000-row list with credits to spare, for a fraction of what most tools charge for the initial verification alone.

Resolve the Rows Your Verifier Left Behind

200 free credits. No card. Import the template, add your API key, run on your catch-all rows.

Related