Greylisting Explained: Why Some Verifications Come Back Unknown

You verified a list and some addresses came back Unknown. Not valid, not invalid: the verifier could not get an answer. One of the most common reasons is greylisting, an anti-spam technique that deliberately refuses the first attempt from any unfamiliar sender. It is harmless for real mail and slightly annoying for verification, and once you know how it works, the Unknown results make sense.

How greylisting works

When a greylisting mail server receives a connection from a sender it has not seen before, it records three things: the sending IP, the sender address and the recipient address. Then it refuses the message with a temporary error, something like:

451 4.7.1 Greylisting in action, please come back later

or more cryptically:

450 4.2.0 Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html

A legitimate mail server treats a 4xx reply as "try again later" and retries, typically within five to thirty minutes. On the retry, the server recognises the same triplet, lets the message through, and remembers the sender so future mail is accepted immediately.

The technique works because most spam software does not retry. It fires once and moves on. Greylisting stops a large share of that traffic at almost no cost, which is why it remains popular on self-hosted servers, university systems and some hosting providers, even though the big mailbox providers do not use it.

Why it produces Unknown in verification

A verifier connects, names the recipient, and gets the 4xx reply. At that moment it has learned nothing about the mailbox: the server would have said the same thing to a real address and a fake one. The only honest result is Unknown. Our guide to how verification works without sending shows where in the conversation this happens.

A verifier could wait and retry, and some do when the delay is short. But greylisting windows are chosen by each server, and holding a 10,000-address job for half an hour per greylisted domain is not practical. So the address is reported Unknown, and the fix is to verify it again later.

Other reasons for Unknown

Greylisting is one of several. The others you will see:

The last-but-one row is the one to know about. Outlook.com and Yahoo reject connections from IPs they do not trust before the recipient is mentioned, and a verifier whose IP is in that position returns Unknown for every address on those providers. How each provider behaves is in how Gmail, Outlook and Yahoo respond to email verification.

What to do with Unknown addresses

1. Do not treat them as deliverable. Some are real, some are not, and you have no information about which. Sending to all of them means sending to the invalid ones.
2. Do not delete them either. Most Unknowns from greylisting and timeouts are real addresses on slightly unusual servers.
3. Re-verify after a day. Greylisting windows will have expired and outages will have cleared. On a typical list, a large share of the Unknown group resolves to a definite answer on the second pass.
4. Send to what remains as a small test batch, after your deliverable segment, and watch the bounce rate. The approach is the same as for catch-all addresses, described in is it safe to send to catch-all emails.

Greylisting when you are the sender

If you run your own mail server or use an SMTP service, greylisting shows up as delays: a message to a greylisting domain arrives ten or twenty minutes late, and your logs show a 4xx followed by a successful retry. This is normal. The only time it is a problem is when your sending software does not retry, or retries from a different IP each time, so the triplet never matches. Sending platforms that rotate IPs across a pool can fall foul of this; the usual remedy is to retry from the same IP, which most platforms do.

Greylisting is also why cold email tools and warm-up services sometimes report a message as deferred. Deferred is not bounced. For the difference between deferrals, soft bounces and hard bounces, see soft bounce vs hard bounce.

How InboxSure handles it

A 4xx at the recipient step is reported as Unknown with a temporary-failure reason, and the result is not cached, so re-verifying the address later runs a fresh check. A rejection before the recipient step is reported as Unknown with a sender-rejected reason, so you can tell the two apart in your download and decide what to retry.