Catch-all emails: what they are and how to handle them

A catch-all domain says yes to every address, which makes it hard to know whether a particular person is really there. This guide explains what that means for your list and what to do about it.

CheckMX guide · Published October 27, 2026

What a catch-all domain is

Most mail servers decide per recipient whether to accept a message. If you send to nobody@example.com and no such mailbox exists, the server usually refuses the recipient. A catch-all (sometimes called accept-all) domain is configured differently. It accepts mail for any name before the @, whether or not a matching mailbox exists. Messages for unknown names might land in one shared mailbox, be sorted later, or be dropped quietly.

Companies set this up for ordinary reasons. A small business may not want to miss a message sent to a mistyped or newly created alias. An administrator may prefer to filter mail after receiving it rather than reject it at the door. Some security gateways accept first and decide later, so a catch-all result can come from the gateway rather than from the company’s own mail system. None of this means the domain is suspicious. It means the server’s answer carries less information.

Why a verifier cannot confirm a single inbox there

Email verification relies on a conversation with the receiving mail server. At the recipient step of that conversation, called SMTP RCPT TO, the verifier asks whether the server would accept the address, then ends the session without sending a message. On a normal domain, an accepted address is a good sign and a rejected one is a clear no.

On a catch-all domain the same question gets the same answer for everyone, so acceptance says little about one person. To detect this, a verifier tests a random address that cannot plausibly exist. If the server accepts that too, the domain behaves as a catch-all. CheckMX then labels the result risky rather than deliverable. Risky means the result is uncertain. It does not say the address is bad, and it does not say it is fine.

You can inspect the domain side yourself. The MX lookup shows which servers receive mail, but DNS records cannot reveal catch-all behavior. Detecting it takes a recipient check, which the free email verifier and the catch-all checker page explain and demonstrate.

SMTP acceptance is not a delivery guarantee

It is worth repeating because it applies beyond catch-all domains. A server can accept a recipient during a check and still bounce, filter or discard the real message later. Content, sender reputation and authentication all affect what happens next. A verification result is a signal about an address, and delivery and inbox placement are separate questions. The guide on bounce rate and spam rate limits explains why that distinction matters for your sender reputation.

How to spot catch-all behavior in practice

• Every address on the domain returns the same verdict. If you verify several made-up names and all of them look fine, the domain is probably accepting everything.
• Bounces arrive later than usual. If a send to a catch-all domain bounces, the rejection may come well after the first accepted handshake.
• The first send gets no reply from anyone on that domain. That is not proof, but it is a reason to look closer.

A safe way to handle catch-all addresses

You have three practical choices, and the right one depends on how much a bounce costs you.

1. Keep them in a separate segment. Do not mix risky addresses with confirmed ones. A separate list lets you apply different rules, such as a smaller send or a manual review.
2. Improve the evidence before you send. Check the spelling and where the address came from. An address a person typed into your own form, or one that appeared in a recent reply, is more trustworthy than one guessed from a pattern such as first.last@. If you can, ask the contact to confirm through an existing channel.
3. Send with caution and watch the results. If you do include risky addresses, send a small batch first, watch for bounces and complaints, and stop if the numbers worsen. Avoid adding them in bulk to a campaign that matters to your sender reputation.

Whatever you choose, only contact people where you have a valid basis to do so. A verification result tells you about an address. It does not give you permission to email the person, and it does not satisfy any legal requirement about consent or opt-outs.

What not to do

• Do not treat risky as invalid and delete everything. You may discard good contacts, especially at small companies that use catch-all by default.
• Do not treat risky as safe. That is how lists with a hidden bounce problem are built.
• Do not guess addresses from name patterns on a catch-all domain. Every guess looks valid, so the verifier cannot warn you when you are wrong.
• Do not pay for certainty that nobody can sell. A service that claims to confirm every catch-all inbox is describing something the protocol does not allow. Be cautious of such claims, including from us. CheckMX reports the uncertainty instead.

How CheckMX treats catch-all results

CheckMX labels a catch-all domain risky and gives a reason with the verdict, so you can sort a list into confirmed, risky, invalid and unknown results. Unknown results are where the server times out, defers or blocks the connection. You can check one address, upload a CSV of up to 10,000 unique addresses, or call verification from the API, the CLI or an assistant through MCP. Every plan, including the free Sandbox, comes with email checks.

If you are comparing services, see how CheckMX stacks up in CheckMX vs ZeroBounce and CheckMX vs NeverBounce. If you are preparing to send, continue with the cold email domain setup checklist.

Frequently asked questions