Catch-all emails and deliverability (why they're risky)

A catch-all domain answers 250 OK to every recipient you name, whether that mailbox exists or not. That single configuration choice destroys the one signal address verification depends on, which is why a verifier can only ever return "risky" or "accept-all" for these addresses and never "valid". The risk is not that catch-alls bounce more. It is that you cannot know in advance which ones will, so a batch of them turns your bounce rate into a coin toss you find out about days later.

What a catch-all is, at the level of the SMTP conversation

Every address check that is not a guess happens inside one exchange. Your sending server opens a connection, issues MAIL FROM, then RCPT TO:, and waits. A domain that knows its own users answers 250 2.1.5 OK for a real recipient and 550 for one it has never heard of. Those two answers are the entire mechanism.

A catch-all domain removes the second answer. Every RCPT TO gets 250, so the reply carries no information about the address you asked about — only about the policy the administrator configured. The message is then delivered somewhere: an administrative mailbox, a group, a rule that files it, or a queue that quietly drops it.

This matters because acceptance and delivery are two different events separated in time. A catch-all edge accepts at the perimeter and decides later. If the later decision is "there is nowhere to put this", the failure arrives as an asynchronous delivery status notification hours afterwards, addressed to your envelope sender, long after your dashboard has counted the send as delivered.

The two configurations that produce a catch-all, named exactly

Catch-all is not a property of a domain. It is a setting, and on the two platforms most of your B2B prospects use it has a specific name you can point at.

Microsoft 365 and Exchange Online. An accepted domain is either Authoritative or Internal relay. Authoritative turns on Directory-Based Edge Blocking, which Microsoft documents as rejecting "messages for invalid recipients at the service network perimeter". Microsoft publishes the exact bounce it returns: 550 5.4.1 Recipient address rejected: Access denied. Switch the same domain to Internal relay and that rejection stops — the service accepts the address and relays it onward, which is the behaviour every verifier reads as catch-all. Microsoft's own guidance is that a migrating tenant should sit on Internal relay until every valid recipient has been added, then switch to Authoritative. A great many tenants complete the migration and never switch back.

Google Workspace. The equivalent is a Default routing rule with a catch-all recipient, which Google documents as the supported way to "get misaddressed email in a catch-all mailbox". Google states an administrator may create up to 1,000 default routing settings and that they carry lower priority than other Gmail routing settings.

The practical consequence: whether an address on a corporate domain is verifiable at all is decided by an administrator you have never met, for reasons that have nothing to do with you. That is worth internalising before you treat "accept-all" as a quality judgement about a prospect.

Why no verifier can confirm a catch-all address by SMTP

This limit is in the protocol, not in the tooling. RFC 5321 section 3.5.3 covers the case directly, for the VRFY command: when a server can neither confirm nor deny an address, "reply code 252 SHOULD be returned", and the specification notes that these cases "parallel the discussion of RCPT verification in Section 2.1". A 252 means the server will accept the message and attempt delivery without claiming the address is valid. That is precisely the honest answer a catch-all domain owes you, and it is the answer a well-behaved verifier passes through as "unconfirmable".

Two further pressures have closed the gap from the other side. Section 7.3 of the same RFC tells implementers they may provide "a way to disable either or both of these commands", and most have — VRFY is off almost everywhere. And the major receivers now decline recipient enumeration outright: Google Workspace answers 250 to every RCPT TO, and Microsoft 365 and Proofpoint refuse to discriminate. So the SMTP probe fails on the largest providers whether or not the domain is catch-all.

The honest position is unpopular but correct. On a catch-all domain, a verifier that reports "valid" has decided to report the domain's acceptance policy as if it were a fact about the mailbox. The free email address checker reports the same address as unconfirmable, which is less satisfying and more true.

The one exception: Microsoft's identity endpoint

There is exactly one common case where a catch-all domain can still be resolved, and it exists because mailbox existence leaks through a channel that is not SMTP.

Microsoft's unauthenticated sign-in endpoint, login.microsoftonline.com/common/GetCredentialType, returns an IfExistsResult field for a username: whether an account with that address exists in the tenant's directory. For a Microsoft-hosted domain running Internal relay, SMTP says 250 to everything and the directory still knows the truth. Autocloz uses this as a separate oracle, and it is worth reading the failure modes because they are the reason it cannot simply be trusted:

• Federated tenants using ADFS or a third-party identity provider return a federation redirect instead of a usable answer. The oracle returns indeterminate.
• Tenants with enumeration protection answer "exists" for every address. Autocloz detects that with a differential control probe — a randomly generated address that certainly does not exist — and discards the tenant's answers when the control also reads "exists".
• The deny-shaped version of the same protection answers "does not exist" for every address, including real ones. A control probe cannot see this, because a deny-everything tenant answers the control correctly. So a negative is only trusted from a tenant that has already been observed saying "exists" for some address in the same domain.
• Rate limiting. Microsoft throttles by source IP; the correct response is to back off and return indeterminate rather than keep asking.

Every one of those returns "we do not know" rather than a guess. That is the whole design: a verdict you cannot falsify is worth less than an admission.

Autocloz's free plan covers 5 users and 10 mailboxes, with verification, warmup and SPF, DKIM and DMARC monitoring included — start free and look at what your own list actually resolves to before you buy a verification credit.

What a catch-all segment costs, in arithmetic

Take a list of 5,000 corporate addresses where 1,200 sit on catch-all domains, and assume for the sake of the worked example that 8% of those catch-all addresses turn out to have no mailbox behind them. That 8% is an illustration, not a measurement — the real figure is a property of your list and nobody's published benchmark can tell you what it is.

Mailed as one batch, 96 hard bounces land inside 5,000 sends: 1.9%. Mailed as two segments, the 3,800 verified addresses produce whatever their own low rate is, and the 1,200 catch-alls produce 96 bounces inside 1,200 sends: 8.0%. The total number of bounces is identical. What changes is that in the second arrangement you can see the number, attribute it, and stop.

That visibility is the entire argument for segmentation, and it compounds with the timing problem. A bounce rate is a lagging measurement — today's figure describes outcomes that arrived today, not sends that happened today — so a threshold-based auto-pause reacts to a batch that finished sending hours ago. The controls that actually move a bounce rate all depend on knowing which segment produced the failures, which mixing destroys.

Catch-all domains, spam traps and the trap type that matters

The link people draw between catch-alls and spam traps is real but usually stated too broadly. Spamhaus describes three categories: recycled, pristine and typo. Recycled traps are "email addresses that were once valid but are now no longer used", and Spamhaus says they make up the majority. Pristine traps "are designed to catch specific abuse" and were never valid addresses. Typo traps sit at misspellings of mailbox-provider domains — Spamhaus's own examples include yaaho.com and homail.com.

Only one of those has a strong structural relationship with catch-all configuration. A recycled trap is an address that existed, stopped existing, and now accepts mail again; a catch-all domain is a domain where every dead address still accepts mail. That is the same condition described twice. Pristine traps live on domains the trap operator controls, and typo traps live on lookalike domains — neither is something you can infer from a domain being accept-all.

The useful conclusion is narrower than the folklore. A catch-all domain does not signal a trap. A catch-all domain does signal that departed employees' addresses on it will keep accepting your mail indefinitely, which is exactly the population recycled traps are drawn from. Old list data plus catch-all domains is the combination that carries the risk, and what a spam trap is and how lists acquire them covers the acquisition paths.

How to actually run a catch-all segment

The decision is not "send or delete". It is which risk appetite you apply, and every serious sender should be able to say which one they are on.

1. Separate the segment before the first send, on the verification detail rather than on the verdict. A catch-all address and an unconfirmable one are both reported risky, and they are different populations.
2. Choose the sending policy deliberately. Autocloz exposes three. Off sends everything. Balanced, the practical default, sends every risky bucket and holds only genuinely unknown addresses — timeouts, blocked MX records, verification errors. Strict additionally holds catch-all and role addresses, stamping the enrolment with verify_held_catch_all or verify_held_role so the operator can read why a lead never went out.
3. Pick the mailbox you are willing to spend. Catch-all volume belongs on a mailbox whose reputation you can afford to damage, not on the one carrying your warmest sequence. Autocloz lets a campaign declare its own sender selection, and email sending honours that selection absolutely rather than falling back to whatever mailbox is healthiest.
4. Cap the batch at a size where the bounce rate is a signal rather than noise. Three bounces out of twelve is 25% and means nothing; three out of three hundred is 1% and means something.
5. Prune on outcomes, not on the verdict. An address that hard-bounced is finished. An address that was accepted and never replied is unproven, and the difference between a soft and a hard bounce decides which of those you are looking at.

If a large share of your list is catch-all, the leverage is upstream. Sourcing addresses that come with an engagement signal beats verifying addresses that come with none, and the stages of list cleaning in the order they have to run put verification last for that reason.

What a catch-all check cannot tell you, and what Autocloz does not do

A catch-all verdict describes a receiving server's configuration. It says nothing about whether the person exists, whether they still work there, whether they will read the message, or whether the domain is one you should be mailing at all.

It is also not stable. A tenant that switches its accepted domain from Internal relay to Authoritative stops being catch-all that day, and every address you filed as "risky" last quarter is now decidable. Cached verification verdicts go stale in both directions.

And Autocloz specifically. The in-house verifier does not detect catch-all at all. The SMTP RCPT probe and the catch-all probe were both removed on 31 July 2026 — they required outbound port 25, which is blocked by default on AWS, Google Cloud, Azure and most container platforms; recipient enumeration got the source address rate-limited and then blocklisted; and against Google Workspace, Microsoft 365 and Proofpoint the probe already returned nothing usable. What remains is syntax, a typo guard, a disposable-domain list, role-address detection and one cached MX lookup per domain, so an address that clears every layer is reported as risky and unconfirmable. The catch_all tag still exists in the verdict vocabulary and in the send policy, and on the free verifier it is unreachable code. Catch-all detection reaches Autocloz only through a configured third-party verifier — the Hunter, ZeroBounce and NeverBounce adapters each map their provider's catch-all verdict onto risky — which is a real reason some teams keep a paid credit balance alongside a free tool, and one of the honest differences on the Hunter alternatives comparison.

Nor can the free verifier ever return "deliverable" on its own. It has no mechanism to prove a specific mailbox exists, so that verdict is written only by evidence that cannot be fabricated: a real delivery that was accepted, or the Microsoft directory oracle described above. A tool that stamps a corporate address "deliverable" without one of those has inferred it, and email verification as a category promises more than the protocol allows.