Graylisting

When a message arrives, the graylisting server records a triplet: the sending IP address, the envelope sender, and the recipient. If it has never seen that exact combination before, it returns a temporary 4xx reply (commonly 451 or 421) and closes the connection without accepting the message. It does not reject the mail; it simply says “not yet.”

A properly built mail server treats that 4xx as a soft bounce, queues the message, and retries after a delay. When the retry arrives and the triplet has aged past a short minimum (often just a few minutes), the server accepts it and usually records the triplet so future mail between those two parties passes straight through. The whole mechanism rests on the fact that legitimate senders retry and most high-volume spam tools, optimised for throughput, do not.

RFC 6647 calls graylisting “cheap and early” because it acts at the very start of the SMTP conversation, before the message body is even transferred, and costs almost nothing to run. Its effectiveness comes from an asymmetry in how the two sides behave.

Much spam is sent by “spamware” that implements only a stripped-down version of SMTP and is built for raw volume. When such software hits a temporary failure it does not retry; it simply moves on to the next address in its list, because in spamming, volume counts for far more than reliable delivery to any one mailbox. A standards-compliant mail server, by contrast, is required to retry. Graylisting turns that single behavioural difference into a filter, which is why RFC 6647 notes it “surprisingly remains useful” despite being a very old idea.

Graylisting’s downside is latency on the first message between any two correspondents. A genuine email from a sender the server has never seen is deferred until the sending server retries, which can be anywhere from a couple of minutes to, in some configurations, an hour or more. For time-sensitive mail such as password resets, one-time codes, and order confirmations, that delay can be a real problem. Once the triplet is known, subsequent mail is unaffected.

From a sender’s point of view, graylisting is normal and not a reputation hit, as long as your server retries. The practical risks are a sending platform that gives up too soon instead of retrying, and a rotating pool of IPs where each new address is a fresh, never-seen triplet that gets deferred again. To reduce friction, many receivers now allowlist senders with a strong reputation or valid authentication so their mail skips the delay entirely.