Catch-All Domain: Deliverable at the Server, Unconfirmed at the Mailbox

A catch-all domain accepts SMTP mail for every possible address at that domain, whether or not the mailbox exists. Ask its server about sales@ and about a random string of characters, and both get the same 250 OK. The acceptance is real: the mail will be taken. It just says nothing about the mailbox. Deliverable at the server, unconfirmed at the mailbox.

If you are looking at catch_all: true and wondering which verifier let you down, the answer is none of them. Catch-all is not a gap in the probe. It is standards-compliant SMTP behavior that RFC 5321 explicitly permits, and it forecloses the question at the SMTP layer. The same configuration is also called an accept-all domain, and Postfix's manual calls it a wild-card.

What does a catch-all domain do at the SMTP layer?

It answers the only question SMTP lets a verifier ask, and it answers it the same way every time.

RFC 5321 defines the command a probe issues. For RCPT TO:<forward-path>, the spec gives two outcomes: "If accepted, the SMTP server returns a '250 OK' reply and stores the forward-path. If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as 'no such user - ' and the mailbox name." A catch-all server never reaches the second branch, because it never makes the "known not to be a deliverable address" determination during the RCPT exchange. The reply code is identical for the CEO and for a keyboard mash.

That is not the server cutting a corner. RFC 5321 writes deferral into the protocol at the MAIL FROM step in nearly the same words: "the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined." Accept now, work it out later, is sanctioned.

Section 2.1 says why. Once a server issues a success reply, "a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so." A 250 is a promise to deal with the message. It was never designed to be proof the mailbox exists, and Section 4.4 requires that a partial delivery failure still get an OK reply, with the undeliverable notification composed and sent afterward as a separate message.

The failure, if there is one, arrives later and out of band. By design.

How do verifiers detect a catch-all, and why does detection stop there?

Every verifier uses the same trick, and two vendors describe it independently.

Hunter.io documents its own mechanism plainly: "Hunter's Email Verifier connects to the receiving domain and asks if it will accept emails sent to an address that doesn't exist for sure (because it's a random string of characters.) If the receiving server responds positively, it means that it's configured as accept-all." Qualisend calls the same step "a domain-level test," where the verifier "probes a deliberately nonsensical mailbox at the same domain."

Domain-level is the whole limitation in one word. The probe returns a property of the domain, not of the address you asked about. As Qualisend puts it, "a catch-all server says yes to everything, so the answer carries no information." You can check whether a domain is catch-all in a second. That probe cannot then get past the domain to the mailbox, and no variation on it can.

The most useful confirmation comes from a source with every commercial reason to claim otherwise. BounceZero, an email verification vendor, wrote in its own 2026 research: "This class of address cannot be resolved by SMTP probing, by us or by anyone."

RFC 5321 anticipated the situation and handled it more honestly than the market does. For VRFY, a server "MUST NOT return a 250 code ... unless it has actually verified the address," and must instead use reply code 252 when an address "appears to be valid but cannot reasonably be verified in real time." RCPT has no equivalent forced-honesty rule. There is no 252 for a RCPT TO probe, which is why the ambiguity lands in your API response instead of on the wire.

Note what that sentence does and does not close off. SMTP cannot answer the question. It does not follow that nothing can, only that the answer has to come from somewhere other than the mail server. Which makes vendor claims in this area worth reading closely. Enrichley markets a catch-all verifier it says resolves individual addresses on accept-all domains "with 98% accuracy and no test email ever sent to the recipient," on a page that discloses no methodology, sample size, or ground truth. The objection is not the premise. Non-SMTP methods do exist, and the last section of this page comes back to that. The objection is a precise-looking number with nothing published behind it, attached to a claim that covers accept-all domains generally rather than the narrow set where a non-SMTP answer is actually available.

What does it cost to send to a catch-all address?

For the sender, the cost is a bounce you stopped waiting for. SpamCipher describes it: "Because the front door said yes, the eventual non-delivery arrives minutes or hours later as an asynchronous bounce message, after your platform already counted the send as delivered. Those late bounces still hit your reputation ledger; they just do it after you stopped watching." It is a hard bounce that arrives after the books closed.

For the operator, the cost runs the other way. Postfix's virtual(5) manual documents the @domain wildcard and warns about it in the same breath: "This may turn your mail system into a backscatter source: Postfix first accepts mail for non-existent recipients and then tries to return that mail as 'undeliverable' to the often forged sender address." Spam arrives for invented local parts with a forged Return-Path, the catch-all accepts it, the filter rejects it afterward, and the non-delivery report goes to a stranger. At scale that gets the sending IP onto backscatter blocklists. Postfix's own fix is explicit one-to-one mappings or a reject_unverified_recipient restriction.

There is one benefit, and it explains why a competent admin turns catch-all on deliberately. RFC 5321 names the tradeoff in Section 6.2: accepting a message "may trigger additional undesirable traffic by providing verification of the address." Rejecting unknown recipients at RCPT time is itself an oracle. An attacker blasting common prefixes at a domain learns which ones exist from which ones get the 550. A catch-all closes that oracle by refusing to distinguish. Hunter.io says the quiet part out loud: the configuration's "purpose is to prevent email finders from using brute force methods to find valid addresses set up on the domain."

Some catch-all domains are configured specifically to defeat the probe you are running.

How do Microsoft 365, Google Workspace, and Postfix configure it?

Three mechanisms, and one platform that does not want you doing it at all.

Postfix does it in one line. A virtual_alias_maps entry of the form @domain address is a wild-card, and with it "the Postfix SMTP server accepts mail for any recipient in domain, regardless of whether that recipient exists." With explicit per-user mappings instead, Postfix "rejects mail for unknown-user@virtual-alias.domain as undeliverable."

Google Workspace implements it as a routing rule, not a mailbox type. Google's admin documentation describes adding "a catch-all address to your routing settings," applied to "All inactive and unrecognized accounts." A non-recognized address is defined as one belonging to a suspended user, a user with Gmail turned off, or an address in a verified domain "that isn't associated with a user in your Google Workspace account." Google publishes the steps and no warning against them.

Microsoft 365 is the interesting case. No first-party Microsoft support article in Microsoft's own voice was located, but three Microsoft-adjacent sources agree. A community answer hosted on Microsoft Learn states that "Microsoft 365 does not support catch-all addressing." An archived TechNet Wiki article preserved under learn.microsoft.com calls it "Not officially supported by Office365 Support." GoDaddy, a Microsoft 365 reseller, cites spam and phishing exposure while migrating customers off it. Administrators achieve the behavior anyway by setting the accepted domain type to Internal Relay and adding a transport rule.

Is a catch-all domain a fraud signal?

On its own, the evidence is weak. Worth stating plainly rather than dressing up.

No independent, non-vendor study was found tying catch-all configuration to fraud once other signals are controlled for. The closest thing to a pattern comes from a single vendor blog, and that source undercuts the simple version itself: the actionable signal it describes is a catch-all domain combined with forwarding-only MX records and no live web server. Three conditions, not one, and no checkable data behind them. SpamCipher, working the same problem from the deliverability side, keeps catch-all and disposable addresses in separate risk categories, noting of burner addresses that "there is no evidence-based exception like the catch-all has." Catch-all is ambiguous. Disposable is not.

Prevalence numbers deserve the same caution, and one vendor showed why by correcting itself in public. BounceZero first reported that 33.1% of verification attempts hit a catch-all domain. A follow-up study took the number apart: 64.9% of it came from two consumer providers, Yahoo and T-Online, "that don't reveal whether a mailbox exists over SMTP. That isn't accept-all configuration; it's a provider you can't probe." Restricted to mail returning a definite SMTP verdict, the vendor's revised figure for true catch-all was 1.4%. On verifiable Microsoft 365 and Google Workspace business mail, 8.2%.

Those figures are vendor-reported, unaudited, and not comparable to each other, because they count different denominators. A range of 1.4% to 33.1% inside one research program is not an industry rate. It is a reminder to ask what was counted.

The distinction buried in that correction is the one to carry into your own code. A provider that refuses to answer existence queries and a domain configured to accept everything look similar in a result set and are not the same condition.

How Trueguard handles a catch-all address

Trueguard's email validation API returns isCatchall on the deliverability object. By default, a catch-all domain downgrades what would otherwise be a safe verdict to risky. Not invalid, because the mail will very probably be accepted. Not safe, because the mailbox behind it was never confirmed.

That default is not where the check ends. Not every catch-all address is a dead end. Some of them resolve to a definite verdict on signals that do not depend on the SMTP conversation, so nothing above about RCPT TO stops being true. The outcome in those cases is either a definite safe, with isDeliverable true, or a definite invalid, with isDeliverable false. isCatchall stays true either way. The domain is still catch-all. The verdict is what changed.

The limits deserve the same plain statement as the capability. This does not cover every catch-all domain. Where no such signal is available, the verdict stays risky. Where one is available, it can still come back without a clear answer, and the verdict stays risky then too. There is no published accuracy figure attached to this and none should be inferred. The claim is the narrow one: some catch-all addresses resolve to a definite verdict, the rest keep the verdict they always had.

That fallback is risky, not unknown. The two stay distinct. unknown covers a different cause: the destination server gave no clear answer at all, for example because it refuses verification probes. A catch-all answered clearly. It just answered the same way for everyone.