---
title: "How to Verify Catch-All Email Addresses | Emvero"
description: "Check a catch-all address step by step: syntax, mail route, recipient reply and a control address. Learn what the result proves and when to confirm by email."
url: https://emvero.io/blog/how-to-verify-catch-all-email-addresses/
language: en
updated: 2026-10-07
---

Blog

# How to verify catch-all email addresses

A server may accept both real and invented recipients. Check the route and SMTP evidence, then keep the mailbox question open until you have a stronger signal.

Published 2026-09-09

To verify a catch-all email address, check the address and domain first, then compare the receiving server’s response for the requested recipient with its response for a generated control recipient. If it accepts both, you have learned how the **domain** behaves. You have not proved that the requested mailbox exists. Treat that result as `risky` and use email confirmation when you need to know that someone controls the address.

This distinction is the reason a catch-all address cannot be labelled simply valid or invalid. A catch-all server may accept mail for every name at a domain, including names nobody uses. The [catch-all definition](https://emvero.io/glossary/catch-all-domain/) explains that policy; the steps below show how to make a decision from it.

## Step 1: reject only an address that fails a definite check

Start with syntax. Parse the local part, domain and total length before asking the network anything. An internationalised local part may need the `SMTPUTF8` extension when a server is contacted. [RFC 6531](https://www.rfc-editor.org/rfc/rfc6531.html#section-3.2) defines that extension. Passing syntax means only that the address is well formed.

Next, resolve the domain and its inbound route. An authoritative answer that the domain does not exist, or an explicit null MX, can end the check before SMTP. A domain with no ordinary MX record is different: under [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1), an A or AAAA address can provide an implicit mail route. [RFC 7505](https://www.rfc-editor.org/rfc/rfc7505.html#section-3) defines the null MX declaration. The [MX record reference](https://emvero.io/glossary/mx-record/) separates these cases in more detail.

A usable route shows where mail could go. It does not say whether `alex@example.com` belongs to anyone.

## Step 2: ask about the requested recipient

A full verification may open an [SMTP session](https://emvero.io/glossary/smtp-handshake/) and name the requested address in `RCPT TO`. The server may accept it, defer it, refuse it or prevent the probe. Emvero stops before `DATA`, so the probe does not send an email. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html#section-3.3) defines the recipient and message-content stages.

A positive reply is evidence of acceptance at this stage. It is not yet evidence that this server distinguishes real recipients from invented ones. A temporary reply or a blocked probe leaves that question open. Even a reply classified internally as “mailbox not found” is reported by Emvero as `unknown` with `SMTP_RECIPIENT_REJECTED_AMBIGUOUS` under the current policy, rather than an automatic `reject`.

## Step 3: after an acceptance, test one control recipient

If the requested address was accepted, ask about one newly generated, implausible address at the **same domain** in the same session. Use a random control value rather than a familiar name such as `test`; a familiar name might exist. The [Emvero catch-all reference](https://docs.emvero.io/answers/accept-all/) describes the control-recipient check.

| Requested address | Control address | What you can conclude |
| --- | --- | --- |
| Accepted | Accepted | The server accepts arbitrary names. The domain behaves as catch-all; the requested mailbox remains unproved. |
| Accepted | Specifically refused | The server distinguishes recipients. Its acceptance of the requested address is more useful mailbox evidence, though future delivery is still unproved. |
| Accepted | Temporary or ambiguous response | The domain’s catch-all state remains uncertain. Do not call the control result a clear refusal. |
| Refused or no probe | Not sent | There is no accepted recipient to qualify with a control address. Interpret the original result on its own terms. |

The control measures a domain policy. It is not a directory search and cannot establish who owns a particular mailbox. A known catch-all state may also come from an earlier domain observation or a provider rule, so Emvero need not repeat the control on every address.

## Step 4: read the result and choose an action

A full check at a domain established as catch-all can return this combination:

```
{
  "status": "risky",
  "action": "allow_with_email_confirmation",
  "checks": { "smtp": "accepted", "accept_all": "yes" },
  "reason_codes": ["SMTP_RCPT_ACCEPTED", "ACCEPT_ALL_DOMAIN"]
}
```

`SMTP_RCPT_ACCEPTED` records the recipient reply; `ACCEPT_ALL_DOMAIN` explains why that reply does not establish an individual mailbox. Keep `status`, `action`, `checks.accept_all` and `reason_codes` together. An SMTP refusal, including an observation classified as mailbox-not-found, does not become a deterministic domain failure: the terminal result can remain `unknown`. A malformed address, non-existent domain or null MX is a different, earlier basis for rejection.

At **signup**, let a catch-all address proceed behind a confirmation message when mailbox control matters. The [signup form guide](https://emvero.io/guides/signup-form-validation/) shows how to handle `risky` and `unknown` without treating either as a definite failure.

For **list cleaning**, keep catch-all addresses separate from confirmed failures and preserve the age of the evidence. A domain can change its routing or recipient policy. The [list cleaning guide](https://emvero.io/guides/cleaning-an-email-list/) explains how to review that segment without silently deleting it.

For **outbound contact**, consider source, permission and past engagement separately. Verification does not establish consent. Confirmation proves control only when someone acts on the message; it does not guarantee later delivery or inbox placement.

## Check a known state or run a full verification

The free [catch-all email checker](https://emvero.io/catch-all-email-checker/) reports an already established domain state. It does not open an SMTP session; if Emvero has no trustworthy state, it returns `unknown`. To gather new recipient evidence, use a full address check through the [email verification API](https://emvero.io/email-verification-api/):

```
curl -sS https://api.emvero.tech/v1/verifications \
  -H "Authorization: Bearer emv_your_credential" \
  -H "Content-Type: application/json" \
  -d '{"email":"alex@example.com","variant":"full"}'
```

The API may initially return `pending` while recipient work continues. Read the completed `action` and `reason_codes` before deciding what your own workflow will do. If it says `allow_with_email_confirmation`, the remaining question is answered by sending a real confirmation message, not by another SMTP probe.

## Terms used here

### Catch-all domain

A domain that accepts arbitrary recipient names, so an accepted address may have no individual mailbox.

### SMTP handshake

The command-and-reply exchange with a mail server; a mailbox check uses it to observe the server’s recipient response.

### MX record

An MX record is a DNS record that names a domain’s incoming mail server and its preference; it does not establish a mailbox.

## Situations this applies to

### Validating an address in a signup form

Somebody is waiting on the other side of the request, so latency decides the design and a wrong rejection costs you the customer.

### Cleaning a list before a send

You are protecting the reputation of the sending domain, so the question is not which addresses are bad but which ones this send can afford.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free