# What is a catch-all email domain (and why it breaks verification)?

_2026-11-09 · Boundstone (https://boundstone.io/blog/what-is-catch-all-email)_


## What is a catch-all email domain?

If you have ever pointed an email verifier at a list and wondered *what is a catch-all email domain*, here is the short answer: it is a domain configured to accept mail sent to **every** possible address, whether or not a mailbox exists behind it. Send to `ceo@acme.com`, `careers@acme.com`, or `qx7z-not-a-real-person@acme.com`, and the receiving server says the same thing to all three: *yes, I will take that.*

Catch-alls (also called accept-all domains) are common and often deliberate. A small company might route everything to one inbox so a typo'd address still reaches someone. A larger org might accept-all at the gateway and sort delivery internally, out of view. Whatever the reason, the behavior is the same from the outside: the server accepts first and decides later.

## Why an SMTP "yes" proves nothing on a catch-all

Many verification vendors check whether a mailbox exists by opening an SMTP conversation with the domain's mail server and issuing a `RCPT TO` for the address — the same handshake a real sender makes. A `250` reply means "accepted." Historically, teams treated that `250` as proof the mailbox is real.

On a catch-all, that inference collapses. Here is an SMTP probe written with Python's standard library:

```python
import smtplib

def probe(mx_host: str, address: str) -> int:
    with smtplib.SMTP(mx_host, 25, timeout=10) as smtp:
        smtp.helo("checker.example.com")
        smtp.mail("probe@checker.example.com")
        code, _ = smtp.rcpt(address)
        return code  # 250 means "accepted"

probe("mx.acme.com", "ceo@acme.com")                    # -> 250
probe("mx.acme.com", "qx7z-not-a-real-person@acme.com") # -> 250
```

Both calls return `250`. The random string is not a real person, yet the server accepts it exactly as readily as the CEO's address. On a catch-all domain the `250` tells you the domain accepts mail — nothing about the specific mailbox you asked about. The signal you wanted is simply not there to be read.

## How catch-alls inflate false "valid" results

This is where accept-all domains quietly damage a verification report. A vendor that leans on SMTP probing has two options when it hits a catch-all, and both are bad for you:

- **Return `valid`.** The address gets a green check it did not earn. Your "verified" list now contains addresses that may bounce, and you find out only after you send.
- **Return `unknown` or `risky`.** More honest, but now a large slice of legitimate, deliverable addresses on accept-all domains gets flagged, and you either drop good contacts or learn to ignore the flag.

Good tools disclose catch-all status so you can decide. The failure mode is a tool that folds a catch-all `250` into a plain `valid` and never tells you the difference between "this mailbox exists" and "this domain accepts everything." That is the gap between *validation* and *verification*, which we pull apart in [email validation vs verification](/blog/email-validation-vs-verification).

## What Boundstone checks — and what it refuses to fake

Boundstone does not probe mailboxes and does not detect catch-all domains. Rather than infer a mailbox from a handshake that a catch-all renders meaningless, it reports both as *not performed* — out loud, in every response.

```bash
curl -s https://api.boundstone.io/v1/verify/email \
  -H "Authorization: Bearer bs_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"you@example.com"}'
```

```json
{
  "valid_syntax": true,
  "domain": "example.com",
  "mx_found": true,
  "disposable": false,
  "role_account": false,
  "free_provider": false,
  "checks": {
    "performed": ["syntax", "mx", "disposable_list", "role_list"],
    "not_performed": ["smtp_mailbox", "catch_all"]
  }
}
```

`smtp_mailbox` and `catch_all` sit in `not_performed` on purpose. Boundstone will not hand you a hollow "yes" that a catch-all could have manufactured. What it does check, it checks for real: valid syntax, live MX records at the domain, whether the address is a disposable throwaway, and whether it is a role account like `support@` or `admin@`. The `not_performed` list is the point — it is what lets you trust a `valid` from Boundstone, because you know exactly what that word covers and what it does not.

## Where the honest signal actually lives

Before you reach for an API at all, know what the free layer already gives you. For a one-off address, the [free email validator](/tools/email-validator) checks syntax and live MX without a signup, and standard-library parsers in most languages will catch malformed input on their own. Often that is genuinely all you need — so say so, and skip the paid call.

The API earns its place as the layer *past* that: disposable and role-account lists, a live MX check, and one consistent response contract across every language and client you call it from. Part of that MX check is confirming the domain can receive mail at all — the mechanics of which are covered in [what is an MX record](/blog/what-is-an-mx-record).

## The short version

- A **catch-all email domain** accepts mail to every address, real or not.
- An SMTP `250` on a catch-all proves the domain accepts mail, **not** that a specific mailbox exists — so vendors that probe can return false `valid` results.
- Boundstone does **not** probe mailboxes or detect catch-all, and marks both `smtp_mailbox` and `catch_all` as `not_performed` rather than fake a "yes."
- You can trust a `valid` because you can see exactly what was checked — `["syntax", "mx", "disposable_list", "role_list"]` — and what was not.