Skip to content

What is a catch-all email address, and how should you handle it?

published · September 3, 2026 · updated · October 8, 2026

A catch-all domain accepts mail for every address, so no handshake can confirm one mailbox. What Spaw reports, how the confidence score works, when to send.

A catch-all email address is any address at a domain whose mail server accepts mail for every recipient, whether or not the mailbox exists. Because the server says yes to everything, an SMTP handshake cannot tell a real mailbox from a made-up one, and a verifier has to report the address as unconfirmed rather than deliverable. Roughly, catch-all means "the domain is real and receiving, the mailbox is unknown."

What is a catch-all address?

Every domain's mail server decides, at the RCPT TO step of the SMTP conversation, whether it will accept mail for a recipient. A normal server checks its directory and answers 550 5.1.1 for an unknown user. A catch-all server, also called accept-all, answers 250 OK for every recipient and sorts the mail out afterwards: it delivers what matches a mailbox, forwards the rest to a default inbox, or silently drops it.

The effect on verification is total. The handshake that settles most addresses proves nothing here, because the same 250 comes back for [email protected] and for [email protected].

Why do catch-all servers exist?

Four common reasons, and none of them is a mistake.

Setup Why it accepts everything
Security gateways (Proofpoint, Mimecast, Barracuda) The gateway sits in front of the real mail system and often accepts first, then filters or bounces internally
Microsoft 365 tenants Directory-based recipient checking is optional; many tenants accept all recipients at the edge
Small businesses and agencies One default inbox collects mail to any address at the domain so nothing is lost
Anti-harvesting policy Rejecting unknown users lets an attacker enumerate valid addresses; accepting everything hides the directory

The last reason matters: some of the most carefully run domains are catch-all on purpose. The first one changes the arithmetic: when the domain's mail provider is a security gateway (mx_provider_type: "security_gateway" — Proofpoint, Mimecast or Barracuda), the catch-all is the gateway's design rather than a squat, so the score carries catch_all_gateway at 15 instead of catch_all at 30. The reason stays catch_all either way.

How does verification detect a catch-all?

The tell is a server that accepts a recipient no real person could have. Verification providers probe with an address that cannot exist and, if it is accepted, mark the domain catch-all. Spaw's mailbox provider reports that classification directly, and Spaw remembers it: a catch-all answer is stored per domain for seven days, so later addresses at that domain are answered from memory and no further handshakes are spent on a question the server will not answer.

The domain endpoint exposes the same memory. GET /api/v1/email/domain/acme.com returns catch_all: true once any address at the domain has been seen to be catch-all in the last week, and null when that is not known.

What does Spaw return for a catch-all address?

The verdict is risky with reason: "catch_all", mailbox_exists stays null, and the handshake detail explains itself.

curl https://spaw.co/api/v1/email \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]"}'
{
  "success": true,
  "data": {
    "email": "[email protected]",
    "deliverable": "risky",
    "reason": "catch_all",
    "risk_score": 30,
    "risk_level": "medium",
    "smtp_checked": true,
    "mailbox_exists": null,
    "catch_all": true,
    "mailbox_confidence": 65,
    "risk_signals": [{ "signal": "catch_all", "weight": 30, "dataset": "mailbox-smtp" }],
    "// 36 more fields": "see the endpoint reference"
  },
  "meta": { "credits_used": 0, "credits_remaining": 10, "cache_hit": false }
}

That request is free because [email protected] is one of the six fixed test addresses. A real catch-all answer is billed like any other risky answer: 1 credit, with repeats of the same address free for seven days. The catch-all flag adds 30 to the risk score, which alone puts the address in the medium band.

What is mailbox_confidence?

Since the handshake cannot say whether the mailbox exists, Spaw adds an estimate built only from signals already in the response, so you can recompute or ignore it. It starts at 50 and moves as follows.

Signal Adjustment
Delivery outcomes every account reported for the domain, five or more: bounce rate of 50% or more −20
Delivery outcomes every account reported for the domain, five or more: bounce rate of 10% or less +15
DMARC policy reject or quarantine +15
DMARC policy none +5
SPF record published +10
No SPF record −10
Mail hosted at an established provider (Google, Microsoft, Proofpoint, Mimecast, Barracuda, Zoho, Fastmail) +10
Username looks like a name (dictionary of first names and surnames) +15
Username looks like keyboard mash −25
Role address such as info@ +5
Domain registered less than 90 days ago −15
Domain registered two years ago or more +10
Plus-tag alias −10
Username follows the naming convention seen in the domain's confirmed deliveries (first.last, flast, …) +15
Username is name-shaped but breaks that convention −10

The result is clamped to 0 to 100. Delivery outcomes only count once five or more have been reported for the domain through the API or a provider webhook, and they are read as counts per domain — the share that bounced, and the shape the delivered usernames take — never as addresses. A domain administered with DMARC and SPF, hosted at a serious provider, with a name-shaped username in the house style, reaches the top of the range; a plus-tagged mash of consonants at a domain registered last month lands near zero.

A relay alias (is_relay: true) is the exception. At a forwarding service such as Firefox Relay or Brave Email Aliases, the domain's DMARC, SPF, provider and age describe the relay operator, and an alias's name, whether the relay generated it or its owner chose it, proves nothing, so none of the rows that argue for the mailbox applies. A relay address stays at 50, and only the evidence against it moves it: a bounce rate of 50% or more takes 20 off, and a plus-tag takes 10.

How should you send to catch-all addresses?

Treat them as a segment, not as a verdict to act on blindly.

Send in moderation first. A catch-all address that bounces is a hard bounce like any other, so warm the segment with small volumes and watch the results before sending the whole list.

Report what happens. Post delivered and bounced outcomes to the feedback endpoint, or point your sending provider's bounce webhook at Spaw. A delivered report turns later lookups of that address into confirmed mailboxes (smtp_reason: "delivered_recently", mailbox_exists: true), and bounces move both the suppression list and the domain's bounce rate, which feeds the confidence score for every other address at the domain.

Branch on the confidence score for the rest. A common policy is to send to catch-all addresses with a confidence of 60 or more, hold the rest for a second attempt, and drop anything under 30. Treat relay aliases (is_relay: true) as a segment of their own: they stay at 50, and a second attempt cannot raise them. Because the score is recomputable, you can tune those thresholds against your own bounce data instead of trusting a label.

What to do next

Related

markdown version: /guides/catch-all-email-addresses.md

Verify addresses the same way

The Spaw API runs every check described here on each lookup, with an SMTP handshake that never sends mail. 10 free lookups a month, no card required.

Get your API key

More guides