Accept-All vs Unknown: Two Results That Need Different Handling

Accept-all and unknown both mean "not confirmed", but for opposite reasons. Accept-all means the mail server answered, and answered yes to everything, including an address that cannot exist. Unknown means the server never gave a usable answer. Accept-all will come back the same tomorrow; unknown often will not, so only unknown is worth re-checking.

Most verifiers report the two as separate statuses. Some, including ours, fold both into one "risky" bucket. Either way, the decision you make about each address depends on knowing which of the two you have. Our guide to verification results maps every vendor's labels; this post is about telling these two apart and acting on each.

What the server actually said

The difference is visible in the SMTP conversation: accept-all is a definite reply, unknown is a missing or temporary one. A verifier asks about a mailbox at the RCPT TO step without sending a message, then asks about a deliberately random address on the same domain.

An accept-all domain looks like this (illustrative):

> RCPT TO: <jane.doe@company.com>
< 250 2.1.5 OK
> RCPT TO: <x7qk2m9zt1@company.com>
< 250 2.1.5 OK

Both accepted. The server's answer is clear; it just does not distinguish real mailboxes from invented ones, which is what makes it a catch-all domain.

An unknown result looks like one of these instead (illustrative examples; exact wording varies by server):

< 450 4.2.0 <jane.doe@company.com>: Recipient address rejected: Greylisted
< 421 4.7.0 Try again later, closing connection
(no reply before the timeout)
(connection refused on port 25)

None of those say anything about the mailbox. They say the check did not finish.

	Accept-all	Unknown
Server reply	250 for the address and for a random one	4xx, timeout, or no connection
What it tells you	The domain accepts everything	Nothing about the mailbox
Caused by	The domain's configuration	Timing, throttling, anti-spam systems, network
Changes on a re-check?	Rarely, only if the company reconfigures	Often
Right next step	Decide using the address's source	Re-check later

How vendors describe the two

Vendor documentation draws the same line: accept-all is unverifiable by design, unknown is a failed attempt. ZeroBounce's status code reference describes catch-all addresses as "impossible to validate without sending a real email and waiting for a bounce", and unknown as "We couldn't validate for one reason or another. Typical cases include an offline mail server or an anti-spam email system."

Bouncer's terminology page defines unknown as "We were unable to receive a response from the email provider", and puts accept-all inside its risky status under the reason low_deliverability.

ZeroBounce's sub-statuses for unknown are worth reading closely, because the vendor itself predicts different outcomes for different causes:

ZeroBounce sub-status	What ZeroBounce says
greylisted	"If you resubmit these emails, they will often validate on a second pass."
timeout_exceeded	"Most of the time, these emails will end up being invalid."
mail_server_temporary_error	"Most of the time, these emails will end up being invalid."
mail_server_did_not_respond	"Most of the time, these emails will end up being invalid."
failed_smtp_connection	"Most of the time, these emails will end up being invalid."
antispam_system	Anti-spam systems "are preventing us from validating these emails."

Those are ZeroBounce's own characterisations, not independent measurements, but the point holds generally: "unknown" is several different situations, and greylisting is the one most likely to clear up.

ZeroBounce also says "you are not charged for unknown results, credits will be credited back." Billing rules vary by vendor, so check yours before re-running a large unknown segment.

Why unknown usually deserves a second attempt

The most common causes of unknown are deliberately temporary, and the standards say how long they last. Greylisting, described in RFC 6647, is "the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism". The RFC says the temporary reply should be 421 or 450, and that the window in which a retry is accepted "SHOULD be from one minute to 24 hours". The widely used Postfix greylister postgrey defaults to a 300-second delay before it accepts a retry.

A verifier that asks once and moves on will record every greylisted address as unknown. A verifier, or a person, that asks again later will get a real answer for many of them. That is why our greylisting glossary entry describes it as a nuisance rather than a verdict.

A sensible re-check schedule:

1. First retry a few hours later, which clears a typical greylisting delay.
2. Second retry the next day, which catches servers that were down or overloaded.
3. Stop there. Whatever is still unknown after two retries is behaving like a domain you cannot verify, and should be handled like accept-all.

Timeouts and refused connections can also be caused by the verifier rather than the recipient. If a verifier's network cannot reach port 25, everything it checks comes back unknown. We measured how common that is in cloud providers block port 25. If a single tool returns unknown for a large share of mainstream domains, suspect the tool.

Why re-checking accept-all is usually wasted effort

An accept-all domain will accept your test address again tomorrow, because acceptance is its policy. The domain is configured to take mail for every address and sort it out later, or not at all. Nothing about the second probe is different from the first.

Accept-all results change only when the company changes its mail setup, for example by moving to a provider that rejects unknown recipients at the edge. That happens occasionally, which is a reason to re-verify old lists on a normal re-verification cadence, not a reason to keep re-running the same accept-all addresses this week.

Instead, accept-all addresses need a sending decision based on where each address came from, a measured test batch, and a volume cap tied to your bounce limit. We set that out step by step in should you email catch-all addresses.

When the two are reported together

Some verifiers merge accept-all and unknown into one status, so you need the reason field to split them. That is a defensible design choice, because in both cases the mailbox was not confirmed and neither should be treated as valid. It does mean you lose the hint about which addresses are worth a retry.

If your results file has a single risky or unverifiable bucket, you can split it yourself:

• Read the reason or sub-status column, if there is one. Accept-all, catch-all or low_deliverability go one way; timeout, greylisted, no connect or unavailable_smtp go the other.
• Group by domain. If every address on a domain came back the same way, and the domain accepted a random address, it is accept-all. If addresses on the same domain came back mixed, some valid and some unconfirmed, the unconfirmed ones were probably temporary failures.
• Re-run the whole bucket once, a day later. Addresses that resolve to valid or invalid were unknown. Addresses that come back unconfirmed again are almost always accept-all.

SimpleVerifier is one of the tools that merges them: anything the mailbox probe could not confirm is returned as risky, never as valid, and transient failures are retried rather than stored as a verdict. The free single email checker shows the reason behind a risky result for any one address.

What not to do with either

Do not treat both as invalid, and do not treat both as valid. Deleting every unconfirmed address throws away real people on domains that simply configure their mail this way. Sending to all of them at once, mixed in with confirmed addresses, risks the bounce rate your platform tolerates. The thresholds vary by provider; we collected them in bounce rate limits by platform.

Practical takeaway

Split unconfirmed results into two piles before deciding anything:

1. Unknown: the server never answered. Re-check a few hours later and again the next day.
2. Accept-all: the server answered yes to everything. Do not re-check; decide by source and test batch.
3. Anything still unknown after two retries joins the accept-all pile.