Catch-all email domains, explained

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 ¹. 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 ¹.

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 ¹.

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 ¹. 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.

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 ¹. A domain can also say it accepts no mail by publishing a null MX, a single MX with preference 0 and the exchange . ².

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.

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

1{
2  "domain": "example.com",
3  "has_mx": false,
4  "null_mx": true,
5  "role_account": true,
6  "smtp_checked": false,
7  "deliverability_signal": "undeliverable"
8}

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 or the email domain check product page.