Greylisting
Greylisting is a filtering technique where a receiving server temporarily refuses a message from an unfamiliar sender and waits to see whether it is tried again. A real mail server retries; much bulk software does not. The message is accepted on the second attempt, so the only cost to a legitimate sender is a delay of minutes, and the sender is usually remembered afterwards.
At a glance
- Category
- Delivery
- Mechanism
- A temporary 4xx refusal on first contact
- Keyed on
- The sending address, the envelope sender and the recipient
- Cost to senders
- A delay on the first message, then nothing
- Described in
- RFC 6647, on email greylisting
How it works
When a message arrives from a combination the receiving server has not seen before, it answers with a temporary failure rather than accepting or rejecting. A properly behaved sending server treats that as a deferral and tries again after a delay. On the retry the receiver recognises the combination, accepts the message, and usually adds the sender to a list it will not greylist again. Software that fires once and discards failures never comes back, which is the entire point.
Why it matters
For a sender, greylisting is the most common innocent explanation for a message that was not delivered instantly. Support tickets about a password reset arriving twenty minutes late are frequently this and nothing else. It also explains why the first message to a new corporate domain is slow while every later one is prompt, and why a retry policy that gives up after a single attempt is a genuine deliverability bug rather than an efficiency choice. It is also a reminder that a missing delivery event in the first few minutes is usually patience rather than failure.
Example
A customer at a company running its own mail server requests a password reset. The first delivery attempt is refused with a temporary code and no delivery event appears. The sending service retries a few minutes later, the receiving server accepts it, and the message arrives. Every subsequent message to that company is delivered on the first attempt, because the sending address is now known to the receiver.
Common mistakes
- 01Treating a temporary refusal as a permanent one and suppressing the address, which removes a perfectly valid customer.
- 02Retrying immediately and repeatedly, when most greylisting implementations require a minimum wait before they will accept.
- 03Promising instant delivery for time-sensitive codes without allowing for a first-contact delay outside your control.
- 04Reporting the first temporary refusal to a customer as a failure, when the retry that follows it usually succeeds without anyone doing anything.
Related terms
Frequently asked questions
How long does a greylist delay last?
Typically a few minutes, because the receiver enforces a minimum wait before it will accept the retry. The exact interval is set by whoever runs the receiving server and is not advertised.
Can I avoid being greylisted?
Not directly, since the decision belongs to the receiver. Sending consistently from stable addresses helps, because most implementations stop greylisting a sender once it has proved itself.
Is greylisting still common?
It is much less common at the large consumer mailbox providers and still widely used on self-hosted and smaller corporate servers. That is why it tends to show up as a complaint from business customers rather than consumer ones.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.