What is greylisting and how does it affect queues?

You send an email to someone for the first time. Their server says "not yet" and hangs up. Five minutes later, your MTA tries again and this time it goes through. That's greylisting.

Greylisting is an anti-spam technique where a recipient server temporarily rejects mail from an unfamiliar sender. The server responds with a 4xx code (usually 451), which means "try again later." It also records the combination of sending IP, from address, and recipient address. If the same sender retries after a short delay, they pass. Most spam bots don't bother retrying, which is exactly the point.

The logic, step by step:

1. Your server sends a message to a new recipient for the first time.
2. Their server returns a 451 and records your sending details.
3. Your MTA queues the message and schedules a retry (typically after 5 to 15 minutes).
4. On the retry, their server recognises your details and accepts the message.
5. Future emails to that same recipient skip the greylist entirely.

It's worth noting that a 4xx is fundamentally different from a 5xx. A 4xx is a soft, temporary rejection. Your MTA holds the message and retries. A 5xx is a hard rejection and the message bounces permanently. Greylisting always uses 4xx codes, so nothing is lost, just delayed.

What this means for your queues

Now the first time you email someone on a greylisting server, that message will sit in your queue for the greylist window. That window is usually 5 to 15 minutes, but some servers hold out for up to an hour. Delivery to new recipients takes longer than usual, and the delay is invisible to you unless you're reading queue logs or delivery reports.

And once a sender and recipient pair is established, greylisting has no effect. Subsequent messages to that same address go through without any hold. So for senders with healthy, engaged lists, the impact shrinks over time as your pairs get recognised.

For ESPs sending to large lists at volume, the initial wave of greylisting deferrals can create a temporary spike in queue depth. A good backoff algorithm handles this automatically, spacing out retries without hammering the receiving server. If your retry policy has a minimum backoff of at least 5 minutes, you're likely already covered without any extra configuration on your end.

From your perspective as a sender

Greylisting is mostly invisible when your MTA is set up correctly. You don't need to do anything special. The delay is real but short, and it resolves itself on retry. If you're seeing consistent multi-hour delays to specific domains, greylisting alone probably isn't the cause. That's more likely a reputation issue or rate limiting worth investigating separately.

If you're curious whether greylisting is behind a specific delay, check your sending logs for repeated 451 codes to the same recipient domain, with successful delivery on the second attempt. That's the signature pattern.

Not sure how to read your delivery headers or diagnose what's causing a delay? Our free Email Header Analyzer can help you spot where the hold-up happened.