Catch-All Email Address: How to Detect It and What to Do

CaptainVerify verified more than 126 million email addresses in 2025. About 2.5% of that volume sits on a catch-all domain. Restricted to addresses hosted on a company domain, outside the consumer mailboxes that account for close to 75% of everything verified, the share climbs to nearly 11%, or close to 1 business address in 9. This measurement counts addresses. The much higher rates quoted elsewhere count domains, which is a different unit: a single catch-all domain may carry a handful of addresses in your database or several hundred. On a B2B file of 50,000 contacts, that works out to roughly 5,500 rows whose validity stays undecidable before you send.

The domain hosting those addresses can be spotted in seconds with a single SMTP command. The 2 levels are handled separately: detecting the domain is a reproducible technical test, deciding whether to send depends on your bounce thresholds.

What is a catch-all email address?

A catch-all is a routing rule set at domain level: the receiving server accepts messages addressed to any mailbox on the domain, declared or not.

The rule lives in the configuration of the receiving domain, behind its MX record. No individual mailbox carries the label. The phrase “catch-all address” circulates as shorthand and covers any address whose domain applies this fallback mode.

An example makes the mechanics obvious. The domain example.com declares david@example.com and turns on a catch-all. A correspondent types daivd@example.com, with 2 letters swapped. On a standard domain, the server refuses that address at RCPT TO and returns a permanent error to the sender, one of the SMTP reply codes you need to know how to read. On example.com, the message goes through and lands in the fallback mailbox. The typo goes unnoticed.

Catch-all, alias, forwarding and subaddressing: what sets them apart

An alias declares an extra address that points to an existing mailbox. Forwarding takes a declared address and sends its mail on to another destination. Subaddressing adds a suffix after a plus sign, as in david+press@example.com, which the server maps back to the base mailbox. These 3 mechanisms work on addresses the server already knows, and it rejects anything outside its list. A catch-all acts after that list, on the local parts no rule declares.

What is a catch-all address for?

A catch-all recovers mail sent to a misspelled address and denies an attacker the answer that would reveal which addresses exist on the domain.

The first use is trivial. Typos pile up on compound names. The mailboxes of people who left keep receiving mail for months, and the catch-all picks that mail up.

The second use is defensive. A server that answers 550 on unknown addresses hands out a free oracle: the attacker submits a list of first names and keeps the ones the server accepts. A catch-all domain answers 250 to everyone and sorts nothing on the attacker’s behalf.

The downside arrives in the fallback mailbox. A domain that accepts everything attracts dictionary campaigns, those bulk sends that try contact@, admin@, support@, hr@ and a few hundred first names until something sticks. Sorting then falls to whoever empties that mailbox, with all the mailing list cleaning work it implies on the sender side.

How to detect a catch-all domain

A catch-all domain shows itself when you submit a randomly generated address to the server: if it accepts an improbable address, it accepts everything else.

The SMTP test step by step: MX, EHLO, MAIL FROM, RCPT TO

1. Resolve the MX records of the domain and keep the one with the lowest preference value, the primary MX. With no MX at all, mail falls back to the A record of the domain.
2. Open a connection on port 25 to that server and greet it with EHLO followed by a hostname that resolves in DNS.
3. Announce MAIL FROM with an empty envelope or a test address that is genuinely reachable.
4. Send RCPT TO for the address you want to check, then note the return code and the text that comes with it.
5. Send RCPT TO for a random address on the same domain, something like k7v29xq4m@example.com.
6. Close the session with QUIT, without ever moving on to the DATA command.

The signal is in the random address, the first acceptance only confirming that the session behaves normally. Plan an RSET between the 2 RCPT TO commands, since a server often drops the session after a bad recipient. Stopping before DATA avoids delivering a message and leaves nothing in the remote logs beyond the trace of an opened session. The probing IP needs a valid PTR record, otherwise a policy refusal reads as an invalid address.

250 OK versus 550: reading the server response

RFC 5321, published in October 2008, sets the rule in section 3.3: the server answers 550 to RCPT TO when the recipient is undeliverable, with a message along the lines of “no such user”. RFC 3463, from January 2003, defines the matching enhanced code in section 3.2: 5.1.1 signals an invalid destination address and a permanent failure. A 250 returned on the random address establishes that the domain accepts everything at RCPT TO. The caveat matters: some antispam gateways placed at the edge also accept any recipient at this stage without applying a catch-all. The deferred rejection described below produces the same answer. These codes apply to the envelope, and they say nothing about whether the address itself is well formed.

What skews the test: shared MX, greylisting, tarpitting and deferred rejection

Shared MX tops the list of false signals. Hundreds of thousands of domains point to the same mail servers at the large hosting providers. Recipient policy is set domain by domain behind that common MX, so the name of the server tells you nothing about the fallback mode.

Greylisting produces another kind of noise. The server returns a temporary 4xx error on first contact and waits for a retry before committing. CaptainVerify waits up to 30 minutes and runs the verification again before concluding. Addresses that stay silent after that retry are marked unknown and credited back. Tarpitting belongs to the same family: the server deliberately slows its answers to discourage probes.

Deferred rejection makes the reading harder still. The server accepts the recipient at RCPT TO, then generates a bounce once the message has been swallowed. The test sees a clean 250 while the real send will produce a permanent error a few minutes later.

What the accept_all status means in a verification report

The accept_all status, named ok4all in CaptainVerify reports, means the domain accepts every address and that verification therefore stops at domain level.

The CaptainVerify documentation files ok4all under risky addresses and states the effect plainly: the bounce rate goes up and the open rate goes down. So the report says 2 things in one line. The domain is qualified, the person behind the address still has to be confirmed by sending.

Can you verify an address on a catch-all domain?

The protocol gives no answer, since the server returns the same response for every address on the domain. What stays possible is estimating a probability and sorting the segment accordingly.

Start by looking at what sits behind the MX record of the domain. When it points to a security gateway, Proofpoint, Mimecast, Barracuda or Microsoft Defender for Office 365 for instance, the gateway answers on behalf of the domain before the real mailbox is ever queried. The accept_all status then reflects a filtering architecture rather than a fallback rule the company chose. The case is common on large accounts.

Next comes the shape of the address. On a domain whose mailboxes follow a visible convention, first.last for example, an address that respects that convention carries a much higher probability of validity than an arbitrary string. Compare your rows against each other: the ones that break the mold go into a test segment, the others get priority.

A verifier adds its own signals on top: the age of the domain, the reputation of the mailbox provider, the size of the organization and the history observed on previous sends. The result is a confidence score you can use to order a segment before sending.

Creating or disabling a catch-all, host by host

The switch is set in the admin console of the domain: accepted domain mode under Microsoft 365, a routing rule under Google Workspace, the default address under cPanel.

Google Workspace

Google Workspace offers no native catch-all function. Google does publish a help page dedicated to the collection mailbox and names the account type it targets Unrecognized or Catch-all. Configuration goes through a routing rule, under Apps then Gmail then Routing, with the Change envelope recipient action applied to unrecognized and inactive accounts. Mail addressed to an unknown mailbox then goes to a designated collection address. To undo it, delete that routing rule: the domain goes straight back to refusing the recipients it does not know.

Microsoft 365

Behavior depends on the accepted domain mode, under Mail flow then Accepted domains. In Authoritative mode, the domain rejects unknown recipients and turns on Directory-Based Edge Blocking, which cuts the message off at the edge of the service. Internal relay mode forwards mail for unknown recipients to another server and produces fallback behavior in practice.

cPanel

The feature is called Default Address, and it offers 3 choices. The default one returns an error to the sender during the SMTP session, the exact opposite of a catch-all. The other 2 route mail for unknown addresses to an existing mailbox or discard it silently. The cPanel documentation labels that discard option Not Recommended itself, for a fundamental reason: the sender never learns that the message vanished.

What to replace a catch-all with

The way out runs through declared addresses rather than a fallback rule. Create aliases for the most frequent typos on your domain names and keep a generic contact mailbox that someone actually reads. Subaddressing takes over for tracking your forms without multiplying mailboxes. The domain gets a clean recipient list back. Your correspondents get an immediate error when they make a mistake.

Catch-all with or without a bounce

2 distinct configurations hide behind that question. A catch-all accepts the unknown recipient at RCPT TO and delivers the message to a fallback mailbox, with no bounce of any kind. Deferred rejection also accepts at RCPT TO, then produces a non-delivery report after swallowing the message.

That second mode costs everybody something. When the original envelope is forged, which is the norm in spam, the non-delivery report goes to an innocent third party whose address served as a decoy. The phenomenon has a name, backscatter. It feeds the blocklists. Understanding it also helps you sort your own returns, between hard bounce and soft bounce.

Should you include catch-all addresses in your campaigns?

Sending to catch-all addresses pushes the bounce rate up and the open rate down, 2 curves that mailbox providers watch to decide what comes next. That is how sender reputation degrades, message after message.

The real risk: bounce thresholds, complaint rates, sender reputation and spam traps

Bounce thresholds come from the sending platforms. Amazon SES puts your account under review above 5% bounce and can suspend sending at 10%. The Microsoft documentation for Dynamics 365 Customer Insights, updated in August 2026, draws 2 levels: an acceptable bounce rate stays under 2% in most cases. The product itself tolerates up to 8% before reacting. So the 2% figure is best practice, the 8% is the threshold actually enforced. Take the file of 50,000 contacts again and its 5,500 or so catch-all rows. If half of them bounce, the counter passes 5% before the rest of the database has even been counted, above the bar that triggers an account review. Thresholds then vary from one sending platform to the next, and yours is worth reading before a large send.

Complaint thresholds come from the mailbox providers and are counted separately. The Google guidelines for senders, in force since 1 February 2024, ask for a complaint rate under 0.10% and set a limit never to reach at 0.30%, for any sender of more than 5,000 messages a day to Gmail. The Yahoo Sender Hub asks you to stay under 0.3%. These 2 players publish complaint thresholds, no bounce threshold.

That leaves spam traps. Spamhaus documented the cycle in February 2022: an abandoned address bounces with a permanent error for often 12 months or more, then the domain switches it back on as a trap. A database left uncleaned for 2 years therefore holds, statistically, addresses that changed nature in the meantime.

Reducing uncertainty before you send

Verifying the list beforehand does the first pass. It pulls out the invalid addresses and isolates the ok4all rows in their own segment. What is left is a database where the bounce rate becomes predictable again. Then look at where the collection came from: a list built on single opt-in or double opt-in produces far fewer bounces than a purchased file. Look at age last, since the cycle Spamhaus describes runs on every dormant address. This overview of email verification tools covers the approaches available.

Validating through engagement after the first send

Treat the ok4all segment as a test. Send to 5 to 10% of the segment first. Measure the bounce rate and the open rate, then compare those 2 values with the rest of the campaign. A small gap lets you raise the percentage on the next send. A clear gap points to a segment to set aside or rework.

After 2 sends with no open and no click, a catch-all address has proved its own uselessness and leaves the list. Before your next campaign, isolate the ok4all rows from a sample of your database and compare their bounce rate with the rest: the verdict lands within the hour and it beats any estimate.

Frequently asked questions

Can a catch-all domain be detected?

Yes, in a few seconds. A single RCPT TO on a random address of the domain is enough: a 250 answer on an improbable address reveals the fallback mode. The validity of each individual address stays undecidable through that test.

What share of a B2B database is affected?

Out of more than 126 million addresses verified by CaptainVerify in 2025, about 2.5% came back as catch-all. Narrowed to company domains alone, that share rises to nearly 11%. A B2B database of 100,000 contacts therefore holds roughly 11,000 rows of this kind, to be isolated before sending.

Does a catch-all protect against spam?

It increases the spam you receive, since any invented address on the domain finds a mailbox. Its benefit lies elsewhere: the server no longer answers 550 on unknown addresses and denies the attacker the oracle that would let them enumerate valid addresses.

Should you delete catch-all addresses from your list?

Outright deletion makes sense when your sending platform applies a low bounce threshold, like the 5% that triggers an account review at Amazon SES. On a dedicated IP you control yourself, a separate segment and batched sending stay a reasonable option.

What should you do with an unknown status in a report?

It signals a server that stayed silent despite the automatic retry run within 30 minutes. CaptainVerify credits those verifications back. A fresh pass later settles the question in the vast majority of cases.