Catch-all domains

Some domains accept every recipient. A shop’s contact domain routing everything to one inbox, a university forwarding into a directory it validates later, a provider that has decided mailbox existence is nobody’s business - all of them answer 250 to RCPT TO for an address nobody has ever owned.

An acceptance is worth exactly as much as the destination’s refusals are. If a domain refuses nothing, its acceptance of your address establishes nothing about your address in particular.

How it is established

Three things can establish it, and they are not equally strong.

A control recipient, after an acceptance

When a destination accepts the real recipient and the domain state needs to be established or refreshed, the same session asks about one control address - sixteen random bytes at the same domain, an address nobody could plausibly own. What happens to that recipient is what the domain’s acceptance is worth:

Control address	accept_all	What an acceptance of the real recipient is worth
refused, specifically	no	The domain discriminates. An acceptance is real evidence.
accepted	yes	The domain accepts everything. An acceptance means nothing about the mailbox.
refused ambiguously, or nothing conclusive	unknown	Undetermined. Weighed as though it could be either.

An ambiguous refusal is unknown and never no, deliberately: a false no would let a catch-all acceptance be reported as deliverable, which is the worst error this service can make. A false unknown costs one grade of certainty and nothing else.

A refusal of the address you asked about

A destination that answers no such mailbox is a destination that tells recipients apart, which is the whole content of no - so a refusal establishes the domain’s state on its own, without a second recipient being named. This observation can establish accept_all: no while the address still returns unknown and allow_with_email_confirmation: evidence about the domain and the address decision are separate.

The same care applies: only a refusal that is specifically about the recipient counts. A policy block, a bare 550 from a provider whose wording nobody has measured, and a host that announces it accepts no mail at all are each unknown.

The provider catalogue

Some operators are known to accept everything at their edge, and are not probed at all. That is recorded against the operator rather than against a domain, so it reaches every domain they host - including ones no session will ever be opened to. It fills an unknown and never overwrites: a domain that has been measured keeps its own answer.

What it does to the verdict

A recipient accepted at a domain where accept_all is yes is risky, not deliverable, and carries ACCEPT_ALL_DOMAIN. The recommended action is allow_with_email_confirmation - which is the honest answer, because a confirmation message is the only thing that would distinguish the two cases.

Where accept_all is unknown, the current policy does not add ACCEPT_ALL_UNKNOWN. That identifier remains in the recognised vocabulary, but the policy does not currently emit it. Read checks.accept_all directly. An accepted recipient can still return deliverable unless a separate risk signal changes the result; it is SMTP evidence, not proof that the mailbox exists or that the caller controls it.

It is a property of the domain, and it is remembered

The state is stored per domain and reused. Two consequences worth knowing:

• The same domain is not re-established on every request. A control recipient in every session is a shape a destination learns to refuse, and one that would spend your allowance to re-learn something that rarely changes.
• A probe-derived state has separate refresh and expiry intervals. Once refresh is due, the next suitable full check can re-establish it while it is still trusted. This is driven by requests, not a promise of a background refresh. An expired observation no longer establishes the state; an operator record remains effective until it is changed.

Two reason codes report a session that was not opened, and they are different situations:

• SMTP_PROBE_SKIPPED_PROVIDER_POLICY - this provider is not probed at all, because probing it would establish nothing.
• SMTP_PROBE_SKIPPED_ACCEPT_ALL - this domain is already established to accept everybody, so the session would have been told 250 by a server that tells everybody 250. The verdict is the one that session would have reached.

Both carry ACCEPT_ALL_DOMAIN and both are charged in full: what is sold is the decision, not the packets.

What this is not

It is not enumeration. At most two recipients are named in a session - the one you asked about, and one nobody owns - and the engine has no way to name a third. Nothing here can be turned into a directory harvest, which is a property of the code rather than a promise about how it is used.

Asking without buying a check

POST /v1/accept-all reports what is already known about a domain, free and without opening a session. It is the accumulated result of the work described above rather than a way to do any of it: where nothing has been established it answers unknown and does not find out.