# Why Does My Email Verifier Say "Unknown"? **"Unknown" is the verdict a verifier returns when it can't get a clear enough answer from the receiving mail server to call an address valid or invalid — so it reports the ambiguity honestly instead of guessing. The most common causes are greylisting, a connection timeout, transient rate-limiting between the checking service and the receiving server, and (indirectly) a catch-all domain where even confirming catch-all status itself is inconclusive. None of them mean your list is unusually broken.** If a chunk of your last batch came back "unknown," here's what's actually happening behind that word, what's worth doing about it, and whether it costs you anything. ## Why a Check Can't Always Get a Clean Answer An SMTP-level check — the step that connects to the receiving mail server and asks about a specific address, covered in full in [what an SMTP check is](/blog/smtp-check-explained) — normally gets one of two clean answers: accept the address, or reject it. "Unknown" shows up when the response falls into neither bucket. ### Greylisting Greylisting is a spam-defense technique: a receiving server temporarily rejects a message from a sender it doesn't recognize, on the logic that a legitimate sender will retry after a short delay and a spam operation usually won't. That response is specifically identifiable as greylisting (a defined set of SMTP codes plus text patterns like "try again" or "deferred") rather than lumped in with unexplained failures — which matters, because it means a greylist-caused unknown is a known, named condition, not a mystery. ### Connection timeouts and transient server friction A check depends on the receiving server responding before a waiting window closes. A server under load, a rate limit, or general network friction between the checking service and the receiving server can all produce the same practical result: no clean accept, no clean reject, just silence or a temporary error. None of that confirms anything about whether the mailbox exists — it only confirms the conversation didn't reach a conclusion. ### Catch-all domains — an indirect cause A catch-all (or accept-all) domain accepts `RCPT TO` for any address, real or not, rather than checking each mailbox individually. Contrary to what you might expect, a confirmed catch-all domain usually does **not** come back as "unknown" — it comes back as a *cautious* verdict with an elevated risk score, because the check treats "this domain accepts everything" as a real, if imperfect, piece of evidence rather than nothing at all. Here's the mechanism: PingValid's Deep tier tests for catch-all directly by probing a second, deliberately made-up address at the same domain. If that fake address also gets accepted, the domain is confirmed catch-all, and the real address's own "accept" is downgraded to a caution flag instead of being read as full confirmation. "Unknown" only enters the picture here if the catch-all *test itself* can't be completed — rate-limited or errored before it gets an answer — which is really the same transient-response cause described above. Detecting that a domain is catch-all and resolving which specific mailboxes on it are real are two different things — Deep tier can do the first; nothing can do the second from outside the mail server. ## "Unknown" vs. "Risky": Two Different Verdicts These aren't the same thing, and mixing them up leads to the wrong next action. PingValid's verdict is one of four states: **Valid**, **Risky**, **Invalid**, or **Unknown** — plus a separate 0–100 risk score attached to every check. "Unknown" means the check couldn't reach a conclusion at all. "Risky" means it reached a conclusion, and the conclusion is "proceed with caution" — a confirmed catch-all domain is a textbook example: the check completed, and what it found was reason for caution, not an absence of information. If you're comparing "risky" across different tools, check whether a given tool means a genuine, distinct verdict category (as PingValid's does) or just an elevated number attached to a verdict it's otherwise confident about — those aren't always the same design. ## What to Do With an Unknown Verdict Treat it as its own category, not a rounding error toward either side of your valid/invalid line. - **Don't suppress it like an invalid.** The check didn't find a reason to reject it — it just didn't finish the conversation. - **Don't fold it into your confirmed-valid list either.** Segment it separately so you can see how that group performs on its own. - **Send to it with more caution than your confirmed-valid list.** Running it as its own smaller batch means if something's off, it shows up isolated in that segment's numbers rather than mixed into the whole campaign's. - **Use engagement as your secondary signal.** An unknown address that opens and clicks is a reasonable practical confirmation the mailbox is live. One that never engages across several sends is a reasonable candidate to suppress later — the suppression signal there is your send history, not the original verdict. - **Treat a "risky" verdict differently from an "unknown" one.** Risky (including a confirmed catch-all) is a completed check telling you to be cautious; unknown is an incomplete check. A re-check can sometimes resolve an unknown — greylisting and transient errors are conditional, not permanent. A risky verdict on a confirmed catch-all domain won't change on a re-check, because the domain's behaviour isn't going to change between requests. One scope note: none of this — the verdict, the segment, or the engagement pattern — has anything to do with whether you had permission to email that address. Validation and verification confirm an address is real and can technically receive mail; they don't confirm consent, which is a separate requirement under GDPR, CAN-SPAM, or CASL. ## Do You Get Charged for an "Unknown" Verdict? No. An unknown verdict costs nothing — on any tier, cached or not. This is a stated pricing policy: a verdict PingValid can't stand behind isn't one it bills for. It's checkable directly on the [pricing page](/pricing) without running a single validation. For context on how credits work the rest of the time: cached lookups are free on Quick and Standard, and a cached Deep-tier lookup is billed at half the normal Deep-tier price. Those are the rules for a check that returns a normal verdict. An unknown verdict overrides both of them — it's free regardless of depth or cache status, because the check itself didn't produce an answer worth billing for. ## FAQ ### Why does my email verifier say "unknown"? Because the check couldn't get a clear enough response from the receiving mail server to call the address valid or invalid — usually greylisting, a connection timeout, or transient rate-limiting, rather than any problem with the address itself. ### What is greylisting in email verification? Greylisting is a spam-defense technique where a receiving mail server temporarily defers a message from a sender it doesn't recognize, expecting a legitimate sender to retry after a delay. During a verification check, that deferral is a specifically identifiable, non-final response — not a confirmation the mailbox is real or fake. ### Does a catch-all domain always produce an "unknown" verdict? No. A confirmed catch-all domain typically produces a "risky" verdict with an elevated risk score, not "unknown" — the check did reach a conclusion (the domain accepts everything), it's just a cautionary one. "Unknown" only applies if the catch-all determination itself couldn't be completed. ### What's the difference between an "unknown" verdict and a "risky" one? "Unknown" means the check could not reach a conclusion. "Risky" means the check completed and found a reason for caution — for example, a confirmed catch-all domain. They describe different situations and call for different handling. ### Can a verification tool ever resolve which specific mailboxes are real on a catch-all domain? No external check can. A tool can detect that a domain is catch-all by testing whether it accepts an address that shouldn't exist — but detecting the catch-all configuration is not the same as determining which of its addresses route to a real inbox, and no outside probe can force that distinction. ### Do I get charged for an email that comes back "unknown"? No. An unknown verdict is never charged, on any tier, whether it came from a fresh check or would otherwise have been a cache hit. Source: [pingvalid.com/pricing](https://pingvalid.com/pricing) ### Should I remove unknown-verdict addresses from my list? Not automatically. The check didn't find a reason to reject them. A more reliable approach is to segment them separately, send to them with extra caution, and use actual engagement (opens, clicks) as your signal before deciding whether to suppress.