Why Does an Email Verification Come Back Unknown? Causes and What to Do
Unknown means the mail server gave no reliable answer, not that the address is bad. The common causes, what each one means for you, and how to handle unknown results in a campaign.
An unknown result is the verifier saying: "I asked, and the receiving mail server did not give me an answer I can trust." It is not a verdict on the address, and it is not a bug. Some mail servers answer questions about their mailboxes slowly, unclearly or not at all, and a verifier that guessed would give you worse data than one that admits it does not know.
How unknown differs from risky and invalid
- Valid: the mailbox exists. Send.
- Invalid: the address cannot receive mail. Remove it.
- Risky: the server accepts mail, but the mailbox cannot be confirmed, for example on a catch-all domain.
- Unknown: the server gave no reliable answer at all.
Risky is a known situation: the server says yes to everything. Unknown is a missing answer.
The usual causes
| Cause | What happens | Does a later check help? |
|---|---|---|
| Greylisting | The server refuses the first contact with a temporary code and expects a retry later | Often, after a few hours |
| Slow or busy server | The reply arrives after the time a check is allowed to wait | Sometimes |
| Rate limiting | A large provider limits how many mailbox questions one source may ask in a short time | Often |
| Probe blocking | The server refuses every mailbox lookup and says nothing about the mailbox | Rarely |
| Unreachable mail host | The domain points to a server that does not answer on the mail port | Rarely |
Greylisting and rate limits: wait, then ask again
Greylisting is a spam defence. A server that has never heard from a sender says "try again later" and only accepts the second attempt. A verifier that retries a few seconds later often meets the same refusal. Rate limits work in a similar way: the answer you did not get at a busy moment is often available later.
Blocked and unreachable servers: the answer may never come
Some servers will not discuss mailboxes with anyone, and some domains list a mail server that is simply not there. Checking these again rarely changes anything. The practical approach is to treat them as unconfirmed and let your first send be the test.
What to do with unknown results
- Do not re-run them straight away. Every checked address uses a credit, also unknown, so an immediate second pass mostly buys the same answer. If you want a second look, wait several hours or until the next day.
- Look for a pattern. Many unknowns on one domain are that domain's policy. Unknowns spread across the big providers at a busy hour are more likely to change on a later check.
- Decide by purpose. A sign-up form should accept the address and move on. A newsletter can send to unknown addresses in small batches after the valid ones and watch the bounces. Cold outreach should hold them back. Transactional mail should send normally and watch the bounce log.
- Let the bounce be the final answer. After one send, a permanent bounce is better evidence than any check. Remove those addresses and keep the rest.
How many should you expect?
It depends on the mix of your list. In our own tests on mixed consumer lists, about 9 in 100 addresses came back unknown. A list made of small company domains, or of one big provider, can look very different. Treat your own first result as the benchmark and compare later runs with it.
Where to check
Try a single address with the email checker to see the result and reason, or run a whole file through bulk verification. The API returns the same result and a reason you can store.
Frequently asked questions
Does unknown use a credit? Yes. Every checked address uses one credit, also when the answer is unknown.
Should I delete unknown addresses? Not automatically. Keep them in a separate group, send to them carefully and remove the ones that bounce.
Is unknown the same as catch-all? No. Catch-all is reported as risky: the server accepts the address but the mailbox cannot be confirmed. Unknown means there was no reliable answer.
