How greylisting reduces spam on a mail server

Greylisting is a mail-server technique that temporarily defers delivery from unfamiliar sources. A correctly configured sending server normally queues the message and retries. This can filter simplistic senders that do not retry, but it does not prove a message is legitimate or replace content and authentication checks.

The sender, recipient and IP combination

A common implementation records the sending server’s IP address together with the SMTP envelope sender (MAIL FROM) and recipient (RCPT TO). This combination is often called a triplet. Implementations may use other keys or adapt IP matching for providers with multiple outgoing servers.

First delivery attempt

When the combination is new, the receiving server issues a temporary SMTP 4xx reply, such as 451, and records the attempt. It has not accepted the message for delivery. The sender should retain it in a queue and try again according to its retry schedule. The exact code and wait time depend on configuration.

Retry and acceptance

If a retry satisfies the greylisting policy, the receiver allows the SMTP transaction to continue. Other spam filters and policy checks still apply; a successful retry is not a promise that the message will reach the inbox. Some implementations remember the accepted sender combination for a period so later messages are not delayed again.

Why it can reduce spam

Some basic spam-sending tools abandon a message after a temporary failure. Deferring them before processing message content can save resources. Sophisticated spam senders also retry, so effectiveness depends on current traffic and the rest of the filtering system; a fixed 80–90% reduction is not a general guarantee.

Costs and exceptions

The first legitimate email can arrive minutes or hours late. Password resets and order confirmations can therefore be affected. A sender that fails to retry correctly may never deliver. Large providers use multiple outbound IP addresses, so a strict IP match can mistake a retry for a new attempt. Solutions include appropriate network grouping, policy exceptions or adaptive allowlists, chosen with care so they do not weaken filtering unnecessarily.

Practical checks

Before enabling greylisting, measure queue times and false delays. Monitor temporary replies and accepted retries in mail logs. Provide a route for urgent transactional mail when appropriate, and combine greylisting with SPF, DKIM, DMARC and content filtering according to your mail setup.

Conclusion

Greylisting is a low-cost SMTP filtering layer with a delivery-delay tradeoff. Tune it to your sending partners and users rather than assuming every retry is safe or every non-retry is spam. The IETF discussion is RFC 6647: https://www.rfc-editor.org/rfc/rfc6647.html.