# Catch-all e-mail address

> A catch-all (accept-all) domain accepts mail for any address at that domain, so no check can prove a specific mailbox exists. What it means and how to treat it.

Canonical: https://mobilevalidate.com/glossary/catch-all-email · Last updated: 2026-09-26

![A cell tower sends signal to a SIM card; the line type is identified as mobile rather than landline or VoIP.](https://mobilevalidate.com/images/carrier-and-line-type-lookup.svg)

*Carrier lookup returns the line type (mobile, landline or VoIP) and the network behind the number.*


A catch-all e-mail address is any address at a domain whose mail server is configured to accept mail for every recipient, whether or not a mailbox with that name exists. Because the server says "yes" to everything, no outside check can prove that a specific address at a catch-all domain belongs to a real, read mailbox. The same setup is also called an accept-all domain.

## How does a catch-all domain work?

When one mail server delivers to another, it names each recipient in the SMTP `RCPT TO` command and the receiving server answers with a reply code. The mail standard, [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321), leaves the meaning of the part before the `@` entirely to the receiving domain: the local part "MUST be interpreted and assigned semantics only by the host specified in the domain part of the address" (§2.3.11).

A normal server rejects an unknown recipient with a permanent `550`-type reply. A catch-all server accepts every recipient at the SMTP stage and then routes messages for unknown names to a shared inbox, discards them, or bounces them later in a separate message. From the outside, `jane@example.com` and `xq7z@example.com` look identical: both are accepted.

Companies set up catch-alls for practical reasons: to catch misspelled staff addresses, to keep mail flowing to former employees' addresses, or to create unlimited aliases for tracking. Some mail filters behave like a catch-all on purpose, accepting everything and deciding later, so that address probing reveals nothing.

## Why can't a verifier confirm the mailbox?

Mailbox checks work by asking a question the receiving system answers truthfully. RFC 5321 already lets servers refuse to answer the old `VRFY` and `EXPN` commands for security reasons (§7.3), and a catch-all goes further by giving the same positive answer for every address. So a tool that reports a catch-all address as "valid" is guessing. The honest result is **unknown**, and it should be labelled and priced as such.

## Why does it matter for deliverability and fraud?

- **Hidden typos.** `jonh@company.com` is accepted at a catch-all domain, so the person never receives your password reset or receipt, and you get no bounce to warn you.
- **Late bounces.** Some catch-all servers accept at SMTP time and send a bounce afterwards. These still count against your sender reputation. See [e-mail bounce](/glossary/email-bounce).
- **Fake sign-ups.** Anyone who owns a domain can point a catch-all at it and generate unlimited addresses for trial or promo abuse. The addresses will receive mail, but they don't represent separate people.

## How should you handle catch-all addresses?

1. **Treat them as unknown, not valid.** Keep a separate status so reports don't mix them with confirmed mailboxes.
2. **Confirm at sign-up.** A confirmation link or code proves someone controls the address, which no pre-check can.
3. **Add friction by risk.** For a newsletter sign-up, confirmation is enough. For a free trial with paid compute, combine it with phone checks and rate limits.
4. **Watch engagement and bounces** for opted-in contacts, and suppress addresses that bounce.

## How does MobileValidate handle catch-all domains?

Our [mailbox check](/services/email-verification) covers **major webmail providers only**. Company and custom domains, which is where catch-alls live, are outside that coverage. They return `registered: null` with `reason: UNSUPPORTED_PROVIDER`, and you are not charged. We don't label catch-all addresses as valid, and we don't offer a separate catch-all detection flag. The [e-mail sign-up recipe](/docs/recipes/email-signup-check) shows how to route unknown answers to a confirmation step. Related terms: [MX record](/glossary/mx-record), [disposable e-mail address](/glossary/disposable-email-address).

## Frequently asked questions

### What does catch-all mean in e-mail verification?

It means the domain's mail server accepts every recipient address during delivery, whether or not a real mailbox sits behind it. A verifier therefore can't tell a real address from a made-up one at that domain, and the honest answer is unknown.

### Are catch-all addresses bad or risky?

Not in themselves. Many companies use a catch-all so mail to misspelled staff addresses isn't lost. The risk is that a typo or a fake address looks deliverable, so you only find out later from bounces or a lack of engagement.

### How should a sign-up form treat a catch-all address?

Accept it, but confirm it: send a confirmation link or code and only activate e-mail-dependent features once the person clicks. Don't block it outright, and don't count it as verified.