Catch-all Domain: What It Looks Like in a Live Campaign

Catch-all Domain: What It Looks Like in a Live Campaign

A catch-all domain is a domain configured to accept mail addressed to any mailbox at that domain, including mailboxes that do not exist. Mail to a real employee and mail to a name nobody has ever used are both accepted at the door. The arrangement is also called accept-all, and the two names describe the same configuration.

Nothing about that is a fault. It is a deliberate setting on the receiving side, chosen for reasons that have nothing to do with you, and it happens to remove the one thing an email verification service relies on.

How a verifier normally answers, and why it cannot here

Verification of a business address is done by conversation rather than by lookup. The verifier resolves the domain's MX records, opens an SMTP connection to the mail server those records name, and begins the delivery handshake: it greets the server, names a sender, and then issues a RCPT TO command carrying the address it wants to check. It stops there. No message body is ever sent.

The answer is in the server's reply code. A server that knows its own mailboxes will accept the recipient with a 250 when the mailbox exists and refuse it, usually with a 550, when it does not. That refusal is the verifier's evidence, and it is what a verdict of "invalid" is built from.

A catch-all domain answers 250 to everything. The wildcard routing behind it says that any local part at this domain is deliverable, so sarah.chen@ and notarealperson@ produce identical replies. The probe still completes, the server still answers, and the answer carries no information about whether the mailbox exists.

1. Step 1Resolve the MX records

   Find the servers that accept mail for the domain. This works the same either way.

2. Step 2Open the SMTP conversation

   Greet the server and name a sender. Still no message is being sent.

3. Step 3Issue RCPT TO for the address

   Ask the server whether it will accept mail for this specific mailbox.

4. Step 4Read the reply code

   A refusal here proves the mailbox does not exist. That refusal is what an invalid verdict is made of.

5. Step 5Catch-all: acceptance for everything

   A wildcard-routed domain accepts every local part, so the reply is identical for a real mailbox and an invented one.

That is the whole mechanism. A verifier returning "catch-all" or "accept-all" has completed its work successfully and is reporting that the technique it uses cannot produce an answer at this domain.

How a verifier decides a domain is wildcard-routed is worth knowing, because it explains the one verdict people trust least. The service probes a local part it invented, something no human would own, and watches what the server does. Acceptance of an address that cannot exist is the proof, and it is proof about the domain rather than about your row. This is also why re-running the same address later almost never changes anything: the configuration is a setting on the receiving side, and nothing your side does affects it.

"Catch-all" is a distinct verdict from "unknown", and pipelines that merge the two lose information. An unknown verdict means the probe itself did not complete: the server refused the connection, throttled it, deferred it, or answered in a way the verifier could not classify. That is a transient state, and re-checking it later often resolves. A catch-all verdict means the probe completed perfectly and the answer was uninformative, which no amount of re-checking will fix.

Why domains are set up this way

Catch-all configurations are not rare and they are not careless. Several ordinary reasons produce them.

Small organisations often route everything to one inbox because there is one person reading mail, and setting up individual mailboxes for addresses nobody uses is work with no benefit. Companies that have absorbed other companies keep old domains alive with a wildcard so that mail to former addresses keeps arriving somewhere. Businesses with heavy inbound traffic use it as typo insurance, so that a customer who mistypes an address still gets through. And a large share of business domains sit behind a hosted security gateway whose MX records answer first: those gateways commonly accept everything at the boundary and make the real recipient decision later, at the point where they hand the message to the mailbox behind them.

That last one is worth holding onto, because it means the catch-all label is often describing an appliance rather than a mail server, and it is disproportionately common on exactly the mid-market and enterprise domains a B2B list is full of. The domain looks permissive at the door and is not permissive at all further in.

Where the definition breaks

Here is the confusion that costs real prospects. "Catch-all" is read as a verdict about an address when it is a configuration fact about a domain.

The address may be entirely real, checked every morning by the person you want to reach, and sitting on a domain whose administrator turned on wildcard routing years ago. Nothing about the verdict speaks to that. What the verdict reports is that the question is unanswerable by this method, which is a statement about knowability rather than about validity. Two rows carrying the same verdict can be a perfectly good address and a guess somebody's enrichment tool invented, and the verdict looks identical because it was never about the address in the first place.

Validthe server accepted this mailbox and refuses others

• A claim about the address
• The server distinguishes its own mailboxes
• Evidence that this local part exists
• Safe to send to on the deliverability question

Invalidthe server refused this mailbox

• A claim about the address
• A refusal the server chose to give
• Evidence that this local part does not exist
• Remove it: sending produces a permanent failure

Catch-allthe server accepts every mailbox

• A claim about the domain's configuration
• The server declines to distinguish anything
• No evidence either way about this local part
• The address may be real, and the method has run out of road

Both of the obvious responses to that are wrong in different directions.

Treating every catch-all row as a bad address throws away real prospects, and it does so with a bias, because the domains most likely to be wildcard-routed include the enterprises and the gateway-protected mid-market companies that a good B2B list is built around. A rule that deletes them is a rule that quietly shrinks your addressable market in the direction of your best-fit accounts.

Treating them as good addresses is worse, and it is worse in a way that compounds. You are sending into a set whose failure rate is unknown and materially higher than a verified set, because it contains every guessed pattern and every departed employee that a verifier would ordinarily have caught. Permanent failures at scale are read by receiving providers as a statement about your list hygiene, and that reading attaches to the sending domain rather than to the batch. So the cost of being wrong is not confined to the wasted messages. It lands on everything else that domain sends, which is the argument for keeping the two sets apart in the first place. What a clean list should actually be producing is set out in cold email bounce rate benchmarks.

What to do with them

RevenueFlow holds catch-all addresses out of sends rather than gambling on them, and preserves them rather than deleting them. Both halves of that matter. The hold protects the sending domains, because an unknown failure rate mixed into a verified batch makes the whole batch unreadable and puts the reputation of the domain behind it. The preservation reflects what the verdict actually said: the address may be genuinely valid and only the verification method failed, so deleting the row destroys work that may be perfectly good and will have to be paid for again if the same person is ever sourced afterwards.

Kept rows also keep their options. A catch-all address that later turns up through a different route, confirmed by a source that does not depend on an SMTP probe, moves out of the held set on evidence. A domain that changes its configuration becomes answerable. Neither of those is available for a row you deleted.

The tooling side of this belongs elsewhere. How verification services differ in the verdicts they return, what they charge, and specifically how each one handles catch-all domains is compared in email verification tools, which is the piece to read on picking one. This entry is about what the verdict means once you have it.

Two related terms sit close by and are worth keeping distinct in prose. A soft bounce is a temporary refusal of a message that was actually sent. A hard bounce is a permanent one. A catch-all verdict is neither, because no message was sent: it is the outcome of a probe made before any campaign exists. The reason people conflate them is that catch-all rows sent without care are a common source of hard bounces later, which is a claim about what happens next rather than about the verdict itself.

How it shows up in a live campaign

The first place you meet it is a batch that shrinks more than expected. A list that looked healthy comes back from verification with a large held set, and the temptation is to read that as a sourcing failure. Usually it is a property of the segment: an ICP full of large enterprises or of industries that standardise on hosted security gateways will produce more catch-all verdicts than one full of small owner-operated businesses, on identical sourcing quality.

The second is a build where every row has been resolved with a guessed pattern. Guessing an address is cheap and a wildcard-routed domain will never contradict the guess, so a pipeline that patterns addresses and accepts catch-all verdicts as passes can manufacture an entire clean-looking list out of nothing. That combination is the one worth having a rule against. Address-finding that produces evidence, such as the ordered provider approach described in waterfall enrichment and the sourcing side covered in email finder tools, gives a catch-all row something other than a pattern behind it.

The third is the one that hurts, and it arrives late. Held catch-all rows quietly become the largest untouched part of a mature list, and at some point somebody proposes sending to them because the sourced pool is thin. That is a decision to make on the sending domains you are willing to put at risk, deliberately and in isolation from the verified programme, never as a top-up folded into a healthy campaign. The broader question of what your sending infrastructure can absorb is the subject of the cold email deliverability guide.

Underneath all of it is the same volume discipline that governs everything else here. One message per campaign, sent once on one premise, keeps the amount of unverified mail any receiving provider sees from a domain as small as it can be, and a later approach to the same person is a separate campaign built on a different premise and its own list.

Judging these rows one pool at a time is continuous work, and our pay-per-qualified-meeting outbound is where we do it rather than hand it over.