Email checks and Domain Intelligence share one credit balance. See how credits work

Start for free

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

On this page

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 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 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, an A or AAAA address can provide an implicit mail route. RFC 7505 defines the null MX declaration. The MX record reference 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 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 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 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 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 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 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:

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.

Choose what to check next.

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