Verify Every Email in Your Clay Tables with MillionVerifier

Add a MillionVerifier column to any Clay table and know which emails are safe to send before a single one leaves Clay. Built for list builders, email waterfalls, and outbound teams that can't afford bounces.

The MillionVerifier Clay integration is a native Clay action, Validate Emails with MillionVerifier, that checks the email address in each row of a Clay table and returns its validity status. You connect your own MillionVerifier account, add the action as a column, and use the result to filter, route, or retry rows before you push them to a sequencer or CRM. It's available on Clay's Growth plan and above.

Add MillionVerifier in Clay

Get your API key

99%+ accuracy · Catch-all and unknown credits refunded by default

How MillionVerifier works inside a Clay table

Clay organizes everything in tables. Each row is a person or a company, and each column either holds data or runs an enrichment. The MillionVerifier action is one of those enrichment columns: when it runs, Clay sends the row's email address to MillionVerifier with your API key and writes the verification result back into the cell.

Because it's a column, it runs down the whole table. You verify a list as a list, before anything is sent, rather than contact by contact while a campaign is already running.

New to Clay? Clay is a go-to-market data platform for building and enriching prospect lists. It gives you access to 200+ data providers, combines them in waterfalls so a second provider fills the gaps the first one missed, and runs AI research with Claygent. Finished rows go to a CRM, an outbound tool, or Clay's own sequencer.

What the column returns, and what to do with each row

A filter or formula on this column decides where each row goes next. Most teams keep one view for sendable rows and one for everything else.

Where verification belongs in a Clay workflow

Verification goes after an email is found and before anything is sent. In a Clay table, that means the MillionVerifier column sits right after your email-finding columns, and every export, CRM sync, or sequencer push reads from it.

In a waterfall like the one in playbook 2, an invalid or disposable result sends the row on to the next email provider, so one bad address doesn't cost you the lead. Clay doesn't do this on its own; it happens because of the run conditions you set.

Three rules keep the column accurate and cheap:

• Run it only when there's something to check. Set the column's run condition so it only runs when the email cell isn't empty. Rows without an email then skip the check entirely.
• Verify before you send, not after. Push only rows marked ok to your sequencer, and keep catch-alls in their own segment with lower sending volume.
• Don't re-verify by accident. If your table re-runs columns automatically, make sure the MillionVerifier column only runs again when the email itself changes. Planned re-checks are different: re-running unknown results, or refreshing old contacts as in playbook 5, is worth doing. Unplanned re-runs just use another Clay Action and another MillionVerifier credit each time.

6 Clay playbooks with MillionVerifier

Each playbook is a set of columns you add to a Clay table, and you can combine several in the same table. They draw on different MillionVerifier features, from single-email checks inside a waterfall to bulk verification before data ever reaches Clay.

1. Verify the whole outbound list before export

Goal: Send cold email only to addresses that exist, so bounces never get the chance to hurt your domain.

Columns:

1. Source: Import people from a CSV, a Clay people search, or a CRM list.
2. Find work email: Use your email provider of choice or Clay's waterfall.
3. Validate Emails with MillionVerifier: Run only when the email cell isn't empty.
4. Send status (formula): ok becomes "send," catch_all becomes "low volume," unknown and error become "re-check," and invalid and disposable become "don't send."
5. Push to your sequencer: Send "send" rows to Instantly, Smartlead, lemlist, or Clay's own sequencer, and "low volume" rows to a separate, lower-volume campaign. Keep "re-check" rows in their own view and re-run the column on them the next day.

Why it works: The whole list is verified before the campaign starts, which is how cold email lists should be handled. Nothing is checked halfway through a sequence, after the damage is done.

2. Verify-and-fallback email waterfall

Goal: Find a deliverable email for as many rows as possible, and only pay a second provider when the first one fails.

Columns:

1. Find email with provider A.
2. Validate with MillionVerifier.
3. Find email with provider B: Run only if provider A found nothing, or if MillionVerifier marked A's email invalid or disposable. Catch_all and unknown results don't trigger provider B. Catch-all is a property of the whole domain, so B's address at the same company would almost always come back catch_all too, and unknown results go to re-check instead.
4. Validate with MillionVerifier again: Run only when provider B's email is different from A's, so you don't pay to re-check an address you already know is bad.
5. Final email and Final status (formulas): Take the first email marked ok. If there isn't one, take the first email marked catch_all. Write its result to Final status, so your send-status formula can tell sendable rows from low-volume ones. Rows with neither stay empty, and rows whose best result is unknown go to your re-check view.

Why it works: Waterfalls improve coverage, but an unverified waterfall just finds more addresses, not more deliverable ones. Putting MillionVerifier between providers means the final email column never holds an address that failed verification, and catch-all leads are kept and labeled instead of lost.

3. Catch-all tiering for B2B lists

Goal: Keep catch-all leads instead of deleting them, without letting them drag down your main campaign.

Columns:

1. Validate Emails with MillionVerifier.
2. Send tier (formula): ok becomes Tier 1, catch_all becomes Tier 2, unknown and error become "re-check," and invalid and disposable are excluded.
3. Push by tier: Tier 1 goes to your main campaign. Tier 2 goes to a separate, lower-volume campaign or sending domain.

Why it works: MillionVerifier's Catch-All Email Verifier is built into every check, so many catch-all addresses come back as a clear ok or invalid. The ones that stay catch_all are tagged, so you decide how much risk to take rather than throwing the leads away.

4. Inbound lead check

Goal: Stop fake, mistyped, and throwaway addresses before they reach your CRM or your sales team.

Columns:

1. Webhook source: Send form fills or product signups into a Clay table as they arrive.
2. Validate Emails with MillionVerifier.
3. Route flag (formula): Mark disposable and invalid results as "don't route."
4. Push and alert: Send ok leads to HubSpot or Salesforce and notify sales. Flagged leads go to a review view instead.

Why it works: Disposable inboxes are flagged as their own result, so low-quality signups never get assigned to a rep or enrolled in a nurture flow.

5. CRM hygiene with a status field

Goal: Give every CRM contact a visible email status that sales and marketing can filter on.

Columns:

1. Import contacts from HubSpot or Salesforce, one segment at a time, such as contacts whose Last verified date is empty or more than 90 days old.
2. Validate Emails with MillionVerifier.
3. Update the CRM record: Write the result to a custom "Email status" field and the date to a "Last verified" field, so the next refresh knows which contacts are due.
4. Optional repair: For invalid rows, run a find-email column to look for a new address, then validate it.

Why it works: Verification becomes part of the record itself, so reps stop working dead contacts and marketing can exclude them from sends.

6. Bulk-verify legacy lists before enrichment

Goal: Avoid spending Clay Actions on contacts that are already dead.

Steps:

1. Upload the old list to MillionVerifier's Bulk Email Verifier.
2. Download the clean segment, either ok results only or ok plus catch-all.
3. Import only that file into Clay for enrichment, research, and personalization.

Why it works: Every row verified inside Clay uses a Clay Action, and Clay plans limit how many rows a table can hold. Cleaning a very large database in bulk first means Clay only works on contacts worth enriching.

How to add MillionVerifier to a Clay table

You need a Clay workspace on the Growth plan or higher, a MillionVerifier account with credits, and a table with an email column.

1. Copy your MillionVerifier API key. In MillionVerifier, click your profile icon, open Account settings, and select API KEYS.
2. Add the enrichment. In your Clay table, add an enrichment column, search for MillionVerifier, and choose Validate Emails with MillionVerifier.
3. Connect your account. Paste your API key when Clay asks for it. The action requires your own MillionVerifier account, so verifications use your MillionVerifier credits.
4. Map the email. Point the action's Email Address input at the column that holds each row's email.
5. Set the run condition. Make the column run only when the email cell isn't empty. In a waterfall, also add the condition from playbook 2.
6. Test on a few rows first. Run the column on 10 rows, check the results, then run it on the rest of the table.

From there, build on the result: a formula column for send status, a filtered view for sendable rows, or a push to your sequencer or CRM.

Tip: Testing on 10 rows takes a minute and costs about 10 Clay Actions and up to 10 MillionVerifier credits. Finding a wrong mapping after the column has run on 20,000 rows costs much more.

What a verification costs in Clay

Why MillionVerifier for Clay users: When you bring your own key, every validation provider in Clay costs the same single Action per check. The real difference is the provider's own price and how many rows get a usable answer. MillionVerifier costs less than half a cent per check ($39 for 10,000 credits) and, by default, refunds the credit on catch-all and unknown results. Its built-in catch-all resolution also turns more risky rows into a clear ok or invalid, which gives your waterfall and send-status formulas a definite answer to act on.

Since March 2026, Clay bills with two meters: Data Credits for data that Clay buys on your behalf, and Actions for the work Clay performs. Because the MillionVerifier action uses your own account, each verification draws on Clay Actions and MillionVerifier credits, but not on Clay Data Credits.

Worked example: Verifying a 10,000-row outbound list uses 10,000 Clay Actions, a quarter of the 40,000 included in Clay's Growth plan each month. On the MillionVerifier side, it uses up to 10,000 credits, which cost $39, and credits for catch-all and unknown results are refunded.

Ways to keep the cost down:

• Filter first, verify second. Apply your ICP filters before the MillionVerifier column, so you only verify people you'll actually contact.
• Deduplicate before you verify. The same email in two rows costs two Actions and two credits.
• Skip empty and unchanged emails. Use the run condition from the setup steps, and don't let the column re-run when the email hasn't changed.
• Bulk-verify very large legacy lists outside Clay. Playbook 6 saves Clay Actions on contacts that turn out to be dead.

Frequently asked questions

Why Choose Millionverifier

We have kept improving our email verification software for over six years now, and we are incredibly proud of our outstanding 99%+ email verification accuracy.

99%+ Accuracy Rate

We have created MillionVerifier to provide the best email verification service possible for email marketers with higher email verification needs.

Best Email Verification Prices

Our customers love what we do. We work hard to deliver the best results and user experience for our customers.

Excellent Verification Service