Catch-All Emails: Should You Send to Them?

You verify a B2B list of prospects and a chunk of it comes back neither good nor bad. The addresses are on domains that accept everything, so the verifier could not tell real mailboxes from made-up ones. Delete them and you lose real buyers. Send to all of them and you are betting your sender reputation on addresses nobody has confirmed.

Neither extreme is right. Catch-all addresses differ a lot from each other, and the useful question is which ones to send to, in what order, and when to stop. This post is that playbook: why these domains exist, how detection works, what the catch-all score is built from, and a ramped plan for sending by verdict.

Why catch-all domains exist

A catch-all domain (also called accept-all) answers 250 OK to every recipient during the SMTP conversation, whether or not a mailbox exists. Nobody sets this up to annoy verifiers. The common reasons are mundane.

Shared inbox routing. Some companies want mail for misspelled or departed employees’ addresses to land somewhere rather than bounce. Google Workspace supports this directly: an admin adds a routing rule that sends mail for unrecognized addresses to a chosen catch-all mailbox, as described in Google’s admin help. Mail to nobody-here@ is accepted and delivered to that mailbox.

Microsoft 365 hybrid setups. Exchange Online has two kinds of accepted domain. On an authoritative domain, Microsoft’s documentation says emails for unknown recipients are rejected, using Directory-Based Edge Blocking. On an internal relay domain, mail for recipients Microsoft does not know is relayed on to the company’s own servers. That is common during migrations and in hybrid setups, and it means Microsoft’s edge accepts the address and the decision happens somewhere else, later.

Gateways and filters in front of the mailbox. Security appliances and relays often sit in front of the real mail server without access to the directory. They accept at the edge and let the server behind them sort it out. RFC 5321 acknowledges this directly in section 3.3: “some servers do not perform recipient verification until after the message text is received.”

Resisting address harvesting. A server that rejects unknown users tells anyone who asks which addresses are real. Microsoft’s recipient filtering docs call this “an ideal environment for a directory harvest attack” and add a delay (tarpitting) to make it slower. Accepting everything removes the signal entirely.

Defaults nobody revisited. Some catch-alls are simply a hosting control panel setting someone switched on years ago and nobody has looked at since.

Why a 250 OK means little on a catch-all domain

On a normal domain, 250 2.1.5 in reply to RCPT TO is real evidence: the server checked its directory and said yes. On a catch-all domain, a real address and a random string get the same reply. The 250 describes the server’s configuration, not the person.

What happens after acceptance depends on why the domain is catch-all:

Setup	What happens to mail for a mailbox that does not exist
Catch-all routing to a shared mailbox	Delivered to that mailbox. No bounce, but no real reader either.
Internal relay or gateway in front of the real server	Passed on, then rejected by the server that knows the directory. You get a bounce later.
Discard rule	Silently dropped. No bounce, no reader.
Real mailbox exists	Delivered normally.

The second row is the dangerous one, usually called accept-then-bounce. Section 6.1 of RFC 5321 says that once a server accepts a message, it must send a failure notice back if delivery fails. That notice is a hard bounce in your sending tool, and it counts against you just like a 550 5.1.1 at the door. The 550 5.1.1 page shows what these look like across providers.

How catch-all detection works

The only way to spot a catch-all is to ask about addresses that cannot exist. After the real address is accepted, RocketVerifier stays in the same SMTP session and asks for three random addresses at the same domain. If two of the three are accepted, the domain is treated as catch-all.

Three probes with a two-of-three rule is deliberate. One probe would be fooled by a single flaky accept, or by a real catch-all that happened to rate-limit that one request, as in the transcript above.

Two related outcomes are worth knowing. If the real address is rejected, the catch-all question never comes up: the result is undeliverable/ mailbox_not_found . If the real address is accepted but the probes are blocked or time out, we cannot rule out an accept-all domain, so the result is unknown rather than deliverable. The full pipeline is in how email verification works.

Why B2B lists have so many catch-alls

Consumer mailbox providers generally reject unknown users at RCPT TO, because they run one huge directory and have every reason to bounce mail early. Business domains are where the setups above live: hybrid Exchange, gateways, shared inbox routing, and old hosting defaults. So a list of work addresses will usually contain far more catch-alls than a list of consumer signups.

We are not going to quote an industry-wide percentage. We have not found a public figure with a sound method behind it, and the share swings with the industries and company sizes on your list. The number that matters is the share in your own results, and you will see it the moment a list is verified.

What the catch-all score is built from

On a catch-all domain the result is risky/ catch_all with a catch_all_verdict. The verdict comes from a 0 to 100 score built from three inputs, all judged per address:

• Local-part plausibility. Does it look like a person? jane.doe and jdoe score higher. xk7q2p9z and keyboard mashes score lower.
• The domain’s naming pattern. If the domain’s confirmed mailboxes mostly follow one shape, such as first.last, an address in that shape gains confidence and one in a different shape loses some. Patterns are learned and stored as anonymous counts of address shapes, never as addresses.
• The mail provider. A catch-all domain on an established mailbox provider gets a small lift over an unknown, self-hosted server. Small is the right word: it cannot rescue a random string.

The thresholds are fixed: 65 and above is send_safe, 35 to 64 is send_with_caution, under 35 is avoid.

9

54

88

avoidavoid

cautionsend_with_caution

safesend_safe

03565100

• avoid: 0 to 34
• send_with_caution: 35 to 64
• send_safe: 65 to 100

1. xk7q2p9z@acme-corp.com

   score 9 avoid

   • - Lowers the score: Local part is a random string, not a name
   • - Lowers the score: Does not fit the domain's first.last pattern
   • + Raises the score: Established provider, a small lift that cannot rescue it

2. marco.r@acme-corp.com

   score 54 send_with_caution

   • + Raises the score: Local part looks like a name plus an initial
   • - Lowers the score: Shape is first.initial, the domain uses first.last
   • + Raises the score: Established provider

3. jane.doe@acme-corp.com

   score 88 send_safe

   • + Raises the score: Local part looks like a real name
   • + Raises the score: Matches the domain's first.last pattern
   • + Raises the score: Established provider

The API returns the score and its reasons alongside the verdict, so you can see why an address landed where it did:

{
  "email": "jane.doe@acme-corp.com",
  "status": "risky",
  "sub_status": "catch_all",
  "catch_all_verdict": "send_safe",
  "catch_all": {
    "verdict": "send_safe",
    "score": 88,
    "method": "pattern",
    "reasons": [
      "Local part looks like a real name (e.g. first.last)",
      "Matches this domain's known naming pattern (first.last, seen in 86% of 14 verified mailboxes)",
      "Domain is hosted on a reputable provider (microsoft)"
    ]
  }
}

method tells you how much the score had to go on. pattern means the domain’s naming convention was used. heuristic means no pattern was available, so the score leans on the local part and the provider alone. Expect more send_with_caution results on domains scored by heuristic, and treat their send_safe results with a little less confidence.

How to send to catch-all addresses by verdict

The verdict does the hard work. send_safe addresses go out with your confirmed list, send_with_caution addresses earn their place in small batches, and avoid addresses stay out.

1. 1

   Segment all catch_all results

   Split by catch_all_verdict into three lists, one per verdict.

2. 2

   Send with your deliverables send_safe

   Strong evidence the mailbox is real. Treat these like deliverable addresses in your normal sends.

   pass Suppress any address that bounces, as you would for any send

   stop Bounces clustered on one domain: pull that domain's remaining addresses

3. 3

   Test batch send_with_caution

   Send a small slice, such as 200 addresses, highest scores first, as its own campaign.

   pass Hard bounces under 2% (fewer than 4 of 200): go to step 4

   stop 2% or more: stop, suppress the bounces, review the domains

4. 4

   Expand send_with_caution

   Roughly double the batch each send until the segment is done.

   pass Same check after every batch

   stop One bad batch stops the ramp

avoid

Never sent. Find a confirmed address for the person another way, or drop the contact.

Segment by verdict

Split every catch-all result by catch_all_verdict. If you work from code, it is a few lines over your results:

// results from a bulk job or the API, using RocketVerifier-Version: 2026-11-01
const segments = { main: [], send_with_caution: [], avoid: [], recheck: [] };

for (const r of results) {
  if (r.status === 'deliverable') segments.main.push(r.email);
  else if (r.sub_status === 'catch_all') {
    if (r.catch_all_verdict === 'send_safe') segments.main.push(r.email);
    else segments[r.catch_all_verdict].push(r.email);
  }
  else if (r.status === 'unknown') segments.recheck.push(r.email);
  // undeliverable and other risky results (role_based, possible_trap, ...) stay out
}

In the dashboard, filter by verdict and export each group as its own CSV.

Send send_safe with your deliverable addresses

A send_safe verdict means the score found strong, specific evidence that the mailbox is real: the local part matches the naming convention the domain’s confirmed mailboxes use, it reads like a real person’s address, and the mail provider’s behaviour fits. Treat these addresses like deliverable ones and send to them in your normal campaigns.

As with any send, suppress every hard bounce immediately. If bounces cluster on one domain, that domain is probably accepting and then bouncing; pull its remaining addresses and keep going.

Ramp send_with_caution in its own campaigns

send_with_caution is where the ramp earns its keep. Start with a slice of around 200 addresses, highest scores first, ideally the contacts you know most about (a recent form fill, a reply to a colleague, a meeting). Send it as its own campaign, so its bounce rate is a number you can read rather than noise inside a larger send.

Count hard bounces only. Soft bounces (full mailbox, temporary deferrals) say little about whether the address exists. Accept-then-bounce notices are generated after the receiving system has processed the message, so they do not always arrive with the immediate rejections. We wait about a day before reading the numbers.

The stop line we use is 2%, taken from Amazon SES’s guidance to keep bounce rate below 2%. On a batch of 200, that means 3 hard bounces is a pass and 4 is a stop. If the batch passes, roughly double the next one and check again until the segment is done. One batch over the line stops the ramp.

For cold outreach from domains you cannot afford to burn, keep send_with_caution batches especially small; email verification for cold email covers protecting outbound domains in more detail.

Leave avoid out

avoid addresses are never sent. A random local part on a catch-all domain is exactly what a typo, a fabricated form entry or a scraped guess looks like. If the contact matters, find a confirmed address another way. Keep the record in your CRM if you like, but mark the address as do-not-email.

Real sending is the final test

Verification stops before the DATA command, so no message is ever sent during a check. That is what makes it safe, and it is also why no verifier can see accept-then-bounce: the bounce only exists after a message has been handed over.

So treat your first catch-all sends as part of verification. Each send tells you something the SMTP check could not: which domains bounce after accepting and how a given company’s mail setup behaves. Feed that back. Suppress bounces at once, note domains that bounced after acceptance, and handle those domains more carefully next time. Catch-all handling should also be one step in your regular list cleaning process, not a one-off.

What catch-all results cost

In the dashboard and in the current API version (RocketVerifier-Version: 2026-11-01), catch-all addresses come back as risky / catch_all with a verdict, and they use 1 credit like any other result. Only unknown results and duplicate addresses in a bulk list are free. There is no separate charge for the catch-all scoring.

API keys and integrations still on the older version see catch-all addresses as unknown, the earlier mapping. If your code branches on catch_all_verdict, send the current version header. The details are on the catch-all resolution page and in the API docs.

Catch-alls are also outside the bounce guarantee, which covers addresses marked deliverable. The verdict is what turns those addresses from a gamble into a decision: send the safe ones, ramp the cautious ones, and leave the rest.