Catch-All and Bounce Flags in Cold Email Tools: Instantly, Smartlead, Clay
By Aria Pramesi, founder of InboxPolicy · Updated July 9, 2026
Instantly, Smartlead, and Clay each ship their own vocabulary for risky and catch-all addresses, Risky status, community bounce list, catch-all verification, but every one of those flags traces back to the same SMTP reality: a catch-all domain accepts RCPT TO for any address, so no tool can confirm a specific mailbox from that response alone.
Why every cold email tool has its own catch-all vocabulary
Roughly 30-40% of B2B email addresses sit on catch-all domains, so every cold-email platform has had to build something to handle them. The underlying SMTP behavior is identical everywhere: a catch-all mail server accepts the recipient regardless of whether the exact address is real, so a single SMTP session can't distinguish a live inbox from a fabricated one. What differs is what each tool does with that ambiguity, some bucket it into a broader "risky" status, some cross-reference bounce history from other users, some treat it as valid unless you opt out. (The base vocabulary itself is covered in catch-all vs accept-all.) None of that changes the underlying fact: catch-all is an unresolved mailbox, not a confirmed one.
Instantly: catch-all and Risky status
Instantly's verification labels a catch-all domain as one it accepts mail for any address, and its help documentation groups that result, along with other unconfirmed outcomes, under a Risky status rather than a hard Valid or Invalid. The tool can tell you the domain is catch-all; it cannot tell you whether the specific address you're about to email is a monitored mailbox or one nobody reads. Instantly's own guidance frames catch-all resolution as valuable specifically because it reclaims otherwise-unusable addresses back into a sendable list, but "sendable" here still means unconfirmed, not verified.
What it doesn't tell you: whether the individual mailbox exists, is monitored, or has bounced elsewhere. A Risky label is a status, not a routing decision.
Smartlead: community bounce list and bounce auto-protection
Smartlead ships two related but distinct features. The community bounce list is a documented, real feature (see Smartlead's help center and API reference): its lead-import API exposes an ignore_community_bounce_list parameter that, left at its default, filters out addresses that have previously bounced in campaigns run by other Smartlead users. It's a crowd-sourced deny-list, not a live check on the address in front of you right now. Separately, High Bounce Rate Auto Protection is a campaign-level guardrail: you set a bounce-rate threshold and Smartlead automatically pauses the campaign if your live sends cross it, which protects your sender reputation after the fact rather than screening addresses before you send.
What it doesn't tell you: the community bounce list reflects other users' send history, not a fresh SMTP check on your specific list, so it can miss a mailbox that just went dead or hold onto a stale bounce that no longer applies. Auto-protection only fires once bounces are already happening.
Clay: catch-all verification statuses
Clay's documented email verification statuses include Valid, Invalid, Catch-all, Unknown, and Role-based. Clay defines catch-all plainly: domains that accept all email addresses, even ones that may not be monitored or exist. The default behavior is the one worth knowing, Clay counts catch-all addresses as usable unless you turn on a stricter setting (commonly surfaced as an "only mark Safe to Send as valid" toggle, depending on which verification provider is wired into your table) to exclude them.
What it doesn't tell you: "counted as valid by default" is a workflow default, not a confirmation the mailbox is real. If you never touch that setting, catch-all and genuinely verified addresses flow into your list looking the same.
Unified decision table
Same underlying signal, different vocabulary. Here's how the flags line up and what to actually do with each one.
| Tool flag | What it actually means | Recommended action |
|---|---|---|
| Instantly — Valid | Live SMTP check confirmed the specific mailbox | send |
| Instantly — Risky / Catch-all | Domain accepts all mail, mailbox unconfirmed | review |
| Smartlead — community bounce list match | Address bounced in another user's campaign, not yours | review / avoid |
| Smartlead — bounce auto-protection triggered | Your live send already crossed your bounce threshold | avoid, pause and re-verify the list |
| Clay — Catch-all (default) | Domain accepts all mail, counted valid unless you opt out | send_with_caution / review |
| Clay — Unknown | Temporary verification failure | retry_later |
| InboxPolicy — catch_all evidence tag | SMTP accepted the domain but couldn't confirm the mailbox | review (or send_with_caution under an aggressive policy) — never guessed send |
What InboxPolicy does differently
InboxPolicy doesn't add a fourth vocabulary to memorize, it returns an explicit send decision, send, send_with_caution, review, retry_later, or avoid, backed by the SMTP evidence behind it, rather than a status label you still have to interpret. A catch-all result is always tagged and returned as review (or send_with_caution if you opt into an aggressive policy), never silently upgraded to a guessed send. Verification is $0.01 per fresh check, pay-per-call via x402 in USDC on Base with no account or API key required, and a result already checked in the last 72 hours returns free from cache instead of re-billing you. See the full mechanics in the catch-all email verifier guide, or how this compares to Apollo's catch-all flag and the broader question of whether catch-all emails are safe to send to.
Frequently asked questions
What does catch-all mean in Instantly?
In Instantly, a catch-all result means the domain accepts mail for any address, so its verification engine can identify the domain as catch-all but cannot confirm the specific mailbox is real. Instantly groups these under a Risky status alongside other unconfirmed results, rather than a hard Valid or Invalid.
Is Smartlead's community bounce list reliable?
Smartlead's community bounce list is a real, documented feature (the ignore_community_bounce_list API parameter skips it on import) that filters addresses which bounced in campaigns run by other Smartlead users. It's a useful aggregate signal, but it isn't a live SMTP check on the address you're about to send to, so it can miss a mailbox that recently became invalid or wrongly carry over a bounce that no longer applies.
Should I send to catch-all emails flagged by my cold email tool?
Not automatically. A catch-all flag means the tool could not confirm the mailbox exists, it is not a bounce prediction and not a safety guarantee either. Treat it as a review case: check other signals (a prior reply, a known job title, engagement history) before sending, rather than either blanket-excluding catch-all addresses or sending to all of them.
How do I verify catch-all emails before a campaign?
Run syntax and MX checks first to rule out malformed addresses and dead domains, then a live SMTP check to see how the mail server responds. On a catch-all domain the SMTP step still can't confirm the individual mailbox, so the honest output is a review flag with the supporting evidence, not a guessed Valid or Invalid. InboxPolicy runs this full sequence and returns that evidence with a send / send_with_caution / review / retry_later / avoid action for $0.01 per check.
Does Clay mark catch-all emails as valid?
By default, yes. Clay's email verification statuses include Catch-all as a distinct category, but out of the box it treats catch-all addresses as usable. Clay offers a setting, often described as an Only Safe to Send toggle depending on which verification provider is connected, that excludes catch-all results if you want a more conservative list.