The Catch-All Address Standard: Send, Corroborate, or Reroute

When a verifier returns catch-all, accept-all, or unknown for part of a prospect or candidate list, someone has to decide, address by address, what goes into the sequence. This standard is for the recruiting ops and RevOps people who make that call and may have to explain it later. It gives you five evidence dimensions you can check without buying anything, a scoring rule that returns Send, Corroborate, or Reroute, and the arithmetic for a per-mailbox cap that keeps the rolling 7-day hard-bounce rate under 2%.

What do catch-all and unknown verification results mean?

A catch-all result means the domain's mail server accepted mail for an address that should not exist, so the verifier cannot tell whether this particular mailbox is real. An unknown result means the verifier got no conclusive answer at all. Neither result says the address is bad. Both mean the verifier ran out of evidence, and the rest of the decision is yours.

Four terms used throughout:

• Catch-all (or accept-all) domain: a domain whose mail server accepts mail for any address at that domain, real or invented, at the moment of delivery.
• Unknown: the verifier's check timed out, was refused, or returned something the verifier could not classify.
• Hard bounce: a permanent delivery failure. It can arrive at send time or days later.
• Rolling 7-day bounce rate: hard bounces divided by sends over the trailing seven days, measured for each sending mailbox rather than each campaign.

How common are catch-all domains?

Published estimates run from under 8% to over 60%, and most of the spread comes from what each source counts. Some count addresses and most count domains. Every sample is drawn from the lists that a verification vendor's own users chose to check.

The highest estimate is about five times the lowest, and the lowest is the only one that counts addresses. The 1.6M-domain survey warns that its sample skews toward B2B prospecting lists. The address-level study put another 23.61% of records in unknown, about three times its catch-all share. A policy that covers only catch-alls therefore misses the bigger bucket. This standard scores both the same way.

The sources even disagree on which way company size pushes the rate. One says enterprise domains run lower, at 8-10%. Another reports 9-12% for companies under 50 staff and higher rates for enterprise. Don't use company size as a proxy. Read the domain's mail setup instead, which is dimension one below.

What does sending to a catch-all address risk?

Published post-send data puts catch-all bounce rates between roughly 8% and 27%, against about 1-2% for verified addresses. No mailbox provider publishes a bounce limit, so the 2% ceiling you hold yourself to is a policy you set and have to own.

Look at the whole spread, not one number. The 27% comes from a single 100-address test. The 8-15% is pooled data with no per-test sample stated. The 14.7% is five bounces among 34 leads in a forum post. Treat all of these as starting estimates that your own measured rates will replace. The method is in the last section.

What do mailbox providers actually publish?

Providers publish limits on complaints and rules on authentication. None of them publishes a bounce limit.

• Google: keep the spam rate reported in Postmaster Tools below 0.10%, and never reach 0.30% or higher. Google calculates the rate daily. Secondary sources report that a sender above 0.3% loses Gmail mitigation until the rate stays below 0.3% for seven consecutive days.
• Yahoo: keep the spam rate below 0.3%. Yahoo publishes no numeric bulk threshold, and it requires unsubscribes to be honoured within 2 days.
• Microsoft: rejects mail with 550 5.7.515 Access denied when the sending domain does not meet the required authentication level. The rule applies to senders of 5,000 or more messages to its consumer services from one From domain.

The 2% bounce line is industry convention. Hold to it anyway, as written policy. A bounce cap is the one lever you control before problems show up in the complaint and authentication numbers that providers do enforce.

The five evidence dimensions and how to score them

Score each flagged address 0, 1, or 2 on five dimensions: domain mail setup, pattern confirmation, current-employment proof, provenance, and sending fragility. You can check each one from public sources or your own sending data. Each one can also mislead you in a known way, and that is listed with it.

These point bands are my starting policy, not a published standard. Nobody has publicly validated weights for this problem. Calibrate them against your own bounce data for each verdict band, as described in the last section.

Dimension 1: domain mail setup

This dimension shows who answers mail for the domain, and whether the catch-all flag describes the mailbox or a gateway standing in front of it. A secure email gateway is a filtering service that sits in front of the company's mailbox platform. It usually shows up in the MX record, the DNS entry that names the servers that accept the domain's mail.

Run dig MX example.com and record the hosts. Hosts containing pphosted, mimecast, or barracudanetworks mean the company has a security gateway in front of its mailboxes. Proofpoint hosts follow the format mx0a-XXXXXXXX.pphosted.com and mx0b-XXXXXXXX.pphosted.com. To test for catch-all behaviour, verifiers probe a random address that cannot plausibly exist. If the gateway accepts that address too, the domain is treated as accept-all.

When it misleads you: once a gateway is in place, the platform behind it is invisible to DNS. It can also fail the other way. Mimecast offers an API deployment with Microsoft 365 that needs no MX record changes, so a clean Microsoft 365 MX can still sit behind a gateway. Check the Remote-MTA field in the headers of any reply or bounce you already hold from that domain. Gateway status also changes over time. One survey of the top million MX domains found Proofpoint's share more than doubled between two snapshots four years apart, from 0.86% to 1.91%. Re-read the MX record each time you score rather than caching an old answer.

Score 2 if the MX points directly at the mailbox platform and any headers you hold agree with it. Score 1 for a known gateway in the MX. Score 0 if there is no MX answer, the host is one you can't identify, or headers contradict the MX. Greylisting and tarpitting (servers that defer or slow down unfamiliar senders) may explain some unknown results. I found no primary source describing how to detect either from outside, so don't score them.

Dimension 2: pattern confirmation

A company's address pattern is its format, such as first.last@domain. Confirming it shows that the format which produced this address is one the company really uses, or once used. The confirmation has to come from a source the address supplier did not control.

Commit metadata is the strongest public source. Append .patch to a public GitHub commit URL and the author's email appears, unless the author used the GitHub noreply address. Press-release contacts, speaker pages, and regulatory filings also work. Every piece of evidence must be a non-noreply address at the same domain, and it must have a date.

When it misleads you: GitHub documents that commits made before someone changed their commit email stay associated with the old address. A commit therefore proves the pattern only as of its date. The author may also have committed from a personal address, which proves nothing about the company's format. How quickly press contacts, speaker pages, and filings go stale has not been established publicly. Date everything and prefer the most recent source.

Score 2 if you find the person's own address, or two independent addresses in the same format, dated within the last 12 months and inside the person's tenure. Score 1 for one dated, independent address at the domain that matches. Score 0 if the pattern is guessed, or if only the tool that supplied the address confirms it.

The slow part here is finding someone currently at the company who has a dated, non-noreply corporate commit. Refolk lets you ask for exactly those people in plain English and returns them with their public profiles, so the pattern evidence and the employment evidence in dimension 3 often come back from the same search.

Dimension 3: current-employment proof

This dimension shows that the mailbox still has an owner. A perfectly confirmed pattern is worthless for someone who left the company last year. No public procedure for this exists, so the bands below are my policy.

Look for a dated public signal that ties the person to the company now. Good signals include a role start date on a professional profile, a recent commit from the corporate address, a speaker page, or a press mention.

When it misleads you: profiles lag behind job moves. A corporate-address commit can be years old. A speaker page can list a title from before the person moved. Use the signal's date, not the date you happened to find it.

Score 2 for a signal dated within 90 days. Score 1 for a signal within 12 months. Score 0 if nothing falls within 12 months or if there is evidence they have moved.

Dimension 4: provenance

Provenance means where the address came from and when it was last verified. It shows whether you can explain the address to someone who asks.

When it misleads you: one verifier's write-up describes vendor exports labelled "verified" that bounced by day three. A "verified" label with no date is a claim, not provenance.

Score 2 if you saw the address yourself in a public primary source and logged the URL and date. Score 1 if it came from a tool or list and you logged both the source and the verification date. Score 0 if the origin or the date is unknown.

Dimension 5: sending fragility

This dimension shows how much bounce risk the sending mailbox can absorb this week. It describes the mailbox, so every address queued on that mailbox gets the same score.

Practitioners generally warm up a new mailbox for 30 days, though that is a common consensus and not a published rule. One source goes further: send no catch-all addresses at all during the first 30 days.

When it misleads you: a healthy average across mailboxes can hide one mailbox sitting at 4%. Always measure each mailbox separately.

Score 2 if the mailbox is past 30 days and has room in its weekly catch-all allowance. Score 1 if it is warm but this week's allowance is nearly used. Score 0 if it is inside its first 30 days or its rolling rate is already at or above 2%.

How does the score become Send, Corroborate, or Reroute?

Apply the gates first, then the total. A Send needs a total of 8 or more with no zeros. A Corroborate gets one time-boxed round of evidence gathering. A Reroute goes to a channel other than email, so the person is not simply dropped.

1. Employment gate: employment scores 0 → Reroute. If the evidence shows a move, re-source the person at their new employer.
2. Fragility gate: fragility scores 0 → nothing on the catch-all list sends from that mailbox this week. The address keeps its verdict and waits.
3. Send: total of 8 to 10, with no dimension at 0.
4. Corroborate: total of 5 to 7, or a zero on pattern or provenance that more research could fix. Give it one round of research, then score it again.
5. Reroute: total of 4 or less, or still Corroborate after that one round.

What Reroute means in practice

Reroute means changing the channel, not giving up on the person. Use a channel the person has chosen to publish: a professional-network message, a phone number on their own site, a warm introduction through a shared connection, or the contact route on a speaker page. Record the channel and an owner, so that a Reroute doesn't quietly turn into a drop. Refolk returns people with their GitHub, LinkedIn, and open-web footprints together, so the alternative channel is often already in front of the sourcer when the verdict is set.

address:
domain:
verifier_status: catch-all | accept-all | unknown
verifier_run_date:
mx_hosts:
gateway: none | pphosted | mimecast | barracudanetworks | other
remote_mta_seen_in_headers:
D1 domain mail setup (0-2):
D2 pattern confirmation (0-2):   source URL + source date
D3 current employment (0-2):     signal URL + signal date
D4 provenance (0-2):             where obtained + date verified
D5 sending fragility (0-2):      mailbox + warm-up start + current 7-day bounce
total (0-10):
gates_triggered:
verdict: Send | Corroborate | Reroute
reroute_channel_and_owner:
scored_by + date:

How many catch-all sends can one mailbox carry?

Fewer than most teams assume. A mailbox sending 30 a day has about 4 bounces of budget a week under a 2% ceiling. When verified addresses bounce at 1%, about half that budget is already spent, which leaves room for roughly 17 catch-alls that bounce at 12%. Work out the allowance for each mailbox before you choose any interleave ratio.

The sources disagree on how to mix catch-all rows into sends. One says never put accept-all rows in the same send as confirmed-valid rows. Another recommends interleaving catch-all and verified sends at about 1:3 while keeping every mailbox's rolling 7-day rate under 2%. The arithmetic shows why the ratio alone is not a policy. All rows below are derived and assume verified addresses bounce at 1%.

A 1:3 mix stays at 2% only if the catch-alls you send bounce at 5% or less. Even a 10% share breaks the ceiling at a 12% catch-all bounce rate. I found no published source for a fixed "percentage of a send" rule, so calculate the allowance instead.

Interleaving dilutes risk you have already scored. It does nothing for risk you have not.

One sending platform advises keeping campaign sends at or below 30 per inbox per day. The worksheet below uses that figure. Replace it with your own daily cap.

sends_per_week        = daily_cap x 7                      e.g. 30 x 7 = 210
bounce_budget         = sends_per_week x 0.02              e.g. 210 x 0.02 = 4.2
verified_bounces      = sends_per_week x verified_rate     e.g. 210 x 0.01 = 2.1
catch_all_allowance   = bounce_budget - verified_bounces   e.g. 4.2 - 2.1 = 2.1
max_catch_alls        = catch_all_allowance / catch_all_rate
                        scored Send at 12%:  2.1 / 0.12 = about 17
                        unscored at 27%:     2.1 / 0.27 = about 7

Whether you interleave or batch separately, tag every catch-all row in the sending tool so you can see which bounces came from it. If you can't tell which segment produced a bounce, you can't calibrate the scoring.

The procedure, step by step

Run these nine steps for each list. The first and the last two belong to ops. Steps 3 to 5 belong to the sourcer. No published source gives time estimates for the evidence steps, so measure your own for a week before committing to a turnaround.

How this goes wrong: failure modes and false positives

Most failures come from trusting a signal past the point where it means anything. Here are the seven that matter most, what each looks like, and the check that catches it.

The MX gateway mistaken for the mailbox platform

What it looks like: you score a domain as a plain Microsoft 365 setup because the MX says so, while a gateway running in API mode sits behind it unseen. Or you read the gateway hostname and assume you know the platform behind it.

Check: look at the Remote-MTA field in received headers or prior bounces from the domain before giving dimension 1 a 2.

A probe treated as harmless

What it looks like: a heavy round of re-verification gets your sending IP an SC-002 block at Outlook.com, which damages the infrastructure the verification was supposed to protect.

Check: probes and re-checks run only from IPs and domains that never send outreach.

Stale pattern evidence

What it looks like: the classic false positive. A pattern is confirmed by a 2019 commit for someone who left in 2022. The format may have changed, or the commit may show an address the company has since retired.

Check: the commit date must fall inside the person's verified tenure, and the address must not be a personal or noreply address.

Judging the batch too early

What it looks like: one worked scenario shows a 1.2% bounce rate on day one becoming 4.8% by day three, because delayed bounces keep arriving after 72 hours. Teams that expand after day one end up well over the ceiling.

Check: measure on a rolling 7-day window for each mailbox. Never judge a single send, and never judge before 72 hours.

Silent drops counted as delivered

What it looks like: some configurations accept a message and then quietly discard it. A blackholed address looks exactly like a person who didn't reply, so it never shows up in bounce data and it inflates your idea of how well the list performs.

Check: no outside signal for this exists. Treat zero engagement on a catch-all address differently from zero engagement on a verified one. After the sequence ends with no engagement, Reroute it rather than re-enrolling it.

A 1:3 interleave applied blind

What it looks like: the ratio is taken from a vendor guide and applied to unscored catch-alls. At a 12% catch-all bounce rate the blended rate is 3.75%.

Check: the ratio comes last. Score first, then size the batch from each mailbox's allowance.

A vendor's "verified" accepted as provenance

What it looks like: an undated export goes into the sequence with no record of where it came from. When it bounces, nobody can say which source to downgrade.

Check: log the source and verification date for every address at import time, not after the first bounce.

Keeping the standard current

The scoring bands and the 12% planning rate are starting points. Your own bounce data should replace them within a few send cycles, and the provider rules they rest on need re-reading periodically. Treat this as a living policy with an owner, not a one-off cleanup.

• Feed back every bounce. Add hard and delayed bounces to suppression in every sending tool, not just the one that recorded them. No published cross-tool procedure exists, so the owner has to define one and check it.
• Calibrate by band. After each 7-day window, calculate the bounce rate for each verdict band and each total score. If Send addresses bounce above the rate you used in the allowance worksheet, raise the Send threshold to 9, or use the higher rate in the worksheet.
• Downgrade sources that bounce. A source whose addresses bounce repeatedly drops to 0 on provenance for future lists.
• Re-score Corroborate addresses on a schedule. A Corroborate that has had its one round of research and is still short becomes a Reroute. It doesn't sit in limbo.
• Re-read the provider pages. Google's sender guidelines, Yahoo's Sender Hub best practices, and Microsoft's 550 5.7.515 page set the complaint and authentication rules your bounce cap protects. Check them whenever you review the policy, and update the policy text if a number changes.
• Re-read MX records. Gateway adoption is changing, so a domain scored last quarter may now sit behind a gateway.