Greylisting is an anti-spam technique that exploits a difference between legitimate mail servers and many spam systems. A receiving server temporarily refuses a message from an unfamiliar sender. A standards-compliant sending server will queue the message and try again later. Many bulk spam engines do not retry, or do not retry quickly. The technique is simple, cheap to run, and effective against a particular class of spam, but it has real costs.
How the mechanism works
When a message arrives, the receiving server records a triplet: the connecting IP address, the envelope sender, and the envelope recipient. If this triplet is new, the server replies with a temporary failure, a 4xx code such as 450 or 451, and stores the triplet with a timestamp. The message is not discarded. It is deferred.
The sending server keeps the message in its queue and retries after a delay. Standard MTA queues retry after a few minutes and continue at increasing intervals for days. When the retry arrives after the minimum delay, and within the expiry window, the server accepts the message and marks the triplet as known. Later messages with the same triplet pass immediately.
- First attempt from an unknown triplet: temporary rejection.
- Retry after the minimum delay: accepted, and the triplet is recorded as valid.
- Subsequent mail from the same triplet: accepted without delay, until the record expires.
Why it works
Much spam is sent by software that treats a rejection as final. It makes one attempt, moves on, and does not queue the message for retry. Greylisting filters that software out at the cost of one deferred delivery. It also avoids content analysis, so it does not need to read the message and it does not depend on a message's text. The overhead is a small database lookup per connection, which is why it has been used on smaller and older systems.
Greylisting is also independent of reputation lists. A sender with a clean record and a sender with no record are treated the same on first contact, which is a feature for avoiding false positives but a limit for the cases where a reputation signal is already known.
Benefits
- Low cost. The check is cheap and needs no content scanning.
- Low false positives for real senders. Legitimate servers retry, so the delay is an annoyance rather than a loss.
- Reduces load. Spam that never retries is rejected before the message is accepted, which saves processing and storage downstream.
- Complements other checks. It works alongside SPF, DKIM and DMARC evaluation and content filters.
Delays and other costs
- First-contact delay. The first message from a new sender waits for the retry interval. For a password reset or a one-time code, a few minutes can be significant.
- Retry from a different IP. Large senders use pools of outbound servers. A retry can arrive from a different address than the first attempt, which creates a new triplet and resets the wait. Some implementations match on a subnet instead of a single address to reduce this problem, at the cost of a little precision.
- Time-sensitive mail. Alerts, calendar invitations and similar messages can be delayed in ways that matter.
- Misconfigured senders. Some systems do not retry properly, and their messages are delayed or lost until the sender notices.
Reducing the drawbacks
Most implementations let you define allowlists for known senders and domains, so critical senders bypass the wait. Auto-whitelisting, which adds a sender after a number of successful deliveries, reduces the delay for regular correspondents. Tuning the retry window and the record lifetime changes the balance between strictness and delay. Postgrey is a widely used greylisting daemon that works as a Postfix policy service, and many other MTAs can use a similar policy hook.
Where it fits
Greylisting is one layer among several. It is weaker against spam that retries correctly, and it does nothing about mail that is sent by a legitimate server but contains unwanted content. Used with authentication checks and filtering, it is a useful cheap filter. Whether a particular provider uses it is an operational choice, and it is not a guarantee against any specific kind of message.
If you run your own mail server and see delayed first messages from a sender, check the log for 4xx responses and confirm that the sender retried. The delivery troubleshooting guide covers how to trace deferred mail, and the bounce messages guide explains how to read the responses your server gives.