What is a catch-all email address?
A catch-all domain accepts mail addressed to every possible mailbox, including ones that do not exist. Verification works by asking a server whether an address is deliverable, so on a catch-all every answer is yes — which means no verifier can tell a real mailbox from a typo. That is why you get "unknown".
Written by the SieveGuard team from the checks our own free tools run. Last reviewed .
Why verification returns unknown
Mailbox verification is an SMTP conversation held up to the point of asking. The verifier connects, names a sender, names the recipient, and reads the answer to RCPT TO:
normal domain RCPT TO:<real.person@company.com> 250 2.1.5 Ok → deliverable RCPT TO:<nobody-xyz-9f2@company.com> 550 5.1.1 User unknown → not deliverable catch-all domain RCPT TO:<real.person@company.com> 250 2.1.5 Ok → ? RCPT TO:<nobody-xyz-9f2@company.com> 250 2.1.5 Ok → ?
On the second domain both answers are identical, so the test carries no information. The honest report is unknown — and a verifier that returns "valid" here is not detecting anything, it is relabelling a 250 it cannot interpret.
The random-address probe in that example is how the condition is detected at all: ask for a mailbox that certainly does not exist, and if the server accepts it, everything it accepts is meaningless.
Why domains are configured this way
Almost never to frustrate verification. Four ordinary reasons, and knowing which one applies changes how you treat the address:
| Reason | Typical of | Are the addresses real? |
|---|---|---|
| Not losing mail to typos | Small businesses, professional services | Mostly yes |
| Default on the hosting plan | cPanel and similar shared hosting | Mixed — nobody chose this |
| Deliberate address-per-vendor use | Technical users, privacy-conscious teams | Yes, and each one is single-purpose |
| Anti-enumeration posture | Larger organisations and security-conscious hosts | Unknowable by design |
The last row matters more than it used to. Answering 550 for non-existent mailboxes tells an attacker exactly which addresses are real, which is a directory harvesting gift. A number of large hosts now accept everything at SMTP time and reject later precisely to close that, so "catch-all" is increasingly a security default rather than a configuration choice.
Deciding what to do with them
Deleting every unknown throws away real customers; sending to all of them risks the bounces. The workable answer is to treat them as a separate segment and let other signals decide.
| Signal on the address | Read it as | Action |
|---|---|---|
| They signed up themselves and confirmed | Almost certainly real | Send normally |
| They have opened or clicked before | Real — engagement is proof | Send normally |
| A named local part (firstname.lastname) | Probably real | Send, watch bounces |
| A role address (info@, sales@) | Real, but a shared mailbox | Send with care — higher complaint risk |
| Imported from a list you bought | Unknowable, and the least of your problems | Do not send |
| No engagement in 12 months | Dead or uninterested | Suppress |
The pattern underneath: engagement history beats verification. A prior open is direct evidence a human received the message, which is a stronger proof than any SMTP probe. Verification only matters where you have no history.
The effect on your numbers
Bounce rate understates the problem
A catch-all accepts at SMTP time, so a dead address there does not produce an immediate hard bounce. It either bounces hours later — often not attributed back to the send — or is silently discarded. Your bounce rate looks healthy while a chunk of the mail reaches nobody.
Engagement rate is the better instrument
A segment of catch-all addresses that never opens anything is telling you what the bounce rate cannot. If open rate on that segment is near zero while the rest of your list is normal, the addresses are not being read — suppress on that evidence rather than waiting for bounces that will never arrive.
A high catch-all share is itself a signal
Twenty percent unknowns on a list built from your own signups is unremarkable. Eighty percent means the list came from somewhere else — scraped, purchased, or generated by pattern-guessing against company domains, which produces catch-all hits by design.
What nobody can do
- Prove a mailbox exists on a catch-all domain. The server will not distinguish, and there is no other authority to ask. Any vendor claiming otherwise is either reporting engagement data they hold from elsewhere, or guessing.
- Reliably use the "deep" SMTP tricks. Some verifiers probe further into the conversation looking for behavioural differences. It works occasionally, breaks often, and looks like directory harvesting to the receiving server — which is a good way to get the probing IP blocked.
If you want to see the conversation yourself rather than take this on trust, our SMTP tool runs it live and shows the full transcript, including the RCPT TO response that decides the whole question.
Sources
FAQ
What does "catch-all" mean in email verification?+
It means the receiving server accepts mail for every address at that domain, whether or not the mailbox exists. Verification asks the server whether an address is deliverable, so on a catch-all every answer is yes and the test tells you nothing.
Why does my verifier return "unknown" instead of valid or invalid?+
Because unknown is the accurate answer. The server accepted a deliberately random address as readily as the real one, so there is no basis to call it either. A verifier reporting "valid" there is relabelling a response it cannot interpret.
Should I send to catch-all addresses?+
It depends entirely on where the address came from. Someone who signed up themselves, or has opened your mail before, is almost certainly real — send. An address from a purchased list is unknowable and should not be sent to, though that is true regardless of catch-all status.
How is a catch-all domain detected?+
By asking for a mailbox that certainly does not exist — a long random local part. If the server accepts that, it accepts everything, so every other answer from that domain is uninformative. That single probe is the whole detection method.
Do catch-all addresses hurt my bounce rate?+
Less than they should, which is the trap. They accept at SMTP time, so a dead address there bounces late or is silently discarded rather than producing a clean hard bounce. Watch engagement on that segment instead — near-zero opens tell you what bounces will not.
Can any tool prove a catch-all address is real?+
No. The receiving server will not distinguish, and there is no other authority to consult. The only genuine evidence is engagement — a prior open or reply proves a human received it, which is stronger than any SMTP probe could ever be.
Check it on a real domain
Free, no signup, DNS-only. Nothing you type leaves the lookup.