What is greylisting? Why honest verifiers say unknown

The short answer#

Greylisting is a spam-filtering technique in which a mail server temporarily rejects messages — and verification probes — from senders it hasn't seen before, answering with a "try again later" SMTP response instead of a yes or no. Legitimate mail servers retry a few minutes later and get through; the crude spam software the technique was designed against historically did not. For email verification the consequence is simple: a greylisting server's answer is not yet, so an honest verifier either retries within its time budget or reports the address as unknown. What it must not do is guess.

What greylisting looks like on the wire#

The deferral happens at the same point in the SMTP conversation where a normal server would confirm or reject the mailbox:

> RCPT TO:<jane@example.com>
< 451 4.7.1 Greylisted, please try again later

The first digit is the whole story (the full grammar is in SMTP response codes explained). A 5xx response (550 5.1.1 user unknown) is permanent — the address is dead, the verdict is undeliverable. A 4xx response (421, 450, 451) is temporary by definition: the server is explicitly saying that the same request might succeed later. Classic greylisting implementations track the sender's IP and the from/to addresses, reject the first attempt, and accept a retry that arrives after a few minutes — proof that a real mail server with a retry queue is on the other end.

The technique dates back to the early 2000s and survives because it is cheap and quietly effective: a legitimate mail server keeps a retry queue as a matter of course, so deferring the first attempt costs real senders nothing but minutes, while fire-and-forget spam software never comes back. Typical implementations remember the triplet of sender IP, from-address, and to-address; once a retry for that triplet succeeds, the sender is usually whitelisted for weeks, so the delay is a one-time toll rather than a permanent tax.

You will meet greylisting most often on corporate mail gateways, self-hosted servers, and security appliances. The large consumer providers mostly do something different that looks identical from the outside — more on that below, because the difference matters for verification.

What a 4xx does to a verification probe#

A verifier that hits a greylisting server has exactly three options:

1. Wait and retry. Honest and often effective, but it costs time — the greylist window is minutes, and a bulk job can't wait forever.
2. Report unknown. Honest, when retrying didn't resolve it. The address isn't bad; the server just never gave a usable answer.
3. Guess. Dishonest. Any tool that converts a 451 into a confident "valid" or "invalid" is manufacturing certainty the server refused to provide.

Here is how Qualisend handles it: a greylisted address is retried within a bounded time budget, and if the server is still deferring when that budget runs out, the verdict is unknown with reason timeout and a mid-range confidence score — an address worth re-checking later, not a dead one, which is exactly how you should treat it.

One deliberate exception: when the deferring server belongs to a major consumer mailbox provider, a 4xx is almost never classic greylisting. It is reputation-based rate-limiting, and retrying rarely changes the answer. Qualisend recognizes those cases and settles them as unknown rather than holding your job hostage to a retry that won't help — the same honest verdict, without the wait.

Why greylisting can't stall your list#

The subtle cost of deferrals isn't accuracy — it's time. A naive bulk verifier that dutifully retries every 4xx can end up with a 100,000-row job held hostage by a handful of stubborn servers, stuck at "99% complete" for an hour. We learned this the practical way, and the pipeline now carries several layers of timeouts and caps so a few stubborn servers can't stall the whole job:

• every SMTP conversation runs under a hard deadline — a server that tarpits past it becomes an unknown, and the job moves on;
• greylist retries are capped and tracked per address rather than left to loop;
• a job whose last few addresses stop making progress has that tail settled as unknown rather than letting one straggler hold the "N−1 of N" line, with a backstop behind it for anything stuck for other reasons.

The design position: a late honest unknown beats an on-time guess, but an unknown you get in minutes beats both. However a verifier implements it, this is a fair question to ask of any tool: what happens to your job when a server simply refuses to answer?

Greylisting vs its lookalikes#

Several different server behaviors end in a not-quite-answer, and they map to different verdicts:

The common thread: unknown is a statement about the conversation, not the mailbox. risky means we reached the server and learned something concerning; unknown means the infrastructure never answered conclusively. Those deserve different treatment on your list.

What to do with unknown verdicts#

• Don't suppress on a single unknown. Real, active mailboxes live behind grumpy servers. Treating unknown as invalid throws away subscribers to make a dashboard look decisive.
• Re-verify later. Greylist windows pass and rate limits reset — the same address often resolves cleanly on a second run hours or days later. This is also why two verifiers (or two runs of one) can disagree about an address without either lying: the mailbox is deterministic, the server isn't.
• Keep unverified unknowns out of high-stakes sends. Until an unknown resolves or engages, treat it like the catch-all segment: small, throttled sends where a bounce costs little — the same playbook as the Klaviyo cleaning guide applies verdict by verdict.
• Read the unknown rate as a fact about your list's servers, not a flaw in verification. B2B lists heavy on corporate gateways will always carry more unknowns than consumer lists — the tooling didn't get worse, the infrastructure got more defensive.

Frequently asked questions#

Does an unknown verdict mean the address is bad?#

No. Unknown means the mail server never gave a conclusive answer during verification — because of greylisting, rate-limiting, a timeout, or an unreachable server. The mailbox behind it may be perfectly healthy. Treat unknown as "retry later", not as a polite word for invalid.

Why did the same address get different results on two runs?#

Because the server's behavior changed between runs, not the mailbox. A greylisting server rejects the first attempt and accepts a retry; a rate-limited server defers you at busy moments and answers at quiet ones. An address that was unknown yesterday and deliverable today is the system working as designed.

Can a verifier bypass greylisting?#

The only legitimate "bypass" is patience: retrying after the greylist window, which is what verifiers do within their time budgets. Nothing guarantees an answer inside a bulk job's runtime, which is exactly why the honest verdict set includes unknown. A tool that claims it never returns unknowns is telling you it guesses.

How long should I wait before re-verifying unknowns?#

Longer than the greylist window, shorter than your next campaign. The classic greylist delay is minutes, so anything from a few hours to a few days later gives deferring servers ample room to have seen your prober before — while rate-limit-driven unknowns benefit from simply landing at a quieter moment. Re-running just the unknown segment before a major send is cheap insurance; unknowns that survive several spaced re-runs deserve the same skeptical treatment as a cold catch-all address.

Is greylisting still common in 2026?#

Yes, though unevenly. It remains a standard tool on corporate gateways, security appliances, and self-hosted servers, where it is cheap and effective. The large consumer providers have largely moved to reputation-based rate-limiting instead — which produces the same temporary deferrals from a verifier's point of view, and the same honest answer: unknown, retry later.