How to Verify Catch-All Emails Without Bouncing Your List

Short answer: you cannot verify a catch-all address by guessing at it or by sending it a test message. Guessing produces plausible addresses, and plausible is exactly what bounces. Test-sending runs your experiment in public, in front of the mailbox providers who decide where your mail lands. The only approach that gives you an answer without a cost is resolution that happens without sending anything.

This guide covers all three approaches honestly — including where guessing and testing have limited legitimate use — and then gives you a workflow you can put into production this week.

Why the normal method stops working

A quick recap. Standard verification depends on the receiving server refusing recipients it does not recognise. On a catch-all domain, the server accepts everything, so acceptance tells you nothing. Every address at that domain looks equally real.

That is why your verifier returns "catch-all", "accept-all" or "risky" and stops. It is not being lazy — it is being honest about running out of signal.

Approach 1: pattern guessing

The most common workaround. You know the company domain and the person's name, so you generate the likely permutations:

• `jane.doe@company.com`
• `jdoe@company.com`
• `jane@company.com`
• `j.doe@company.com`
• `doe.jane@company.com`

Then you either pick the most common convention or send to several and hope.

Why it fails more than people think

• Conventions are not universal. Firms use different formats by department, by era of hire, or by whichever system was in place when the person joined.
• Mergers break everything. Acquired staff frequently keep legacy formats or run dual addresses for years.
• Duplicates force exceptions. The second Jane Doe gets `jane.doe2@` or `jdoe.marketing@` and no pattern predicts which.
• Contractors and executives are special-cased. Both groups routinely sit outside the standard format.
• On a catch-all domain, every guess is "accepted". This is the trap. Guessing feels validated because nothing bounces at the gateway — until the campaign report shows a fraction of the opens you expected.

Where guessing is still reasonable

As a *candidate generator*, not as an answer. Generate the permutations, then resolve them properly. That is a legitimate workflow. What is not legitimate is treating an accepted guess as a verified address.

The multi-send variant is actively harmful

Sending to five permutations of one person's address is a well-known spam pattern. Filtering systems recognise it. You are also, in the best case, delivering five copies to one real human, which is an excellent way to be reported.

Approach 2: sending a test email

The intuitive approach: send a short message and see what happens.

It fails on catch-all domains for a structural reason. The domain accepts your test whether or not the mailbox exists — that is the definition of catch-all. So the test produces no information, while costing you everything a real send costs.

The four things that can happen to a test

• Delivered and read by a human. The outcome you wanted. You cannot distinguish it from the next three without a reply.
• Delivered to a shared catch-all mailbox nobody monitors. Recorded as delivered. Reaches nobody.
• Silently discarded. The server accepted it, then dropped it. Recorded as delivered. Reaches nobody. This is the most dangerous case, because your metrics say success.
• Bounced later. The server accepted it, then generated an asynchronous bounce after the fact. Your bounce rate absorbs it.

Three of four outcomes give you either no information or damage. That is not a test — it is a coin flip with a fee.

The reputation math

Mailbox providers score sending domains partly on how well the sender knows their own list. Bounces, spam-folder placement and complaints all feed that score, and the score is slow to build and fast to lose. Running exploratory sends against unresolved addresses is the single most reliable way to spend reputation on nothing. The concrete thresholds are in Are Catch-All Emails Safe to Send?.

If your method for finding out whether an address is real is "send to it and watch the bounce report", you are not verifying — you are paying a mailbox provider to grade your guesswork.

Where a test send is still reasonable

For a single high-value contact you already have a relationship with, a genuine one-to-one message is fine. That is correspondence, not verification, and it does not scale to a list.

Approach 3: resolution without sending

The third option is a service that resolves the individual mailbox on a catch-all domain and returns a definitive verdict, without delivering anything to the recipient.

This is what VeriMailX does. In practical terms:

• You get valid or invalid, not "accept-all", on the addresses other tools give up on.
• Nothing is sent to the recipient. No test message, no notification, no trace in their inbox.
• The check is live, reflecting the mailbox's current state at the moment you ask.
• It works across Microsoft 365, Google Workspace and self-hosted mail. Why those two providers are the hardest case is covered in Microsoft 365 and Google Workspace Catch-Alls.
• Genuinely ambiguous cases come back as "risky", never as a fabricated "invalid".

The method is proprietary multi-signal resolution and we do not publish it. What we do publish is the standard we hold it to: we never claim 100% accuracy, and we would rather return an honest "risky" than suppress a real person with a wrong "invalid".

A production workflow

Here is the sequence that works, in order.

Step 1: verify at the point of capture

Cheapest possible moment. A bad address caught at the signup form never enters your database, never gets synced to three other systems, and never needs cleaning later. Real-time verification at capture removes most of the problem before it starts.

Step 2: resolve before you build the segment

Not after. Run resolution as a pre-send step, so the segment you hand to your ESP is already decided. If you resolve after building the segment, someone will send the unresolved version by accident. Someone always does.

Step 3: split the outcomes deliberately

• Valid — into the send.
• Invalid — permanent suppression, never retried.
• Risky (post-resolution) — held out of large sends; suitable for one-to-one follow-up by a human if the contact is valuable.
• Role-based — allowed for support and transactional flows, excluded from cold outreach.

Step 4: warm gradually if the list is old

If a segment has not been mailed in six months, do not resume at full volume even after resolution. Ramp over several sends and watch engagement. Verification fixes the list; it does not reset a cold sending history.

Step 5: re-verify on a schedule

B2B contact data decays continuously. Anything older than about three months should be re-resolved before a major campaign. Catch-all domains actively hide this decay by accepting mail for people who left two years ago.

Step 6: keep the record

Store the verdict and its timestamp on the contact. When a deliverability question comes up six months from now, the difference between "we verified everything" and being able to show exactly what was known and when is the difference between a conversation and an argument.

What to expect from the numbers

Two honest expectations before you start.

Your list will get smaller. Resolution converts a comfortable "risky" pile into a definite invalid pile, and seeing real numbers deleted is uncomfortable. Those contacts were never reachable; you were just not being told.

Your engagement rates will look better immediately, because the denominator finally reflects reality. This is a measurement artefact, not a performance gain — but the deliverability improvement underneath it is real, and it compounds.

Start with one address

Take a contact your current tool has been calling "risky" and run it through the free email checker. Single checks need no signup. If it resolves, the rest of your risky segment probably will too — pricing starts with free credits on signup and pay-as-you-go credit packs that never expire.