---
title: "Catch-all email domains, explained"
url: "https://lookvalid.com/blog/technical/catch-all-email-domains-explained.md"
canonical_url: "https://lookvalid.com/blog/technical/catch-all-email-domains-explained"
last_updated: "2026-10-22"
type: "conceptual"
summary: "Why a mail server that accepts every recipient gives no mailbox answer, what SMTP says about it, and what a domain-level check can and cannot show."
related: ["https://lookvalid.com/products/email-domain-check.md", "https://lookvalid.com/glossary/catch-all.md", "https://lookvalid.com/glossary/mx-record.md", "https://lookvalid.com/glossary/smtp-verification.md", "https://lookvalid.com/docs/quickstart.md"]
---

# Catch-all email domains, explained

Why a mail server that accepts every recipient gives no mailbox answer, what SMTP says about it, and what a domain-level check can and cannot show.

A catch-all, or accept-all, mail server says yes to every recipient address at its domain, whether or not a mailbox exists behind it. That makes any mailbox-level test at such a domain uninformative. This post explains why SMTP allows that behavior and where the limits of a domain-level check sit, so you can set the right expectations for a list you are cleaning.

## What accept-all means in SMTP

When one server hands a message to another, it names each recipient in an `RCPT` command. If the receiving server accepts the recipient, it replies `250 OK`; if the mailbox is not available, it can reply `550` [1]. The specification is explicit that this is not always the full story: in practice, some servers do not perform recipient verification until after the message text is received [1].

A catch-all domain takes that further. The server accepts every recipient, then sorts out later what to do with mail for addresses that do not exist, by delivering it to a shared mailbox, discarding it or sending a non-delivery notice. The RFC does not use the term catch-all, but the mechanism is the one it describes: acceptance and delivery are separate steps. Once a receiver answers `250 OK` to the end of the message data, it has accepted responsibility for the message [1].

## Why SMTP cannot give you a mailbox answer here

SMTP has a `VRFY` command meant to confirm an address, but a server must not return a 250 code to it unless it has actually verified the address [1]. That leaves a probe that opens a connection and walks through `RCPT`, which tests only what the server chooses to reveal.

- A rejected recipient is informative: the server told you the mailbox is unavailable.
- An accepted recipient is not: on an accept-all server it says nothing about whether a person reads that address.
- A server that defers its check until after the message body gives you no answer at all without sending mail.

So for a catch-all domain, the honest result of a mailbox probe is "unknown", and the same is true for any server that checks late.

## What a domain-level check can tell you

The part of the question that DNS can answer is whether the domain is set up to receive mail at all. A sender looks for MX records. If there are none and the name resolves to an address record, the address is treated as if it had an implicit MX with preference 0, but where MX records exist, address records are not used [1]. A domain can also say it accepts no mail by publishing a null MX, a single MX with preference 0 and the exchange `.` [2].

What a domain-level check can and cannot show

| Question | Can a domain check answer it? | Why |
| --- | --- | --- |
| Does the domain exist? | Yes | DNS answers for the name |
| Does it publish mail servers? | Yes | MX records, or the implicit MX fallback |
| Does it refuse all mail? | Yes | A null MX says so |
| Is it a known disposable provider? | Yes | Matched against open lists |
| Does this particular mailbox exist? | No | Needs the mail server to tell you, and an accept-all server will not |
| Is this domain catch-all? | No | Only visible by talking to the mail server |

## What our email-domain-check does and does not do

The `email-domain-check` product inspects the domain behind an address. It reads the MX records, flags a null MX or a domain with no mail host, reads the SPF and DMARC records, and matches the domain against open disposable-domain and free-provider lists and the local part against a role-mailbox list. It never opens an SMTP connection: the `smtp_checked` field is always `false`, so it does not inspect individual mailboxes and does not detect catch-all behavior.

The `deliverability_signal` field summarizes the domain-level findings as `good`, `risky` or `undeliverable`, with a list of reasons. A `good` signal means the domain publishes MX records and none of the risk checks matched. The mailbox itself was not checked, and the reason text says so.

Check an address at the domain level

```bash
curl -X POST https://YOUR_API_HOST/v1/email-domain-check \
  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"info@example.com"}'
```

Excerpt of a captured example response for info@example.com

```json
{
  "domain": "example.com",
  "has_mx": false,
  "null_mx": true,
  "role_account": true,
  "smtp_checked": false,
  "deliverability_signal": "undeliverable"
}
```

## Handling catch-all risk in practice

1. Run the domain check first and drop addresses at domains that accept no mail.
2. Treat `risky` as a reason to send in small batches rather than a reason to delete.
3. Watch bounces and replies on the first send, since they are the real mailbox signal.
4. Keep role addresses like info@ out of one-to-one campaigns.

To run this check over a whole list, start with the [quickstart](https://lookvalid.com/docs/quickstart.md) or the [email domain check](https://lookvalid.com/products/email-domain-check.md) product page.

## Sources

1. [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html), read 2026-10-19
2. [RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail](https://www.rfc-editor.org/rfc/rfc7505.html), read 2026-10-19

By LookValid engineering. Published 2026-10-19, updated 2026-10-19.

## Related

- [Email Domain Check API](https://lookvalid.com/products/email-domain-check.md)
- [What is Catch-all?](https://lookvalid.com/glossary/catch-all.md)
- [What is MX record (Mail Exchanger record)?](https://lookvalid.com/glossary/mx-record.md)
- [What is SMTP verification?](https://lookvalid.com/glossary/smtp-verification.md)
- [Quickstart](https://lookvalid.com/docs/quickstart.md)