An email leaves your server, doesn't bounce, doesn't land in spam — it just... isn't there yet. Ten minutes later it shows up in the recipient's inbox like nothing happened. If that's your pattern, you're probably not dealing with a deliverability problem at all. You're dealing with greylisting, and it's actually a good sign in a strange way: it means the receiving server doesn't trust you yet, not that it's blocking you.
Symptom: The Mail Isn't Lost, It's Just Late
The telltale signs of greylisting look different from a real delivery failure:
- The delay is consistent — usually 5 to 30 minutes, sometimes up to an hour, then the message arrives normally.
- It happens most on the first email to a new recipient, or the first email after a long gap, and rarely repeats for that same sender-recipient pair afterward.
- There's no bounce-back (NDR) in your inbox — because nothing failed. A temporary defer isn't a rejection.
- Your mail log on the server shows the message being retried, not dropped.
Check your Exim mail queue on the sending side to confirm the message is sitting in a retry state rather than stuck or bounced:
exim -bp | head -30
mailqIf you see the message with a "frozen" or repeated delivery attempt status and it eventually clears, that's consistent with a receiving server issuing a temporary 4xx deferral.
Cause: What Greylisting Actually Does
Greylisting is an anti-spam technique used by many receiving mail servers (Gmail's enterprise tier, Office 365 tenants with strict policies, and a lot of corporate mail gateways use variants of it). The logic is simple:
When mail arrives from a sender/IP/recipient combination the server hasn't seen before, it temporarily rejects the message with a soft error like 451 4.7.1 Please try again later instead of accepting it outright.
Legitimate mail servers are built to retry on a temporary failure — that's standard SMTP behavior (RFC 5321). Most spam-sending software doesn't bother retrying; it fires once and moves to the next target on its list. So greylisting filters out a chunk of spam for free, at the cost of delaying the first legitimate message from any new source.
Once your sending IP successfully retries and delivers, the receiving server usually whitelists that IP/sender/recipient triplet for some period (often 24 hours to several weeks), so subsequent mail goes through immediately.
A few things make greylisting delays worse than the typical 5-15 minutes:
| Factor | Effect |
|---|---|
| New or recently-changed sending IP | Every recipient sees you as "unknown" again, so delays repeat more often |
| Multiple outbound MTAs / load-balanced mail servers | Retries can come from a different IP than the original attempt, resetting the greylist timer |
| Low mail volume overall | You never build enough reputation for receivers to stop greylisting you |
| Long retry intervals in your MTA config | Exim's default retry schedule can wait well past 15 minutes before the second attempt |
Fix: Confirm It, Don't Panic-Fix DNS
The instinct when email "doesn't arrive" is to start rewriting SPF/DKIM/DMARC records. Don't — if this really is greylisting, your authentication is fine, and unnecessary DNS churn on a mail domain can cause its own delivery problems for a few days while it propagates.
Step 1 — Confirm the defer in your mail log. On wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel/Exim servers:
grep "recipient_id" /var/log/exim_mainlog | tail -50
exiqgrep -iLook for a line referencing a temporary error (4xx) from the receiving server, often literally containing "greylist" or "graylist" in the deferred SMTP response text.
Step 2 — Let it retry. If the queue is healthy and the message is retrying, the correct fix is usually to just wait. Exim's default retry rule tries again within 15 minutes for a fresh temporary error, then backs off.
Step 3 — If it's stuck for hours, force a retry manually instead of waiting on the schedule:
# Find the message ID from the queue
exim -bp
# Force immediate delivery attempt for one message
exim -M <message-id>
# Or force-retry everything in the queue
exim -qffStep 4 — Check for split delivery paths. If you're behind Cloudflare, a smart-host, or multiple outbound mail servers (common on VPS setups with a separate mail relay), verify that retries actually originate from the same IP as the first attempt:
exim -bp | grep -A2 recipient
tcpdump -i any port 25 -nIf retries are coming from a different IP each time, the receiving server's greylist database never sees a matching second attempt, so it keeps deferring indefinitely. That's a routing problem worth fixing on your end — pin outbound mail to one consistent IP.
Prevention: Stop Fighting the Same Delay Every Time
You can't (and shouldn't try to) disable greylisting on someone else's mail server — it's their policy. But you can reduce how often you trip it:
- Keep a stable outbound IP. Don't rotate sending IPs across multiple servers for the same domain unless you have to. Consistency is what earns you the whitelist faster.
- Warm up new IPs gradually. If you just moved to a new VPS or changed your mail relay, expect greylisting to hit harder for the first couple of weeks until your IP builds a reputation with common receivers.
- Set a sane PTR record. A missing or mismatched reverse DNS record makes some servers greylist (or reject outright) more aggressively, since it's a common spam signal. Confirm yours resolves cleanly:
dig -x YOUR_SERVER_IP +short- Don't disable retry logic in your MTA. Some overly-aggressive queue-cleanup scripts or third-party "send fast" plugins skip retries on soft failures — that turns a 15-minute greylist delay into a permanently lost email. Leave Exim's default retry configuration alone unless you know exactly why you're changing it.
- Tell time-sensitive senders to expect it once. If your app sends password resets or invoices to brand-new recipient domains, a one-time 15-30 minute delay on the very first contact is normal and not something to "fix" with a workaround.
Frequently Asked Questions
How is greylisting different from my email going to spam?
Spam filtering evaluates content, reputation, and authentication and then delivers (to inbox or junk) or rejects. Greylisting happens before any of that — it's a temporary "come back later" issued purely because the sender/IP combination is unrecognized. The email isn't judged as spam; it just hasn't proven it can retry yet.
Why did it only happen once and never again to the same address?
Once your server successfully retries and delivers, most greylisting implementations whitelist that sending IP (or the IP + envelope sender + recipient triplet) for a period ranging from a day to several weeks. Mail to that same recipient after that point skips the delay.
Can I ask the recipient's mail admin to whitelist me?
Yes, and it's the fastest permanent fix if you email a specific organization often — most mail admins can manually whitelist your domain or IP in their spam gateway (Proofpoint, Mimecast, Barracuda, etc.) so greylisting never applies to your mail again.
Does greylisting affect all recipients, or just some?
Only receivers that have greylisting enabled will do this — it's a policy choice on the receiving mail server, not a universal SMTP behavior. That's why you might see delays to one company's domain but never to Gmail or Yahoo personal accounts, which generally don't greylist consumer inboxes.
Should I add anything to SPF or DKIM to avoid greylisting?
No — greylisting is independent of SPF/DKIM/DMARC. Those records affect whether a message is trusted and authenticated once it's actually evaluated; greylisting happens at the initial connection stage before content or headers are even inspected. Solid SPF/DKIM/DMARC helps overall deliverability, but it won't skip the greylist delay.
