# What is a catch-all email?

> A catch-all (accept-all) domain accepts mail to any local-part, so "is this person real?" cannot be answered from SMTP. EmailPal flags catch-alls as their own verdict instead of calling them valid.

Source: https://emailpal.io/help/what-is-a-catch-all-email

## In one sentence

The server says "yes" to `does-not-exist-xyz@company.com` and to the real people, so a green SMTP check is meaningless.

A **catch-all** (also called accept-all) domain is configured to accept mail for every local-part at that domain, whether or not a mailbox exists. IT teams do this so they never bounce a customer who typo'd. Cold emailers meet it as a list that looks 98% valid and then goes nowhere.

## Why cold emailers care

Sending to catch-alls does **not** bounce immediately. The receiving server accepted the message. It also does **not** mean a human will read it. Mail can land in a bit bucket, a shared dump folder, or a filter nobody checks.

High catch-all rates hide list quality problems until:

- Complaints show up (someone did get it, and they marked spam)
- Ghost sends show up (nothing bounces, nothing replies)
- You think warmup "worked" because bounce rate is low, then Gmail folds you anyway

A 4% hard-bounce rate will undo warmup. Catch-alls can keep bounce rate artificially low while still wasting the send. [List verification by EmailPal](/help/list-verification-by-emailpal) exists so you see them before the campaign.

## What EmailPal does

We probe. If the domain accepts random local-parts, the address is **catch-all**, not **valid**. [Catch-all detection](/help/catch-all-detection).

Nothing is delivered during the check. `RCPT TO` only.

Catch-all is one of six verdicts. It is not "invalid" and it is not "valid." [Six verification verdicts](/help/six-verification-verdicts).

## Should you send to catch-alls?

Usually **no** on a new domain or a newly claimed [pre-warmed mailbox](/help/pre-warmed-inboxes-by-emailpal). Some teams send a smaller subset after the domain is trusted and after another source (LinkedIn, a reply, a conference list) says the person is real. That is a risk decision, not a default.

Do not let a sequencer's "valid" from a two-state verifier override EmailPal's catch-all.

## Catch-all vs similar labels

| Label | Means |
| --- | --- |
| Catch-all | Domain accepts everything. Person unconfirmed. |
| Unknown | We could not tell (greylist, timeout). |
| Disabled | Mailbox is off. Do not send. |
| Role | Function address (`info@`). Different risk. |
| Valid | Impossible mailbox rejected; yours accepted. |

## FAQs

### Is catch-all the same as "unknown"?

No. Unknown means we could not tell. Catch-all means we could tell the domain accepts everything.

### Can I "verify harder" to find the person?

Not with SMTP. You need another data source (the person's actual published address, a form they filled, a reply).

### Why do companies run catch-alls?

So they never bounce a customer. It is a receiving policy, not a gift to outbound.

### Will EmailPal ever call a catch-all valid?

No. That would be the bug we wrote the probe to avoid.

## Need more help?

[How to verify an email list before sending](/help/how-to-verify-an-email-list-before-sending).