Catch-all emails: how to detect them and whether to send
A catch-all domain accepts mail for any address, so a yes proves nothing. How EmailPal detects them with one RCPT TO probe per domain cached for a day, and whether to send.
The short answer
A catch-all domain accepts mail for every address, real or invented, so its server saying yes to your contact proves nothing. EmailPal detects one by asking the server about a mailbox that cannot exist (no-such-mailbox- plus random characters) before asking about your address. If the server accepts it, every address at that domain comes back catch_all and is not probed individually. One probe per domain is cached for 24 hours, and no email is ever delivered.
Detection is one RCPT TO against an invented mailbox, per domain, cached a day. A 2xx means catch-all, a 5xx rejection means the domain checks its mailboxes, and anything else is inconclusive and not cached. Catch-all addresses cannot be confirmed without sending, so treat them as unverified: send a small, separate segment, watch its bounce rate on its own, and keep it off new or still-warming domains.
01
What catch-all means
Normally a mail server answers RCPT TO for a mailbox that does not exist with a 5xx rejection, and a verifier uses that rejection as its signal. A catch-all domain is configured to accept every local part. It returns a 250 to the invented name and to the real one alike, so a 250 carries no information about whether your contact exists.
The mailbox may exist, may be forwarded to someone else, may sit in a shared inbox, or may not exist at all. The server often decides later, after the connection is closed, and a mail that nobody can deliver bounces asynchronously or is dropped silently. From outside, nothing at SMTP time distinguishes those cases, which is why a catch-all verdict is a statement about the domain rather than about the address.
02
How EmailPal detects a catch-all domain
The check follows the order in which the worker runs it. First a free classifier settles what needs no connection: malformed addresses (invalid), disposable domains and role accounts such as info@ and sales@. Those are answered before any catch-all probe, so info@ at a catch-all domain comes back role_account and not catch_all.
For everything else the worker looks up the domain’s MX, using the lowest-preference host first. It then checks a cache of earlier answers for that domain. On a miss, it connects through the verification IP pool, says EHLO, MAIL FROM and RCPT TO with an invented address of the form no-such-mailbox- followed by random characters at that domain, then QUITs. It never sends DATA, so no message is created.
The reply decides the domain. A 2xx means the domain accepts anything: it is catch-all. A 5xx rejection that does not say mailbox full or disabled means the domain rejects strangers: it is not catch-all, so a yes to your real address is meaningful. A 4xx deferral, timeout, connection failure or a rejection phrased as full or disabled is inconclusive.
A conclusive answer is stored with the domain, the MX host and a timestamp, and reused for 24 hours so that every other address at that domain does not pay for it again. An inconclusive answer is not stored. When the domain is not catch-all (or the probe was inconclusive), the worker then runs RCPT TO for your actual address and maps the reply to a status. When the domain is catch-all, it stops there and does not ask about your address, because the answer would not mean anything.
Probe 1 (once per domain per 24 hours, reused for every address at the domain):
RCPT TO:<no-such-mailbox-8f3ka20b9x@acme.example>
250 -> domain is catch-all -> every address there returns catch_all
550 -> domain checks mailboxes -> go to probe 2
4xx / timeout -> inconclusive, not cached -> go to probe 2
Probe 2 (your address, only if the domain is not known to be catch-all):
RCPT TO:<priya@acme.example>
2xx -> safe
5xx "mailbox full" / "over quota" -> inbox_full
5xx "disabled" / "suspended" -> disabled
other 5xx -> invalid
450 / 451 / 452 / 421, timeout -> unknown
No DATA command is ever sent. The connection ends with QUIT.03
catch_all is not the same as unknown or safe
safe means the domain proved it rejects strangers and then accepted your address, so the yes means something. unknown means the server gave no definitive answer, usually because of greylisting or a timeout. It is a finding about our attempt, not about the address, and it is never rounded up to safe. catch_all is the one case where the answer is definitive and still cannot help: the domain will accept anything, so the mailbox is unconfirmable.
In the API response a catch-all result looks like this. status is catch_all and sub_status is null. The call still costs one credit, because credits are taken per address before the probe, even though no second probe is needed for your address.
{
"email": "priya@northbay-partners.example",
"status": "catch_all",
"sub_status": null,
"domain": "northbay-partners.example",
"mx_host": "mail.northbay-partners.example",
"checked_at": "2026-10-06T14:03:21.000Z",
"credits": { "used": 12, "limit": 500 }
}04
Should you send to catch-all addresses?
Sometimes, but not as part of your main send. The risk is not that the address is bad. It is that you cannot tell, and a wrong guess shows up as a bounce you pay for on your sending reputation. A list built by guessing first.last at company domains produces exactly this: many addresses at domains that accept everything, with no way to separate the real ones.
Our recommendation is to treat catch-alls as a separate, small segment. Send them after your safe addresses, from mailboxes with a clean record, and not from a new or still-warming domain. Watch that segment’s bounce rate on its own rather than blended into the campaign. EmailPal’s sequencer pauses a campaign when its bounce rate passes your threshold, which is 5% by default, so a large catch-all segment can pause the campaign you were protecting.
If the contact is a named person you had a reason to email, and the domain is one you care about, sending is reasonable. If the address was generated from a pattern, or the list is mostly catch-alls, do not send. EmailPal’s own list gate reflects the same reasoning: catch-all, role and disposable addresses count as risky, and a list is blocked when about 40% of it is risky or the estimated bounce rate reaches 8%.
05
How lists treat catch-alls
On a list, the catch-all probe happens once per domain and the answer applies to every address there. A domain with a thousand addresses and a catch-all server costs one probe, and the thousand come back catch_all without a per-address probe. You are still charged one credit per address, taken in full when the list is accepted.
For the list verdict, catch-all addresses are counted in a risky bucket together with role accounts and disposable addresses. The estimated bounce rate counts invalid, disabled and inbox_full addresses in full and the risky bucket at 0.15 each. That weight is an internal planning figure used to decide whether to flag or block a list, not a measured bounce rate for catch-alls. A list is flagged at an estimated 3% bounce rate or when 20% of it is risky, and blocked at 8% estimated bounce or when 40% is risky.
06
Where detection stops
Some large providers accept every RCPT at SMTP time and decide later. EmailPal found this for Yahoo and later for AOL, which runs on the same mail infrastructure, and the worker special-cases yahoo.com, ymail.com, rocketmail.com and aol.com. They are not labelled catch_all, because that would mislabel every address there. Their addresses are probed individually, and since those servers accept everything at RCPT TO, a safe result at those four domains means the accept happened, not that the mailbox was confirmed.
A catch-all result also depends on the server behaving consistently. Greylisting, rate limits and tarpits make the invented-mailbox probe inconclusive, and in that case EmailPal does not record a verdict for the domain. The cache is also keyed to the MX host, so a changed MX host triggers a fresh probe. We do not publish a catch-all prevalence rate or an accuracy percentage on this page, because we have not published one we can stand behind.
Limits, prices and names, in one table
The figures this page relies on, so you do not have to hunt for them.
| Detection method | RCPT TO an invented mailboxno-such-mailbox- plus random characters at the domain. Nothing is delivered. |
| Probes per domain | 1 per 24 hoursConclusive answers are cached by domain and MX host. Inconclusive ones are not. |
| Status returned | catch_allsub_status is null. |
| Order of checks | invalid, disposable, role, catch-all, addressinfo@ at a catch-all domain returns role_account. |
| Credits per address | 1Charged for catch_all results too, on single checks and on lists. |
| Weight in list bounce estimate | 0.15 per catch-allAn internal planning weight, not a measured bounce rate. |
| List flagged at | 3% estimated bounce or 20% risky |
| List blocked at | 8% estimated bounce or 40% risky |
| Domains handled separately | yahoo.com, ymail.com, rocketmail.com, aol.comThey accept every RCPT, so they are never labelled catch_all. |
| Campaign auto-pause | 5% bounce rate by defaultThe threshold is yours to change. |
Checked against the product and the API on . Plans and limits change, so confirm in the docs before you build on them.
This is not for you if
- You need every catch-all address confirmed. Nobody can confirm those mailboxes without sending, and no verifier that does not send can change that.
- You want a percentage of catch-all addresses that bounce. We do not publish one, and it varies by domain and by how the list was built.
- You need Yahoo or AOL mailboxes individually confirmed. Those servers accept everything at RCPT TO, so a safe there means the accept happened.
- Your list is mostly catch-all addresses at pattern-guessed domains. That is a list problem, and sending to it will cost reputation whatever the verifier says.
Common questions
What is a catch-all email?
A catch-all email address belongs to a domain whose mail server accepts messages for any address at that domain, including ones that do not exist. A verifier that asks the server about your contact gets a yes whether or not the mailbox is real, so the yes proves nothing.
How does EmailPal detect a catch-all domain?
It sends RCPT TO for an invented mailbox, no-such-mailbox- followed by random characters, and closes the connection without sending any message. If the server answers 2xx, the domain is catch-all. If it rejects with 5xx, the domain checks mailboxes. The answer is cached for 24 hours per domain.
Should I send cold email to catch-all addresses?
Not as part of your main send. Their deliverability cannot be confirmed, so treat them as a separate segment, send after your safe addresses from clean mailboxes, and watch that segment’s bounce rate separately. Do not send to them from a new or warming domain, or when the list was generated rather than collected.
Does a catch_all result mean the address is bad?
No. It means the domain accepts everything, so the address cannot be confirmed either way. Many real people sit at catch-all domains. The risk is a bounce you cannot predict, which is why the verdict is separate from invalid.
What is the difference between catch_all and unknown?
catch_all is a definitive answer about the domain: it accepts every address. unknown means the server gave no definitive answer, usually because of greylisting or a timeout. Unknown is about our attempt and can be retried later. Catch-all will not change when you retry.
Does verifying a catch-all domain send an email to anyone?
No. The probe issues RCPT TO and QUIT. It never issues DATA, so no message is created or delivered, at the invented address or at yours. The probe leaves from EmailPal’s own pool of verification IPs, not from your sending mailboxes.
Build it on infrastructure that holds up
Domains, mailboxes, warming and verification over one REST API and MCP server, with the sequencer, Unibox and CRM on every plan.
No card to start — cancel any time.