Clean Email List

Inputs

Steps

1. 01

   Collect the inputs

   1. The list (CSV/table) and which column holds the email. Never edit other columns. 2. The purpose, cold volume send vs CRM refresh vs re-engagement. It decides the policy segments: for cold sends, role/generic mailboxes (info@, support@…) go to remove and personal/freemail goes to risky; for other purposes both go to risky.

   Expand
2. 02

   Free passes (zero credits, deterministic code, not an LLM)

   Run in order, recording per-row reason + evidence at each: 1. Normalize + dedupe. Trim, lowercase for comparison (keep the original string). Exact-match duplicates: keep the first, mark the rest remove: duplicate with a pointer to the kept row. 2. Syntax. One local-part @ one domain with a dot, no spaces, a cheap structural check, not full RFC. Failures → remove: syntax-invalid, quoting the string. Never "fix" a typo and keep the fixed version silently. 3. Role/generic screen. Local-part blocklist (production lists run ~40 tokens): admin, info, contact, support, sales, billing, hr, press, help, hello, office, team, marketing, careers, jobs, noreply, no-reply, postmaster, abuse, webmaster… Segment per the Step 1 policy, these are policy calls, not deliverability verdicts (a support@ box may be genuinely read). 4. Disposable domains. Known disposable providers (mailinator, guerrillamail, yopmail…) → remove: disposable. 5. MX per unique domain (any DNS tool, don't hardcode a DoH URL; some networks block them). Three shapes: NXDOMAIN or no MX → dead; null MX (single record 0 .) → the domain declares it takes no mail, dead *even though a record exists*; real MX → survives. Dead domains → remove: dead-domain for every row on them, quoting the DNS answer. This kills paid calls on dead rows for free.

   Expand
3. 03

   Classify survivors (Clay-native, ~free)

   Run extract-email-components (Clay action; catalog tier 1) per surviving row: it returns domain plus isLikelyPersonalEmail / isLikelyCompanyEmail / isLikelyEducationEmail. Personal → risky under a cold-send policy. Read the actual charge from run usage metadata (verified at 0 credits + 0 action executions in one workspace, but read it, don't assume).

   Expand
4. 04

   Paid validation on what's left (approval gate)

   Pick a validator from the live catalog (clay workflows actions list), lowest priorityTier that separates catch-all from valid (tier 2 is typically ZeroBounce validate-email or enrichley-verify-email, ~0.1 credits/check). State survivor count × per-check cost and get approval before running. Then call it per row (Clay MCP execute_clay_action); checks return in seconds for every verdict. Map field PAIRS, never one field, vocabularies invert across validators: ZeroBounce puts catch-all at status: valid + sub_status: catch_all; Enrichley puts it at valid: false + result: catch_all. Verdicts: plain valid (sub_status: "", empty string) → keep; catch-all → risky (Enrichley's catch_all_validated upgrade = keep, probe-confirmed); do_not_mail / suppression / disposable sub-statuses → remove, quoting the sub-reason; invalid → remove; unknown, timeouts, empty payloads → could-not-verify, never rounded either way. Fuse validator with classifier: a freemail address can validate as deliverable (observed live: valid / sub_status: alternate + free_email: true on a Gmail address), a mailbox verdict never overrides the policy segment. Run status is not data: it reports SUCCESS for every verdict. For many hundreds of rows or a recurring clean, build it as a Clay table/workflow instead and say so. ## What good looks like - Reconciliation is the first check: rows in = keep + risky + remove + could-not-verify. If the numbers don't add up, a row was dropped silently, the cardinal failure of list cleaning. - Every removed row carries a reason AND quoted evidence (the DNS answer, the validator field pair, the duplicate pointer), an audit trail, not a verdict. - The common mistake: reading one validator field as a boolean. Catch-all hides inside the safest-looking field, in opposite directions per provider. - Could-not-verify is an honest segment, not a failure, a common shape is unknown / mail_server_temporary_error, which is retryable later; the user decides whether to spend more checks. ## Rules - MUST account for every input row in exactly one segment, never silently drop. - MUST run all free passes before any paid call, and state cost + get approval first. - MUST report raw provider fields alongside each verdict. - NEVER guess a verdict for an unverifiable row; NEVER silently correct a malformed address; NEVER report catch-all, role, or disposable rows as plain valid.

   Expand

Outputs