← ClaudeAtlas

catch-all-risky-emailslisted

Decide what to do with catch-all, unknown and risky email addresses that verification can't confirm. Use whenever the user mentions catch-all domains, accept-all, risky emails, unknown verification status, greylisting, unverifiable addresses, or asks whether to send to addresses a verifier couldn't confirm. Also use when a verification run returns a large share of inconclusive results.
manypicom/sales-skills · ★ 0 · AI & Automation · score 72
Install: claude install-skill manypicom/sales-skills
# Catch-All and Risky Addresses Verification returns three kinds of answer: yes, no, and can't tell. The first two are easy. The third is where a meaningful share of every B2B list sits, and how you handle it decides whether you throw away good prospects or damage a sending domain. ## What the inconclusive statuses mean **`catch_all`** (also "accept-all"). The domain's mail server accepts every address at that domain without checking whether the mailbox exists. So the probe gets a positive answer that proves nothing. `anything@theirdomain.com` returns the same result as the real address. Catch-all is common — a large share of real B2B domains are configured this way, particularly larger companies and anyone running a mail gateway. It's a configuration choice, not a red flag. **`unknown`**. The probe couldn't complete. Greylisting (the server deliberately defers first contact), timeouts, rate limiting, or the server blocking verification probes entirely. This is usually a property of their infrastructure rather than of the address. ## The decision Blanket rules in either direction are wrong. | Approach | Cost | |---|---| | Discard all catch-all | You remove a large share of legitimate B2B prospects, often the biggest companies on your list | | Send to everything | Bounce rate rises to wherever the guessing was wrong, and the domain pays | The workable position: **send to them, but as a managed risk pool rather than mixed in with confirmed addresses.** ## How to manag