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

*Score any catch-all or unknown address on five checkable dimensions, assign Send, Corroborate, or Reroute, and size a weekly cap that keeps bounces under 2%.*

- Canonical URL: https://www.refolk.ai/guides/catch-all-address-verdict-standard
- Pillar: Process, data, and compliance
- Format: Framework
- Published: 2026-11-02
- Last reviewed: 2026-11-02
- Reading time: 22 min
- Keywords: should I send cold email to catch-all addresses, how to verify accept-all email addresses, catch-all domain bounce rate, confirm company email format catch-all domain, unknown email verification result what to do, secure email gateway email verification

## Key takeaways

- No mailbox provider publishes a bounce threshold, so the 2% rolling 7-day hard-bounce ceiling is an industry convention that a team has to adopt and own as written policy.
- In one controlled test, 100 accept-all addresses bounced at 27% against 1% for 100 verified addresses, and pooled post-send data puts catch-all bounces at roughly 8-15%.
- A 1:3 interleave of catch-all and verified sends produces a 3.75% blended bounce rate if the catch-alls bounce at 12%, and only reaches 2% if they bounce at 5% or less.
- A mailbox sending 30 a day makes 210 sends a week, and under a 2% ceiling with verified addresses bouncing at 1% it has room for only about 17 catch-alls that bounce at 12%.
- In a survey of 1.6 million domains, Barracuda-fronted domains were catch-all 99.9% of the time, so on those domains the flag tells you about the gateway and nothing about the person.
- A commit proves a company's address pattern only as of its commit date, so it counts as evidence only when that date falls inside the person's verified tenure.

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.

| Sample | Estimate | Unit counted |
|---|---|---|
| 49.0M verification records, 30 days | 7.71% | Addresses |
| 50M+ emails | 22.8% | Unique B2B domains |
| 1.6M domains | 31.4% | Business domains |
| "Tens of millions of lookups" | 35-40% | B2B domains |
| Unstated, secondhand | 15-28% | B2B domains |

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.

**27% - Bounce rate on 100 accept-all addresses in one controlled test**

In the same test, 100 verified addresses sent the same campaign bounced at 1%.

| Source | Valid | Catch-all | Invalid |
|---|---|---|---|
| Controlled test, 100 + 100 | 1% | 27% | n/a |
| Pooled post-send data, 50M+ | Under 1-2% | 8-15% | 97-99% |
| Verifier estimate, sample unstated | n/a | 9-23% | n/a |
| Forum anecdote, 34 leads | n/a | 14.7% (5 of 34) | n/a |

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.

> **Rule:** Write the cap down and give it an owner
>
> The 2% rolling 7-day hard-bounce ceiling is your policy, not a provider rule. Write it in a document with a named owner, and measure it for each mailbox rather than across the whole account, so anyone answerable for the list can point to it.

## 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.

| Dimension | 2 points | 1 point | 0 points |
|---|---|---|---|
| Domain mail setup | Direct MX, headers agree | Known gateway in MX | No MX, or headers contradict |
| Pattern confirmation | Own or two addresses, dated, in tenure | One dated address at domain | Guessed, or supplier-only |
| Current employment | Signal within 90 days | Signal within 12 months | None, or evidence they left |
| Provenance | You saw it in a public source | Tool source and date logged | Origin or date unknown |
| Sending fragility | Warm 30+ days, headroom | Warm, allowance nearly used | Under 30 days, or at 2% |

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.

**99.9% - Share of Barracuda-fronted domains that were catch-all, in a survey of 1.6M domains**

On these domains the catch-all flag describes the gateway and tells you nothing about the person.

#### The mail path as seen from outside

1. **MX record** - Public DNS, read with dig MX; the only layer you see directly
2. **Security gateway** - pphosted, mimecast, or barracudanetworks hosts; often accepts every address
3. **Mailbox platform** - Hidden from DNS once a gateway sits in front of it
4. **Individual mailbox** - Exists, does not exist, or silently discards mail

*Only the outermost layer can be read directly, and each layer below it can hide the one beneath.*

**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.

> **Watch out:** Probing can damage the IP you are protecting
>
> Outlook.com documents a 550 SC-002 block for IPs doing "namespace mining", which means probing addresses without sending to them. Run every random-address probe and re-verification from infrastructure you never send outreach from.

### 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.

#### Pattern evidence against employment proof

Horizontal axis runs from Weak pattern evidence to Strong pattern evidence. Vertical axis runs from Weak employment proof to Strong employment proof.

| Quadrant | What it means |
| --- | --- |
| Corroborate the pattern | The person is there; find a dated address at the domain before sending |
| Send, capped | Score the other three dimensions and size the batch from the allowance |
| Reroute | Reach them on a channel they chose; stop guessing the address |
| Corroborate employment | The pattern may be right for someone who left; check tenure dates |

*The two dimensions sourcers can improve most decide which kind of extra work an address needs.*

### 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 verdict record**

```
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:
```

*One record per flagged address; keep it in the same sheet as the list so the audit trail travels with the data.*

I ran this search: `Senior backend engineers currently at JPMorgan Chase in London with public GitHub commits from a corporate address in the last 12 months` - [see the full result list](https://www.refolk.ai/s/998fsmy5gf).

*Returns engineers currently at that employer in London whose public commits carry a corporate address, which gives you dated pattern evidence and employment evidence from one search.*

## 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%.

| Catch-all share | Catch-all bounce rate | Blended bounce rate |
|---|---|---|
| 25% (1:3) | 12% | 3.75% |
| 25% (1:3) | 5% | 2.0% |
| 10% | 12% | 2.1% |
| 10% | 27% | 3.6% |

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.

**Weekly catch-all allowance per mailbox**

```
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
```

*Use 12% for scored Send addresses and 27% for anything unscored until your own measured rates replace them.*

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.

#### Score and send a flagged list

1. **Split the verifier output** - Tag every row valid, invalid, catch-all, or unknown with the verifier run date, and move catch-all and unknown rows into their own working list.
2. **Read MX and fingerprint the gateway** - Run dig MX per domain, record the hosts, flag pphosted, mimecast, or barracudanetworks, and run any probe only from an IP you never send from.
3. **Confirm the address pattern independently** - Find at least one non-noreply address at the domain in a commit .patch view or press contact, and log its date against the person's tenure.
4. **Prove current employment** - Log a dated public signal that the person is at the company now, or record the evidence that they have left.
5. **Record provenance** - Log where each address came from and when it was last verified, and mark undated vendor exports as such.
6. **Assess sending fragility** - Record each mailbox's warm-up start date and rolling 7-day bounce rate, and calculate its remaining weekly catch-all allowance.
7. **Score and assign the verdict** - Score the five dimensions 0 to 2, apply the employment and fragility gates, and assign Send, Corroborate, or Reroute with an owner.
8. **Send a capped test batch** - Send 50 to 100 Send-verdict addresses within the allowance, wait at least 72 hours, expand only under 2%, and stop at 5% after the first 100.
9. **Feed results back** - Suppress hard and delayed bounces in every tool, downgrade the sources that produced them, re-score Corroborate addresses, and route each Reroute to a named channel.

## 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.

> **Watch out:** A vendor's "verified" is not provenance
>
> Exports labelled verified have been documented bouncing by day three. Every address needs a logged source and a verification date before it can score above 0 on provenance, whatever the label says.

### 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.

#### Before this list goes into a sequence

- [ ] Every catch-all and unknown row has a verifier status and a verifier run date.
- [ ] Every domain has its MX hosts recorded and a gateway column filled in.
- [ ] No probe or re-verification ran from an IP or domain that sends outreach.
- [ ] Every pattern confirmation has a source URL and a date inside the person's verified tenure.
- [ ] Every Send address has a dated current-employment signal within 12 months.
- [ ] Every address has a logged source and verification date.
- [ ] Each mailbox's weekly catch-all allowance is calculated and written down.
- [ ] No catch-all address is queued on a mailbox inside its first 30 days.
- [ ] The batch will be judged on a rolling 7-day window, no earlier than 72 hours after sending.
- [ ] Every Reroute has a named alternative channel and an owner.
- [ ] The 2% cap, the scoring bands, and the policy owner are written in one shared document.

## Frequently asked questions

### Should I send cold email to catch-all addresses?

Yes, but only to addresses that score Send, and only inside a written cap. Published post-send data puts catch-all bounce rates between roughly 8% and 27%, against 1-2% for verified addresses, so sending a whole catch-all segment blind will usually break a 2% rolling 7-day ceiling. Score each address on mail setup, pattern, employment, provenance and sending fragility first. Then size the batch from each mailbox's weekly bounce budget.

### What should I do with an unknown email verification result?

Treat unknown as missing evidence, not bad evidence. The verifier got no conclusive answer, so re-check once from an IP you never send from. If the result resolves to valid or invalid, the address leaves this process. If it stays unknown, score it exactly like a catch-all. In one study of 49 million records, unknowns were about three times as common as catch-alls, so ignoring them throws away a large share of the list.

### How do I confirm a company's email format on a catch-all domain?

Find at least one real, dated address at the domain in a source that the company who supplied the address did not control. Commit metadata in a GitHub .patch view shows the author's email unless the author used a noreply address. Press contacts and speaker pages work too. Commits keep the old address after someone changes their commit email, so a commit counts only if its date falls inside the person's verified tenure.

### Why does every address at a company with a secure email gateway come back catch-all?

Because the gateway is answering the verifier, not the mailbox. Many gateways accept mail for every address and filter it later. In one survey of 1.6 million domains, Barracuda-fronted domains were catch-all 99.9% of the time. Gateways show up in the MX record as hostnames containing pphosted, mimecast or barracudanetworks. On those domains the catch-all flag tells you nothing about the person, so the pattern and employment evidence have to carry more of the decision.

### How long should I wait before judging a catch-all test batch?

Wait at least 72 hours, and judge on each mailbox's rolling 7-day window rather than on one send. Delayed bounces are documented arriving after 72 hours, and one worked scenario shows a 1.2% bounce rate on day one becoming 4.8% by day three. Start with 50 to 100 addresses. Expand only while the rolling rate stays under 2%, and stop if it reaches 5% after the first 100.

### Is the 2% bounce rate an official limit?

No. No mailbox provider publishes a bounce threshold. Google publishes spam-rate limits of 0.10% and 0.30%, Yahoo asks senders to keep their spam rate below 0.3%, and Microsoft enforces authentication rules for high-volume senders. The 2% bounce line is industry convention, so it is a policy your team chooses. Write it down with an owner and a measurement window.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/catch-all-address-verdict-standard*