Deliverability

Greylisting

A receiving server temporarily rejects mail from an unknown sender and expects a retry. Legitimate servers retry; many spam operations do not.

A receiving server temporarily rejects mail from an unknown sender and expects a retry. Legitimate servers retry; many spam operations do not.

How it works

A greylisting server answers the first delivery attempt from an unfamiliar sender with a temporary error (450 or 451), and remembers the combination of sender, recipient, and sending IP. A correctly built mail server queues the message and retries after a few minutes. On the retry, the greylisting server accepts it.

The bet is that spam software, which sends once and moves on, will not retry. Real servers do.

Why it matters for you

For sending: greylisting delays a message, usually by minutes, occasionally longer. If your sequencer does not retry soft failures, it will report a delivered-in-ten-minutes message as lost. See soft bounces.

For verification: a verifier probing a mailbox can be greylisted too. A single probe that gets a 4xx has learned nothing about the mailbox, and a tool that calls the address "invalid" or "valid" on that basis is guessing. The honest result is unknown, with a retry later.

How common it is

Less than it was. Large providers do not greylist in the classic way, but many smaller company servers and self-hosted setups still do, and so do some security gateways. It is most visible when you email small businesses.

What to do

Make sure your sending tool retries temporary failures for several hours, not once. Do not blast the same address repeatedly to "get it through": the retry has to come from the same server, on the server's own schedule. Related: throttling.

Ready to try it on a real list?

A receiving server temporarily rejects mail from an unknown sender and expects a retry. Legitimate servers retry; many spam operations do not.

Get started

Related