How to check if an email domain is catch-all

To check if an email domain is catch-all, ask its mail server whether it would accept mail for an address that can't possibly exist, such as a long random string at the same domain. If the server says yes to that address too, it accepts everything, and the domain is catch-all.

You can run that test by hand over SMTP, but in practice it's better to let an email verifier do it, because the test only gives honest answers when it runs from a mail-friendly server with a clean reputation.

How does the catch-all test work?#

The test compares two answers from the same mail server. A checker opens an SMTP conversation, the same one a real delivery uses, and names two recipients in turn with the RCPT TO command: the address you care about, then a made-up one.

The checker hangs up before the DATA step, so no message is sent. The full step-by-step pipeline, with reply codes, is in how email verification works.

How do I check for catch-all manually?#

Conceptually, a manual check is five steps:

1. Look up the domain's MX records to find its mail server. Our free email domain checker shows them.
2. Connect to that server on port 25 and introduce yourself (EHLO).
3. Name a sender with MAIL FROM.
4. Name a made-up recipient with RCPT TO, something like a 20-character random string at the domain.
5. Read the reply. A 250 means the server accepts unknown addresses: catch-all. A 550-type reply means it rejects them, so its answer for a real address means something.

Note that the email domain checker covers step 1 only. It reads DNS (MX, SPF and DMARC records) and never talks to the mail server, so it can't tell you whether a domain is catch-all.

Why shouldn't I run SMTP checks from my own computer?#

Because where the check comes from changes the answer, and can harm your network's reputation.

• Port 25 is often blocked. Many internet providers block outbound port 25 from home connections. Cloud platforms do too: Amazon EC2 blocks port 25 to public addresses by default, and Google Compute Engine blocks connections to destination port 25 outside your network.
• Home IPs are on blocklists. Spamhaus's Policy Blocklist lists end-user IP ranges "from which email should never be sent directly to the final destination." Many mail servers refuse or distrust connections from those ranges, so you get errors, not answers.
• Probing looks like harvesting. Checking many addresses at one domain from one IP looks like someone mining the domain for valid mailboxes. Microsoft's Outlook.com sender policy names "namespace mining" as a prohibited practice. Servers that notice may block the IP, and the block can hit your real email if it shares that IP.
• Greylisting gives false negatives. Some servers answer unknown senders with a temporary 4xx code on purpose. A one-off manual check reads that as a failure.

A one-off check of a single domain is unlikely to cause trouble. Running it over a list is what a verifier is for.

Which tools check whether an email is catch-all?#

Most dedicated email verifiers run the catch-all test as part of every check and label the result. The label differs by tool: "catch-all", "accept-all", "accept all" or "risky". Examples include ZeroBounce, NeverBounce, MillionVerifier, Bouncer and Hunter's email verifier. Most offer a small number of free checks; see each vendor's pricing page for current limits.

The last row matters. Some tools that call their check "verification" only look up the domain. We explain the difference in domain check vs mailbox check. A quick test: if a tool never returns a catch-all result, it probably isn't asking the mail server.

What should I do with catch-all addresses?#

Treat them as unconfirmed and send them separately. Hunter tested this: in its sample, 38% of email domains were accept-all, and a test send to 100 accept-all addresses bounced 27% of the time, against 1% for 100 verified addresses. Send verified addresses first, send catch-alls later in small batches, and prefer addresses the business published on its own site over guessed ones. Our guide to catch-all emails has the full decision rules.

FAQ#

How do I know if an email domain is catch-all?#

Ask the domain's mail server, during an SMTP conversation, whether it would accept mail for a random address that can't exist. If it accepts that address too, the domain is catch-all. Email verifiers run this test for you and report the result as catch-all, accept-all or risky.

Can I check for catch-all without sending an email?#

Yes. The test stops before any message is sent: the checker names the recipient with RCPT TO, reads the server's reply, and disconnects. No email is delivered to anyone.

Does an MX lookup or domain checker show if a domain is catch-all?#

No. DNS records such as MX, SPF and DMARC show whether a domain can receive mail and how it's configured, but whether the server accepts every address is only visible by asking the server itself over SMTP.

Should I run catch-all checks from my own computer?#

Usually not. Many home and office internet connections block outbound port 25, home IP ranges are often listed on blocklists such as Spamhaus's Policy Blocklist, and repeated probes from one IP can look like address harvesting. Use a verifier that runs the checks from servers set up for it.

Is a catch-all email address invalid?#

No. It means the check couldn't tell. The mailbox might exist and be read every day, or mail might go to an unread inbox or bounce later. Treat it as unconfirmed: a maybe, never a yes.

Sources#

1. IETF, RFC 5321: Simple Mail Transfer Protocol (RCPT TO, reply codes).
2. IETF, RFC 6647: Email Greylisting.
3. Spamhaus, Policy Blocklist (PBL).
4. Amazon Web Services, Amazon EC2 service quotas (port 25 restricted by default).
5. Google Cloud, Sending email from an instance (destination port 25 blocked outside the VPC network).
6. Microsoft, Outlook.com Postmaster: Policies, Practices, and Guidelines (namespace mining).
7. Hunter, Accept-all (catch-all) emails (November 4, 2025).