Apollo Catch-All Domain Flag Explained
By Aria Pramesi, founder of InboxPolicy · Updated July 9, 2026
If Apollo marked a contact's domain as catch-all, it means the domain accepts mail sent to any address, so Apollo's verifier can't fully confirm that one specific mailbox is real. It's not a bounce prediction and it's not a clean bill of health either — it's an unresolved result that needs a decision, not a guess.
What Apollo's catch-all flag actually means
When you're prospecting in Apollo and see a contact or domain marked catch-all, it means the receiving mail server is configured to accept messages for any address at that domain, whether or not a real mailbox exists behind it. Apollo marks these contacts as catch-all because standard SMTP verification, the technique most email tools rely on, can't distinguish a real inbox from a made-up one on a domain like this.
Apollo says it doesn't depend on SMTP checks alone, and tries to use additional signals from its network of linked mailboxes to differentiate valid from invalid addresses even on catch-all domains, with a filter you can use to include or exclude catch-all contacts from your search results. That's a useful starting signal. It is not a guarantee, especially for a domain Apollo hasn't seen recent mail activity on.
Why this happens technically
Mail servers can be configured to reject RCPT TO for any address that doesn't have a mailbox behind it, which is what lets a verifier confirm a specific address is real or fake. A catch-all domain does the opposite: it accepts RCPT TO for every address, real or invented, often as a deliberate choice by IT (so no legitimate mail bounces due to a typo or an old alias) or simply because the mail server was never configured to reject anything. Either way, the SMTP handshake that would normally settle the question comes back accepted no matter what you send it, so the mailbox-level question stays open.
The real question: should you email them anyway?
Roughly 30-40% of B2B email addresses sit on catch-all domains. That number matters more than the flag itself: if you skip every catch-all contact in Apollo, you're not being cautious, you're throwing out a third or more of your addressable list before you've sent a single email. If you email all of them without any further check, you're accepting whatever bounce rate that unresolved third produces, which can drag down sender reputation for every campaign that follows.
Neither extreme is the right default. The honest answer is that a catch-all flag is a segmentation signal, not a send/don't-send answer by itself. See are catch-all emails safe to send to for a deeper look at the safety tradeoffs, catch-all flags in Instantly, Smartlead, and Clay for how other tools label the same signal, and catch-all vs. accept-all if you're not sure the two terms mean the same thing (they do, different vendors just use different labels).
What to do with Apollo's catch-all contacts
1. Segment, don't blend
Export or tag catch-all contacts separately from Apollo's other statuses so they get their own sending policy instead of inheriting whatever policy applies to confirmed-valid addresses.
2. Run a second verification pass that returns a decision
A second status label doesn't help, you already have one. What helps is a verifier that returns an explicit action with evidence attached. InboxPolicy is built for exactly this: it returns review for catch-all evidence by default rather than guessing send, and every response includes a confidence score plus the underlying SMTP evidence so a human or workflow has something to act on. Under a more aggressive policy setting it can return send_with_caution instead, but it will never silently mark a catch-all address as safe. Verification runs $0.01 per fresh decision via x402, a pay-per-call protocol settled in USDC on Base, no account or API key required. See the catch-all email verifier guide for how the full decision pipeline works.
3. Route by action, not by status
InboxPolicy's decisions map to five actions: send, send_with_caution, review, retry_later, and avoid. Wire your outreach tool or agent to route each action differently, full send for send, a slower or more personalized touch for send_with_caution, a human queue for review, instead of treating every non-rejected address the same way.
4. Monitor bounces and adjust
Whatever policy you land on, watch the actual bounce rate coming back from your catch-all segment specifically. If it's climbing, tighten the policy (route more to review); if it's clean, you can afford to loosen it. This is a moving target, not a one-time setting.
Full API and MCP server details, including how to call verify_email or decide_send directly from an agent workflow, are in the docs.
Frequently asked questions
What does the catch-all flag mean in Apollo?
It means the contact's domain is configured to accept mail sent to any address, so Apollo marks these contacts as catch-all because its verifier cannot fully confirm that specific mailbox exists the way it can on a domain that rejects invalid addresses. It is not a claim that the address is bad, and it is not a claim that it is good.
Should I email catch-all contacts from Apollo?
Not automatically, and not never. Roughly 30-40% of B2B addresses sit on catch-all domains, so blanket-skipping them means skipping a third of your list, while blanket-sending to all of them will raise your bounce rate. Segment catch-all contacts separately, add supporting signals (a real name, a role-based vs. personal-looking address, recent engagement), and route the ones you're unsure about through a second verification pass before a full send.
How do I verify Apollo catch-all emails?
Export the catch-all segment and run it through a verifier that returns an explicit decision rather than just another status label. InboxPolicy returns review for catch-all evidence by default, with a confidence score and the underlying SMTP evidence attached, so a workflow or human reviewer has something concrete to act on instead of a second unresolved flag.
Does a catch-all flag mean the email is invalid?
No. Catch-all means unresolved, not invalid. The domain's mail server accepts RCPT TO for any address, valid or not, so the SMTP check that would normally reject a bad mailbox can't do its job. A malformed or clearly nonexistent address is a different, more confident kind of result than a catch-all flag.
Does Apollo's catch-all verification differ from other tools?
Apollo says it doesn't rely on SMTP checks alone and tries to differentiate valid from invalid addresses on catch-all domains using its own network signals, and it offers a filter to include or exclude catch-all contacts from search and export. Treat that as a starting signal, not a final answer, especially for cold lists Apollo hasn't seen mail activity for.