Playbooks / Playbook
What to do with a catch-all email result
The verifier labels a catch-all domain instead of guessing. From there you have exactly two honest branches: try a personal address with find_personal_email, or drop the row. find_personal_email is not a waterfall endpoint and bills on any 2xx, including one that returns nothing.
Pattern: email_verifier → read status → branch to find_personal_email, a separate sending track, or the bin
In short: A RichAPI pattern for handling catch-all domains. POST https://api.richapi.ai/api/v1/email_verifier returns a status field that labels catch-all domains rather than forcing a deliverable or undeliverable verdict. A catch-all mail server accepts mail addressed to any local part, so no verification method can confirm that a specific mailbox exists behind one. The two honest branches are to attempt a personal address via POST /find_personal_email, or to drop the row. find_personal_email is not a waterfall endpoint: it bills a flat credits_per_call on any 2xx response, including one that returns no address. email_verifier is a waterfall endpoint, so a 2xx carrying success:false returns billed:false and costs zero. Authentication uses the x-api-key header. New accounts get 100 free credits and require no credit card.
Last updated November 4, 2026
Credit math
Worked example at stated counts: 1,000 verifications at 2 credits = 2,000 credits, minus zero for any call the waterfall could not resolve. 280 come back catch-all. Sending all 280 to find_personal_email at 5 credits per call = 1,400 credits charged whether or not an address comes back. Sending only the 60 highest-value rows = 300 credits. 2 credits per email_verifier call, 5 credits per find_personal_email call
ROI math
The decision is not whether catch-alls are worth money, it is which catch-alls are. A blanket personal-email fallback on a large list is the single easiest way to spend credits on rows you would never have called. Convert at your tier rate on /pricing.
Owned internally by
Whoever owns deliverability — usually the same person who gets blamed for the bounce rate
Best for
Anyone whose list skews mid-market or enterprise, where catch-all configurations are common and a blanket drop deletes real prospects
- 01
Sign up at app.richapi.ai and copy your key.
100 free credits, no card.
- 02
Verify the address and branch on status, not on the valid boolean.
valid alone cannot express a catch-all honestly.
- 03
Score the catch-all rows on something you already know — account tier, title seniority, whether a rep asked for them.
- 04
Send only the rows that clear that bar to find_personal_email, and budget for the calls that come back empty, because they still bill.
- 05
Route the survivors onto a separate sending track with a lower volume cap and their own bounce monitoring.
Verify these twelve addresses. For any that come back as a catch-all domain,
tell me which ones they are and do not guess whether they are deliverable.
Then wait for me to decide which of them are worth a personal email lookup.
A catch-all is an answer, not a failure
A catch-all domain accepts mail addressed to anything. jane@, ceo@, qqqqq@ — the server takes them all at the SMTP handshake and sorts it out later, or never. There is no verification technique, ours or anyone's, that can prove a named mailbox exists behind that configuration. The server refuses to distinguish, on purpose.
So every verifier faces the same fork, and what separates them is honesty about it. Return valid: true and you have quietly handed the user a bounce risk dressed as a verdict. Return valid: false and you have deleted a pile of real, reachable prospects — and catch-all configurations cluster at exactly the mid-market and enterprise domains most people want.
email_verifier labels it in status and lets you decide.
The decision is yours, it is a business decision rather than a data one, and there are only two defensible ways to make it.
Branch one: try a personal address
find_personal_email looks for an address outside the corporate domain. For a senior contact at a company whose mail server tells you nothing, that is sometimes the only route that exists.
Read the billing carefully, because this is where budgets leak. find_personal_email is not a waterfall endpoints endpoint. It bills a flat rate on any 2xx, including one that comes back with nothing. The "a miss costs nothing" rule covers email_finder, email_verifier and phone_finder, and it stops there. Every other endpoint in the catalog, this one included, bills on a 2xx whether or not it found anything useful. A non-2xx never bills, on any endpoint.
Which makes branch one a filter problem, not a pipeline problem. Running it across every catch-all row on a large list is how you turn a hygiene step into a line item.
Branch two: drop the row, or isolate it
Dropping is underrated. If the row is a mid-funnel title at a company you were never going to prioritize, the catch-all label has done its job: it saved you a send and a bounce.
The middle option is isolation. Keep catch-all rows, send to them from a separate domain, cap the daily volume, and watch the bounce rate on that track alone. You learn the truth empirically without putting your primary sending reputation on the line. That is more operational work than a toggle, and it is the only method that actually produces evidence.
What you should not do is dump catch-alls into the main sequence because the verifier "didn't say no." Bounce rate is the input that gets a sending domain throttled, and it is the one you control completely.
What catch-all handling costs, at stated counts
| Step | Count | Rate | Credits |
|---|---|---|---|
email_verifier |
1,000 addresses | 2 / call, no-verdict calls free | ≤ 2,000 |
find_personal_email, all catch-alls |
280 calls | 5 / call, billed on empty | 1,400 |
find_personal_email, filtered |
60 calls | 5 / call, billed on empty | 300 |
Rates used above: 2 credits per email_verifier call, 5 credits per find_personal_email call.
The gap between those last two rows is the entire argument for filtering before you fall back. Convert at your tier rate on the pricing page — the rate depends on your package, so there is no single number to quote.
Where catch-all handling goes wrong
Branching on valid instead of status. A boolean cannot carry three states. If your code only reads valid, you have already collapsed the catch-all case into whichever answer the boolean happened to take, and you will never know which rows were affected.
Caching the verdict. A domain's mail configuration changes. So does employment. A verdict from eight weeks ago describes an address that may now belong to nobody. Verify close to the send.
Assuming a personal address is a better idea. Sometimes it is a worse one. A cold pitch to somebody's personal inbox reads differently than one to their work address, and in some jurisdictions it is treated differently too. Use branch one when the relationship justifies it, not as a default.
Silent budget drift. Because find_personal_email bills on empty responses, a fallback that runs automatically on every catch-all row will not fail loudly. It will just cost more each month. Put a counter on it.
Plays related to catch-all handling
Waterfall email then verify covers the happy path this pattern branches off. List build and verify puts it in the context of a full list run, and ICP filter with AI enrich is one way to build the score that decides which catch-alls earn a fallback. The endpoint reference is the email verifier API, the email finder API explains the waterfall billing in detail, and the use-case index has the rest of the plays.
Catch-all handling FAQ
Can any tool confirm a mailbox behind a catch-all?
No. The server accepts every local part by design, so there is nothing to observe. Anyone claiming otherwise is inferring from patterns and calling it verification.
Is find_personal_email free when it finds nothing?
No. It bills a flat rate on any 2xx, empty included. Only email_finder, email_verifier and phone_finder return billed: false on a miss.
What proportion of a list comes back catch-all?
It depends entirely on your ICP and we are not going to invent a number. Run a sample of a few hundred rows from your own list and measure it — that figure is worth more than any benchmark.
Should I just delete them all?
Only if your list is large enough that you can afford to. On a tight enterprise list, catch-alls are often where the best accounts live, which is why the isolation track exists.
Can I do this from Claude or Cursor (MCP)?
Yes. email_verifier and find_personal_email are both exposed as tools on the hosted MCP server, which is a decent way to walk a handful of ambiguous rows by hand before you automate the rule.
Do I need a credit card?
No. 100 free credits on signup.
Try catch-all handling: 100 free credits, no card
Verify a dozen addresses from your worst-performing segment and see how many come back catch-all. Get 100 free credits
FAQ