Email Verification in Clay: Adding the Receipts to Enrichment

Clay is one of the most powerful prospecting tools available — a no-code enrichment platform that waterfalls across dozens of data providers (Apollo, Hunter, Clearbit, PeopleDataLabs, and many more) to find and verify contact information. Clay users build sophisticated workflows: scrape a list of target companies, enrich with contact data, score leads with AI, route to outreach tools.

The email enrichment step in Clay is remarkably good at finding email addresses. It is not the same as verifying that those email addresses currently accept mail.

Data providers return the address they have on file — the address that was valid when their database was last refreshed, which could be weeks, months, or in some cases years ago. The person may have changed companies. The address may have been deleted. The domain may have changed MX configurations. Clay's waterfall increases the chances of finding an address; it does not tell you whether that specific address exists today.

MailCull is the verification layer that fills that gap — and it gives you the evidence to prove it.

Why Clay users care about evidence

Clay users are, as a cohort, more evidence-oriented than typical cold-outreach operators. The platform attracts people who want to understand their data, build auditable workflows, and make decisions based on structured signals rather than hunches.

That orientation maps directly onto what MailCull provides. Every verified address comes with an evidence chain: the specific signals that drove the verdict, in structured JSON.

{
  "email": "[email protected]",
  "status": "deliverable",
  "reason": "smtp_confirmed",
  "confidence": 0.95,
  "evidence": {
    "syntax": { "valid": true },
    "mx": { "records": ["aspmx.l.google.com"], "valid": true },
    "smtp": {
      "host": "aspmx.l.google.com",
      "ehlo": "probe-1.mailcull.io",
      "rcptTo": { "code": 250, "message": "OK" },
      "tlsUsed": true
    }
  }
}

That JSON is not just for display. Clay users can import verification results back into Clay tables, use the confidence score as a filter or sort signal, route contacts based on reason codes, and build downstream logic that treats a smtp_confirmed address differently from a smtp_catchall address.

What the verification covers

Surface layers (table stakes)

Syntax validation — structurally valid email address format.

Domain and MX records — domain exists, has mail servers configured. Reliable negative signal; passing MX is not a sufficient positive signal.

Typo detection — gmial.com, outloook.com, common transposition patterns. Data providers occasionally have typos in their databases.

Disposable and role address detection — throwaway services and role addresses (info@, contact@, hello@). Role addresses in a Clay workflow often come from company-level enrichment where no individual contact was found and a catch-all company inbox was surfaced instead. These are worth flagging.

SMTP mailbox probing

MailCull opens a direct SMTP connection to the receiving mail server and issues RCPT TO for each specific address. The server's response tells you whether the mailbox exists right now — not when the data provider last refreshed their database.

• 250 OK — deliverable
• 550 5.1.1 User unknown — does not exist; hard bounce
• 4xx — temporary deferral; inconclusive

The SMTP probe requires a properly configured sending identity (EHLO hostname with matching PTR and A records). Servers that reject probes from unconfigured identities will block verification tools that are not set up correctly. MailCull's probe infrastructure is configured with matching DNS records.

Microsoft 365 HTTP enumeration

Clay enrichment frequently surfaces business email addresses on M365 tenants. This is the single largest source of false positives in standard email verification.

M365's Exchange Online Protection layer accepts RCPT TO for any address on a tenant — real or fabricated. An SMTP probe returns 250 OK for both existing and non-existing M365 mailboxes. Without an additional check, the address appears deliverable when it will actually hard-bounce.

MailCull's three-step HTTP cascade uses Microsoft's authentication APIs to determine whether the specific account exists:

1. GetUserRealm — confirms M365 routing
2. GetCredentialType — checks active account presence for that username
3. Autodiscover v1 — cross-references account existence

The evidence chain records the cascade result explicitly:

"m365": {
  "tenant": true,
  "getUserRealm": { "exists": true },
  "getCredentialType": { "accountExists": true },
  "autodiscover": { "reachable": true }
}

When the cascade and SMTP agree on deliverable, confidence is high. When they disagree (m365_smtp_disagreed), the address is marked risky — M365 accepted the SMTP probe but the cascade says no active account.

Catch-all detection

Catch-all domains accept all RCPT TO. Individual mailbox verification is impossible. MailCull flags these, and the evidence chain records the catch-all probe result.

In Clay-enriched lists, catch-all is common for SMB and startup companies that run permissive mail server configurations. The catch-all status is not the same as undeliverable — it means "cannot confirm, proceed with caution."

Building a Clay + MailCull workflow

Option A: export and batch verify

The simplest workflow:

1. Build your enriched prospect table in Clay, including the email column from waterfall enrichment
2. Export as CSV
3. Upload to MailCull Verify List
4. Import the verification results (status, reason, confidence) back into Clay as new columns
5. Use Clay's filter/sort to route by verification status before exporting to your sender

This adds the verification layer without changing your existing Clay setup.

Option B: add MailCull as a Clay enrichment step

If you want verification inline in your Clay table workflow, you can call MailCull's API directly from a Clay HTTP API integration step. The endpoint returns the full evidence JSON for each address, which you can map to columns in your Clay table.

Clay's API step supports POST requests with JSON payloads. Point it at api.mailcull.io/v1/verify with your API key (Pro plan includes API access) and map the response fields — status, reason, confidence, smtp.code, m365.accountExists — as separate columns.

This way, every row in your Clay enrichment table has a verification column alongside the enriched email, populated at enrichment time rather than as a post-processing step.

Option C: conditional routing in Clay

With verification results in your Clay table, you can build conditional logic:

• Route status = deliverable to Smartlead / Instantly / lemlist directly
• Route status = risky, reason = smtp_catchall to a lower-confidence track
• Route status = risky, reason = m365_smtp_disagreed to a LinkedIn-only track (email removed)
• Route status = undeliverable to discard or to re-enrichment (try a different provider)

The re-enrichment path is especially useful: if MailCull returns undeliverable for an address from Provider A, you can trigger Clay to try Provider B's waterfall for the same contact.

What verification tells you about your enrichment providers

Clay users who run verification across multiple enrichment providers often discover that provider quality varies significantly by industry, company size, and geography.

Typical patterns:

• Apollo has broad coverage but higher staleness on SMB contacts (frequent employee churn)
• Hunter is strong on generic company emails but weaker on direct individual contacts
• PeopleDataLabs has high coverage for tech industry, variable quality on traditional industries
• Clearbit (now HubSpot) skews toward marketing contacts, solid on mid-market tech

Running MailCull verification on a batch from each provider and comparing the deliverable rate by source tells you which providers to prioritise for which target verticals. That signal is hard to get any other way.

The confidence score in Clay

MailCull returns a confidence score between 0 and 1 with each result. This is useful as a filter column in Clay:

• confidence >= 0.90 — high confidence deliverable; include in all sequences
• confidence 0.75–0.90 — moderate confidence; include with monitoring
• confidence < 0.75 — low confidence; review reason code before including

The score is driven by the combination of checks that fired. A smtp_confirmed address on a non-catch-all domain with matching M365 cascade scores ~0.95. A smtp_catchall risky address scores ~0.65. A m365_smtp_disagreed risky scores ~0.55.

---

You came here to add verification receipts to your Clay enrichment workflow. MailCull returns SMTP-level proof and M365 cascade results for every address — structured JSON that maps directly into Clay columns.

Verify your Clay enrichment output in MailCull — free up to 1,000 rows →