Emails Delayed, Not Bounced? How Greylisting Works

A customer email lands three hours late. No bounce, no error in their inbox, nothing in spam — it just... shows up eventually. If you've chased this ghost before, you're probably looking at greylisting, not a broken mail server.

The Symptom

Someone emails a client from your domain. The client says it never arrived. You check — it did arrive, just two hours later than it was sent. Or a WooCommerce order confirmation reaches Gmail instantly but takes 20 minutes to hit a corporate Outlook inbox. There's no bounce-back, no NDR, no entry in the spam folder. The message is simply slow.

This is different from the mail problems we usually write about. It's not 550 rejected, not stuck in an Exim frozen queue, not blocked because port 25 is closed. The message goes out, gets a temporary "come back later" from the receiving server, and your server dutifully waits and retries — exactly as it's supposed to.

The Cause: Greylisting

Greylisting is a spam-filtering technique used by the receiving mail server, not something wrong on your end. When your server first tries to deliver, an unfamiliar greylisting-enabled server replies with a temporary rejection — usually SMTP code 450 or 451, with text like:

451 4.7.1 Greylisted, please try again in 00:05:00
450 4.2.0 <user@example.com>: Recipient address rejected: Greylisted, try again later

The logic behind it: spam-sending botnets almost never retry a failed delivery — they fire and move on to the next victim. Legitimate mail servers, per RFC 5321, are required to queue and retry. So a greylisting filter bets that anything willing to wait five, ten, or thirty minutes and try again is probably real. It's a low-effort, surprisingly effective spam filter, and a lot of corporate mail gateways (Barracuda, Proofpoint, Mimecast) and some smaller providers still use it. Gmail and Microsoft 365 rarely greylist outright, but their reputation-based throttling behaves similarly for unfamiliar senders.

First-time contact between your domain and a given recipient server is the most common trigger. Once your sending IP has delivered successfully a few times, most greylisting filters whitelist the pair and stop deferring you.

How to Confirm It's Greylisting

Don't guess — check the mail log. If you're on cPanel/WHM hosting:

1. In cPanel, go to Email > Track Delivery and search for the message by recipient or subject.
2. Look at the delivery events. A status of Deferred with a reason mentioning "greylist," "try again," or a 4xx code confirms it.
3. On the server itself (WHM root or SSH), grep the Exim log directly:

grep "recipient_id_string" /var/log/exim_mainlog
grep -i "greylist\|retry time not reached\|temporarily deferred" /var/log/exim_mainlog

You can also check what's currently sitting in the retry queue:

exim -bp | grep -i "<recipient-domain>"
mailq | head -50

If the message shows up as deferred with a 4xx response and later shows a successful 250 delivery on retry, that's a textbook greylisting cycle, not a configuration problem.

The Fix

1. Let it retry — most of the time, that's the fix

Exim's default retry schedule already handles greylisting fine. A deferred message typically clears on the second or third attempt, usually within 5–60 minutes. If the delay is under an hour and delivery eventually succeeds, there's nothing broken to fix — this is the filter working as intended.

2. Check your retry configuration isn't backing off too aggressively

In WHM, go to Exim Configuration Manager > Advanced Editor and confirm the retry rules haven't been stretched out (some hardened configs push the first retry to hours instead of minutes). For a typical setup, the default rule is close to:

* * F,2h,15m; G,16h,1h,1.5; F,4d,6h

That first block (F,2h,15m) means: for the first 2 hours, retry every 15 minutes. If your logs show much longer gaps than that, something's been customized — worth reverting to defaults unless you know why it was changed.

3. Fix your sender reputation so filters trust you faster

Greylisting filters (and the reputation systems behind Gmail/Outlook throttling) go easier on senders with clean, verifiable authentication. Confirm all three are in place and passing:

Missing or misaligned records don't cause greylisting directly, but they make every receiving filter — greylisting or otherwise — treat you with more suspicion, which often means longer or repeated deferrals instead of a quick one-time delay.

4. Set your PTR (reverse DNS) record

If you're sending from a VPS with its own dedicated IP, missing reverse DNS is one of the most common reasons greylisting delays feel worse than they should. Ask your host (open a ticket if you're on Getwebup VPS) to set a PTR record matching your sending hostname, e.g. mail.yourdomain.com. Verify it with:

dig -x YOUR.SERVER.IP.ADDRESS +short

A missing or mismatched PTR record won't stop mail delivery outright, but it removes one of the trust signals filters use to shorten or skip greylisting delays.

5. Move high-volume or time-sensitive mail off shared IP sending

Order confirmations, password resets, and booking notifications shouldn't be sitting in a greylist queue. For transactional email specifically, route it through a dedicated service like Amazon SES, SendGrid, or Postmark via SMTP or API, while keeping regular business email on your hosting account. These services maintain sending reputation at scale and are rarely greylisted the way a fresh domain or shared IP is.

Prevention

• Keep SPF, DKIM, and DMARC published and passing — check them after every DNS or hosting migration.
• Set a matching PTR record for any dedicated sending IP.
• Warm up new domains or IPs gradually — don't blast a large mailing list from a brand-new domain on day one.
• Route transactional email through a dedicated ESP once volume grows past a few hundred emails a day.
• Check Track Delivery periodically, not just when a customer complains — deferred-then-delivered patterns are easy to spot early.

None of this requires changing hosting providers or rebuilding your mail setup. Greylisting is a normal, working part of how spam filtering behaves on the modern internet — the goal isn't to eliminate it, it's to make sure your domain clears it in minutes instead of hours.