Greylisting is one of the oldest anti-spam techniques still in wide use, and the reason a message that eventually arrived perfectly well shows up in your log as a failure first. It is described in RFC 6647, which sums it up in a sentence:
This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.
How does greylisting work?
The receiver says "not now" and waits to see whether you mean it.
When a server it does not recognise tries to deliver, a greylisting receiver returns a temporary failure rather than accepting or rejecting the message. A properly built mail server treats that as an instruction to try again later, and does. On the retry the receiver recognises the attempt and accepts the message.
What the receiver remembers is usually a tuple, and the standard recommends a specific one:
Implement greylisting based on a tuple consisting of (IP address, RFC5321.MailFrom, and the first RFC5321.RcptTo).
with a companion recommendation that once a sender has proved itself, it stops being greylisted:
After a successful retry, allow all further [SMTP] traffic from the IP address in that tuple regardless of envelope information.
So the delay applies to the first message from a given sender to a given recipient, not to every message forever.
Why does this stop spam at all?
Because the cheapest way to send bulk mail is to not retry.
The standard puts the benefit in one line: "spamware generally does not retry and is therefore less likely to succeed, absent a record of a previous delivery attempts." Mass-mailing software optimises for volume, and holding state so it can come back to each rejected recipient later costs exactly the thing it is trying to save.
That also explains why greylisting has faded rather than failed. The technique works against software that behaves in a specific way, and once enough of that software started retrying, the ratio of spam blocked to legitimate mail delayed got worse. It is still deployed, mostly on smaller and self-hosted receivers, which is why you tend to meet it on a minority of your recipients rather than across a campaign.
How long is the delay?
Long enough to matter for anything time critical.
The recommended window is wide:
The default range SHOULD be from one minute to 24 hours.
The lower bound is the receiver's, and the actual wait is your own sending infrastructure's retry schedule, which the standard notes can be slow: "Some popular MTAs do not retry failed delivery attempts for an hour or more, which can cause expensive delays when delivery of mail is time critical."
For a password reset or a one-time passcode, an hour is a failed message even though it was delivered. This is the real cost of greylisting and the reason it is unusual on large mailbox providers, who cannot impose it on their own users' expectations.
How do I tell greylisting from a real failure?
By the status code class, and by what happens next.
A greylisting rejection is a 4yz reply, which means temporary. RFC 6647 notes that receivers have only two sensible choices, 421 or 450, and that the accompanying text is up to them, so you cannot rely on the wording to name the mechanism.
| What you see | What it means |
|---|---|
A 4yz deferral, then delivery on a later attempt | Greylisting, or ordinary throttling. Nothing to do |
A 4yz deferral repeating until the message expires | A block dressed as a deferral, worth investigating |
A 5yz rejection | A hard bounce. Not greylisting at all |
The middle row is the one to watch. A receiver that defers you indefinitely is not asking you to retry, it is refusing you politely, and the cause is usually reputation or a blocklist rather than greylisting. What are deferred emails covers reading the pattern, and what are bounced emails covers the permanent case.
Is there anything I should do about it?
On the sending side, no, and that is worth saying plainly because it is a common place to waste effort.
You cannot ask to be exempted from a stranger's greylisting, and there is no record to publish that avoids it. What you can do is make sure your mail is coming from a sender the receiver will stop greylisting quickly, which is the same thing as sending consistently from stable infrastructure rather than from addresses and IPs that change. The standard's own advice to receivers assumes this: it recommends deleting database entries for senders "that have generated no recent traffic", with a default of at least a week, so an intermittent sender gets greylisted again and again while a steady one does not.
If you run a receiver rather than a sender, the same document has one recommendation that is easy to get wrong: do not greylist your own authenticated submissions.
Greylisting SHOULD NOT be applied by an ADMD's submission service (see [SUBMISSION]) for authenticated client hosts.