Home / Catch-All Email: What It Is, Why It Can't Be Verified, and What to Do

Catch-All Email: What It Is, Why It Can't Be Verified, and What to Do

Published October 24, 2026 · Updated October 24, 2026

Email this to yourself

What is a catch-all email address, and why can't anyone verify it?

A catch-all email setup tells a domain's mail server to accept messages for any address at that domain, even addresses nobody created. Normal servers reject unknown addresses during the SMTP conversation, and that rejection is the signal verifiers rely on. A catch-all server says yes to everything. So nobody outside can tell a real mailbox from a made-up one before sending. The most a verifier can report is "accept-all" or "unknown." You can still remove typos, dead domains and throwaway addresses first.

Key takeaways

• A catch-all (accept-all) domain accepts mail for every address, so SMTP checks cannot separate real mailboxes from fake ones. Any tool that claims to "resolve" one is guessing.
• Verification works by asking the server about a recipient with RCPT TO. A 250 reply means accepted, a 550 means rejected, and a catch-all always says 250.
• Accepted is not the same as delivered. Servers may accept a recipient and bounce later, and some catch-alls discard mail without telling anyone.
• Treat accept-all addresses as their own segment. Send to engaged contacts first, test in small batches, and suppress hard bounces right away.
• ContactLint does not detect catch-all domains. It catches typos, dead domains, disposable and role addresses, which you should remove before you worry about catch-alls.

If you want to see what a DNS-level check returns for your own addresses, get a free API key (100 checks a month, no card), or read how we compare with mailbox verifiers if you need catch-all flags.

What a catch-all email is (and what it is not)

A catch-all is a rule on the receiving side. It says: if mail arrives for an address that does not exist here, deliver it to a chosen mailbox instead of rejecting it. People also call it an accept-all email setup, a catch-all domain, or a wildcard address. They all mean the same server behavior.

Google's admin docs describe it plainly: an administrator can get and save incoming messages sent to non-existent or incorrect addresses in one mailbox. Cloudflare's docs say its catch-all rule forwards every email sent to your domain, including misspelled local parts, to a single destination.

Why do companies set one up? Usually for three reasons:

• To catch typos, like mail for "jhon@" that was meant for "john@".
• To keep getting mail sent to staff who have left.
• To give a small team one inbox without creating many addresses.

What a catch-all is not:

• Not an alias. An alias is one extra address someone created on purpose. A catch-all covers every address nobody created.
• Not a verdict on the person. A catch-all result describes the domain's setup. The address you have for a real prospect may work perfectly.
• Not proof of delivery. The server accepting the message tells you nothing about whether a human reads it.
• Not something a DNS lookup can see. MX records show where mail goes. They do not show what the server does with unknown recipients.

How SMTP verification works, and where a catch-all breaks it

Mailbox verifiers talk to the receiving mail server the same way a sender does, then stop before sending a message. RFC 5321, the SMTP standard, defines three steps in a mail transaction: MAIL (who is sending), one or more RCPT commands (who should receive), then DATA (the message itself).

The useful step is RCPT. Per RFC 5321, if the recipient is accepted the server returns "250 OK," and if the recipient is known not to be deliverable it returns a 550 reply, typically with text like "no such user." A verifier sends RCPT TO for your address, reads the code, and disconnects.

C: MAIL FROM:<probe@sender.example>
S: 250 OK
C: RCPT TO:<jane@normal.example>
S: 250 OK
C: RCPT TO:<x7q2k9zz@normal.example>
S: 550 No such user here

C: RCPT TO:<x7q2k9zz@catchall.example>
S: 250 OK

On a normal domain the fake address gets a 550, so a 250 for Jane means something. On a catch-all domain the fake address also gets a 250. Now Jane's 250 means nothing.

Why not use VRFY instead?

SMTP has a VRFY command meant to confirm a mailbox. But RFC 5321 says sites may disable VRFY and EXPN for security reasons, and a site that does so must answer 252, "Cannot VRFY user, but will accept message and attempt delivery." That reply confirms nothing. So verifiers rely on RCPT instead.

What each reply actually tells you

How to tell if a domain is catch-all, and the limits of that test

The standard test is a probe. Send RCPT TO for an address that almost certainly does not exist, like a long random string. If the server accepts it with 250, the domain is probably catch-all. "Accept-all" flags in verification tools are usually based on this kind of probe.

The test has real limits:

• Accept now, bounce later. RFC 5321 notes that some servers do not verify recipients until after the message text is received, and should then report the failure by mail. It also says that if delivery fails after acceptance, the server must send a failure notice. So a 250 at RCPT can still turn into a bounce.
• RCPT may say nothing. The same RFC warns that where validity checks are deferred until after DATA, RCPT may return no information at all.
• Silent drops. Cloudflare's catch-all supports a Drop action that deletes matching mail, which its docs note can make an address appear valid. RFC 5321 calls dropping mail without notice extremely dangerous, but permitted in practice.
• Probing looks like an attack. RFC 5321 says a server seeing many RCPT commands for invalid addresses may treat it as an attack and close the connection after a number of 550 replies.

Bottom line: catch-all email verification can flag the domain. It cannot tell you which addresses on that domain are real. Be wary of any vendor copy that says otherwise.

How to set up or turn off a catch-all

Each platform does this differently. Here is what each one's own documentation says.

Google Workspace

Google handles catch-alls with a Gmail routing setting. From Google's admin help:

1. Pick the target: an existing user, a new user, or a Google Group (a group lets several people check it).
2. In the Google Admin console, go to Menu, Apps, Google Workspace, Gmail, Routing. You need the Gmail Settings administrator privilege.
3. On the Routing tab, scroll to Routing and click Configure or Add Another Rule. Name the setting and check Inbound messages.
4. Under Action, choose Modify message, check Change envelope recipient, choose Replace recipient, and enter the catch-all address. Then click Show more options.
5. Under the account types section, check All inactive and unrecognized accounts, and make sure Archive accounts with assigned delegate is also checked. Leave Active user account and Group account unchecked.
6. Save. Google says changes can take up to 24 hours but usually happen sooner.

To turn it off: go back to Routing, point at the setting, and click Disable or Delete.

Microsoft 365 and Exchange Online

Exchange Online rejects unknown recipients by default through Directory-Based Edge Blocking (DBEB), which rejects messages for invalid recipients at the service network perimeter. Microsoft says that if all your recipients are in Exchange Online, DBEB is already on. That is why a catch-all takes two pieces:

1. Change the accepted domain to Internal relay. In the Exchange admin center, go to Mail flow, Accepted domains, open the domain, and switch it from Authoritative to Internal relay. Microsoft's accepted domains page ties DBEB to the Authoritative setting, so this switch removes edge blocking for that domain. The same page says not to choose Internal relay if all recipients for the domain are in Microsoft 365, so know that this setup goes against that guidance.
2. Create a mail flow rule. The usual pattern redirects external mail to a shared mailbox, with an exception for recipients in a group that holds your real addresses. Microsoft documents the Redirect the message to action, which sends the message to the recipients you choose instead of the original ones. The rule only catches unknown recipients if the domain is set to Internal relay first, because DBEB would otherwise reject that mail at the edge.

Be clear about the status here. The Microsoft pages linked above document each part, but none of them documents a catch-all from start to finish. The rule is a workaround built from documented parts.

To turn it off: disable the rule and set the domain back to Authoritative. Microsoft recommends Authoritative once all recipients are in Exchange Online, to block messages to addresses that aren't in Exchange Online.

Cloudflare Email Routing

In the Cloudflare dashboard, go to Compute, Email Service, Email Routing, select Routing Rules, and enable the Catch-all rule so it shows as Active. Choose an action (send to an email, send to a Worker, or drop), then select Save. Cloudflare notes catch-all rules are only available for the apex domain. To turn it off, toggle the Catch-all rule off again.

The downside for the domain owner

A catch-all is convenient. It also costs you some things.

• It takes in everything people guess. Spammers try lists of common names. A catch-all accepts every guess, so the target mailbox fills with junk and real typo mail gets buried.
• It answers harvesters. RFC 5321 describes attacks that send many RCPT commands to discover addresses. A catch-all gives every probe the same yes, so you also lose the signal that you are being probed.
• On Exchange Online, you give up edge rejection. Leaving Authoritative for Internal relay removes DBEB, so mail for invalid recipients is no longer rejected at Microsoft's perimeter.
• Your domain becomes unverifiable. Partners and vendors checking your staff's addresses will get "accept-all" for everyone.

Often a few aliases or a group for the addresses you actually expect (sales@, support@, a departed employee's address) do the job without these costs.

Why mailing catch-all addresses is risky for senders

A catch-all email address on your list is not bad by default. It is unknown, and unknowns carry risk:

• Later bounces. An accepted message can still bounce after the fact, as RFC 5321 allows. Those count against you like any other. See hard bounce vs soft bounce for how to handle each kind.
• Unread mail. Mail to a nonexistent person sits in a shared catch-all inbox. No opens, no clicks, no replies.
• Traps you cannot see. M3AAWG's spamtrap guidance describes trap domains whose MX records point directly at the spamtrap server. A trap accepts mail like any server, so acceptance never proves a person. Saying a catch-all "can never be a trap" goes further than anyone can check from outside.
• Reputation. M3AAWG ties careful bounce, complaint and unsubscribe processing to fewer spam trap hits. Sloppy handling of unknown addresses works against that.

Want to put a dollar figure on bad addresses? Try our email bounce cost calculator.

What to do with accept-all or unknown results

Use this table when a verifier hands back mixed results.

The repeated bounce row comes from the M3AAWG Sender Best Common Practices, which call it best practice to remove an address that bounces consecutively at least two times over two weeks or more.

Playbook: signup forms

At signup you have the person right there. That is your best chance to fix an address.

1. Check on submit. Run syntax, MX/A, disposable, role and typo checks. Our guide to validating email on signup covers the setup.
2. Offer typo fixes. If there is a suggestion, show "Did you mean jane@gmail.com?" and let the person pick.
3. Reject dead domains with a plain message, like "That email domain cannot receive mail."
4. Decide on throwaways. Block disposable addresses where abuse matters, like free trials.
5. Send a confirmation email. For a catch-all address, a click on that link is the only real proof the mailbox is read.
6. Hold marketing until confirmed. Unconfirmed accept-all addresses stay off your main list.

Here is the server-side check in Node:

const url = 'https://contactlint.com'
  + '/v1/email/validate';
const r = await fetch(url, {
  method: 'POST',
  headers: {
    Authorization: 'Bearer ' + KEY,
    'content-type':
      'application/json',
  },
  body: JSON.stringify({ email }),
});
const { result } = await r.json();
const v = result.verdict;
const fix = result.did_you_mean;
if (v === 'invalid') reject();
if (fix) suggest(fix);
if (result.disposable) reject();

Playbook: an existing list

1. Remove the obvious failures first. Run the list through syntax, DNS, disposable and typo checks. Our batch endpoint takes up to 50 addresses per request, and our CSV cleaning guide walks through cleaning a list.
2. Add a mailbox check if you need it. Catch-all flags need a tool that connects over SMTP. We don't do that. Our verification tools comparison lists options.
3. Split into segments: accepted on a normal domain, accept-all, and unknown.
4. Send to engaged contacts first. Recent openers, clickers and buyers go out before anything uncertain.
5. Test accept-all in small batches. Check bounces after each batch. If they climb, stop.
6. Suppress hard bounces right away. Do not retry them.
7. Promote or retire. Accept-all contacts who engage move to the main list. The rest go to a sunset flow.

What DNS-level checks like ContactLint can and cannot tell you

We want to be direct about this. ContactLint does not connect to mail servers, so it cannot confirm a mailbox exists and it does not detect catch-all domains. Here is what it does and does not answer about an address that might be on a catch-all domain.

Why do the "yes" rows still matter for catch-alls? A typo domain, a dead domain or a disposable address is a sure loss. Removing those first shrinks the uncertain pile, and any mailbox checking you buy only covers what is left. Our MX record checker and role-based email detection guides explain each result. Each response includes a verdict field (for example invalid, risky or unknown), and checks where our DNS lookup fails are free.

How we put this together

On October 24, 2026, we read and compared the top-ranking Google results for "catch all email" and "what is a catch all email." We noted what each one covered, what it skipped, and where it overclaimed. Then we checked every technical claim against primary sources, which are linked throughout: RFC 5321 for SMTP behavior, Google's and Microsoft's own admin documentation, Cloudflare's Email Routing docs, and M3AAWG's sender and spamtrap best practices. Facts about ContactLint come from our own live product and pricing pages. We did not run deliverability tests for this article, and we have no data of our own on how common catch-all domains are.

Frequently asked questions

How can I tell if a domain is catch-all?

Send RCPT TO for a random address that surely does not exist on the domain. If the server answers 250 instead of a 5xx rejection, it is probably accepting everything. Treat that as a strong hint, not proof, because some servers accept first and bounce later.

What does accept-all mean in a verification result?

It means the mail server accepted a test recipient it should have rejected, so the verifier could not separate real mailboxes from fake ones on that domain. It is a statement about the domain's setup, not about the person. The address might work fine, or it might bounce later.

How should I handle catch-all emails on my list?

Put them in their own segment and send to engaged contacts first. Then mail the catch-all segment in small batches, watch bounces per batch, and suppress any hard bounce right away. Confirmed opt-in clicks are the best proof you will get.

What is the difference between a catch-all and an alias?

An alias is one extra address that someone created on purpose and pointed at a mailbox. A catch-all is a domain-wide rule that accepts every address nobody created, including typos and made-up names. Aliases keep a domain verifiable; a catch-all makes it unverifiable from outside.

How do I turn off a catch-all in Google Workspace?

In the Google Admin console, go to Apps, then Google Workspace, then Gmail, then Routing. Point at the catch-all routing setting and click Disable or Delete. Google notes routing changes can take up to 24 hours.

Does ContactLint detect catch-all domains?

No. ContactLint never opens an SMTP connection, so it cannot detect catch-all domains or confirm that a mailbox exists. It checks syntax, MX and A records, disposable domains, role addresses and common typos, which removes many bad addresses before any catch-all question comes up.

What happens if I send to a nonexistent address on a catch-all domain?

Usually the message lands in the catch-all mailbox, where nobody may read it. If the server accepted it but delivery fails later, RFC 5321 requires the server to send a failure notice, which shows up as a bounce. Some setups, like a Drop action, discard it silently.

Can a catch-all address be a spam trap?

You cannot rule it out from outside. A trap server accepts mail just like a real one, and M3AAWG describes trap domains whose MX records point straight at the trap. Acceptance never proves a person is reading, which is why engagement and bounce handling matter.

Catch the addresses you can catch, for free

No tool can tell you which addresses on a catch-all domain are real. A lot of bad addresses never get that far, though. Typos, dead domains, throwaway inboxes and role addresses can all be caught at the form or in your CSV. ContactLint checks those in one call, and catch-all detection is not included. Get a free API key with 100 checks a month and no card, then see pricing if you need more.

Get a free API key. 100 checks per month, no card required.