Greylisting, Deferrals, And The 4xx Dance

Greylisting is an anti-spam technique where a mail server temporarily rejects the first delivery attempt from an unfamiliar sender with a 4xx reply, then accepts the message when the sender retries. It works on a simple asymmetry: a real, RFC-compliant MTA queues a temporarily-failed message and retries a few minutes later, while a large share of spam-sending software fires once and never comes back. The cost is delay on first contact; the payoff is that a meaningful fraction of junk filters itself out before it ever reaches your content scanner.

The server makes its decision on a triplet: the sending IP address, the envelope sender (MAIL FROM), and the envelope recipient (RCPT TO). The first time a server sees a given triplet, it has no record of it, so it defers. When the same triplet comes back after the required delay, the server recognizes it and lets the message through, usually adding the triplet (or the IP) to an allowlist so future mail is not delayed.

The mechanism, step by step

1. A connection arrives. The receiving MTA forms the triplet (source IP, MAIL FROM, RCPT TO) from the SMTP envelope.
2. It looks the triplet up in its greylist database. If it has never seen this triplet, it records it with a timestamp and returns a temporary failure.
3. The reply is a 4xx code, conventionally 451 4.7.1 (and sometimes phrased as 450), meaning "try again later." Per RFC 5321, a 4yz reply is a transient negative completion: the command failed, the condition is temporary, and the client should retry.
4. A legitimate sender's MTA holds the message in its queue and retries after its normal backoff.
5. On the retry, if enough time has passed (the configured minimum delay, commonly a few minutes), the triplet is now "known" and the message is accepted. The server typically allowlists the triplet or the IP for a window so subsequent mail flows without delay.

# first contact: receiver greylists the new triplet
220 mx.example.com ESMTP
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
451 4.7.1 Greylisting in effect, please come back later

A few minutes later, the same IP, sender, and recipient return:

MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
250 2.0.0 Ok: queued

That is the whole dance: defer the stranger, accept the one who comes back.

Why this filters spam

The technique, introduced by Evan Harris in 2003, exploits a behavioral gap rather than message content. A correct MTA treats a 4xx as a transient error and retries, because RFC 5321 requires queueing and retry for temporary failures. A lot of bulk spam is sent by lightweight senders, botnet scripts, and fire-and-forget tools that do not maintain a retry queue at all. They send once into the 451, get told to come back, and never do. The message simply never arrives, with no content analysis required and no block list consulted.

It also raises the cost of dictionary and recipient-guessing attacks, because every new (IP, from, to) combination eats a deferral and a delay rather than getting an instant accept.

The trade-offs

Greylisting is not free, and the costs are real enough that many operators run it narrowly or not at all.

• Delay on first contact. The first message from any new sender is delayed by at least the minimum retry interval, and longer if the sender's retry schedule is sparse. For a password reset or a one-time login code, even a few minutes is a bad user experience. This is the single biggest reason greylisting has fallen out of favor for inbound mail that includes transactional traffic.
• Sender retry intervals vary. Some senders retry in 60 seconds, some in 15 minutes, some on a longer schedule, so the delay you impose is not under your control.
• Misbehaving-but-legitimate senders. A small number of legitimate senders retry from a different IP each time (large rotating pools), so the triplet never matches on retry and the mail keeps getting deferred. Allowlisting on the /24 instead of the exact IP, or maintaining a known-good-sender allowlist, mitigates this.
• Operational state. You now run a database of triplets with expiry and cleanup, and a tuning surface (minimum delay, allowlist lifetime, triplet-versus-IP matching).

A common compromise is to allowlist well-known, high-volume, well-behaved senders so their mail is never greylisted, and to greylist only sources that are not already trusted or that score poorly on other signals.

From the sender's side

If you operate a sending server and you see 451 4.7.1 greylisting defers, the correct response is to do nothing special: your MTA should already queue and retry, and the message will go through on the next attempt. Greylisting defers are normal and expected, not an error to "fix." What you must not do is treat a 4xx greylist as a hard failure and stop, or retry instantly in a tight loop instead of respecting normal backoff. Confirm your queue is retrying on a sane schedule and that your IP, envelope sender, and HELO are stable across retries so the triplet matches.

Saying it out loud

In an interview: "Greylisting temporarily rejects the first delivery from an unknown sender with a 4xx, usually 451 4.7.1, and accepts it on retry. The key is the triplet: source IP, envelope MAIL FROM, and envelope RCPT TO. New triplet, defer and record it; same triplet back after the minimum delay, accept and allowlist. It works because RFC 5321 makes compliant MTAs queue and retry transient failures, while a lot of spam software sends once and never returns, so the junk filters itself out with no content scan. The trade-off is delay on first contact, which is why I would never greylist transactional streams like login codes, and why I allowlist trusted high-volume senders and match on the subnet rather than the exact IP to avoid deferring senders with rotating pools forever." That answer shows you understand both the mechanism and why you would deploy it carefully rather than everywhere.