Greylisting is the cheapest spam filter you already own. cPanel ships cPGreyList built in, it adds zero per-message cost, and on a shared box it typically rejects a large share of botnet spam before SpamAssassin ever loads. The catch is that it works by delaying the first message from any unknown sender, so a sloppy rollout generates a wave of "my email is slow" and "I never got the receipt" tickets.
This guide is for operators running mail on cPanel & WHM who want greylisting on without the support fallout. It covers how the triplet logic works, the WHM settings that matter, the auto-trust lists that prevent most false delays, and a decision tree for when a specific sender's mail keeps getting deferred.
How greylisting decides
cPGreyList keys on a triplet: the sending server's IP, the envelope sender, and the
envelope recipient. The first time it sees a given triplet, Exim returns a temporary
451 deferral instead of accepting the message:
451 4.7.1 Greylisted, please try again later
A real mail server treats 451 as "try again" and re-queues the message. A botnet or a
spam cannon almost never retries — it fires once and moves on. So when the legitimate server
reconnects a few minutes later, the triplet is now known and the message sails through. From
then on, that sender→recipient pair is whitelisted for the life of the record, so there's no
recurring delay.
The delay only ever hits the first message of a new conversation. Every reply after that is instant.
Enable cPGreyList in WHM
- WHM → Email → Greylisting.
- Toggle the master switch to Enabled.
- Leave Apply greylisting to new accounts automatically on if you want every new domain covered by default. Existing accounts are governed by the per-domain opt-in below.
That's the whole activation. The tuning is where you avoid tickets.
The settings that matter
Three timers control the deferral window. cPanel's defaults are conservative — a 5-minute initial deferral is the well-known starting point — but it's worth understanding each one before you touch them.
Initial Deferral Time
How long an unknown triplet is blocked before a retry is accepted. The default 5 minutes is the sweet spot: long enough that single-shot spammers give up, short enough that a healthy sender's first retry clears it. Pushing this to 15–30 minutes catches marginally more spam and noticeably annoys users waiting on a password reset. Leave it at 5 unless you have a spam problem that SpamAssassin and Imunify360's email filter can't dent.
Resend (must-retry) acceptance period
The window after the initial deferral during which a retry is accepted. Set this generously — a few hours at minimum. Some legitimate but slow queues back off aggressively and won't retry for an hour or more; if your acceptance window is too short, their retry lands after the triplet has been forgotten and the clock starts over, so the message bounces around for hours. A wide acceptance window costs nothing and prevents this.
Record Expiration Time
How long a known-good triplet stays whitelisted with no traffic. Keep this long — days, not hours. The longer a proven sender stays trusted, the fewer first-message delays your users ever see. The only reason to shorten it is to reclaim a small amount of database size, which is almost never worth the extra deferrals.
Auto-trust lists: where false delays die
cPGreyList ships two mechanisms that exempt senders from the deferral entirely. Configure both before you announce greylisting to clients.
Common Mail Providers
Under Greylisting → Trusted Hosts, cPanel maintains an auto-updating list of the big mailbox providers — Gmail, Microsoft 365/Outlook, Yahoo, Apple, and so on. Their IP ranges are exempt, so mail from those providers is never deferred. Keep this list enabled and auto-updating; it's the single biggest reducer of "my Gmail is delayed" complaints. WHM emails you when the provider list changes so you can confirm the update.
Bypass greylisting for hosts with valid SPF records
Also under Greylisting, the Bypass Greylisting for Hosts with Valid SPF Records toggle accepts mail immediately from any sender whose IP passes the domain's published SPF record. The logic: a sender disciplined enough to publish SPF is almost certainly not a botnet. Turn this on. It clears a large slice of legitimate business and transactional mail without you maintaining a single whitelist entry.
Trusted Hosts
For the long tail — a payment gateway, a monitoring system, a partner's mail server that neither publishes SPF nor retries properly — add its IP under Trusted Hosts. You can paste multiple IPs or CIDR ranges at once. This is the manual escape hatch for senders the two automatic mechanisms miss.
Per-domain control
Greylisting is opt-in or opt-out per domain, and end users can manage it themselves. In cPanel, a user opens Email → Configure Greylisting and toggles it for any domain they own. Use this when a single client insists on zero inbound delay — disable it for their domain rather than weakening the policy server-wide.
Decision tree: "this sender keeps getting deferred"
When a specific sender's mail is stuck, work down this list:
-
Is it actually greylisting? Grep the Exim log for the deferral:
grep -i greylist /var/log/exim_mainlog | tail -50No greylisting lines means the delay is elsewhere — check the Exim queue for frozen or stuck messages instead.
-
Does the sender retry at all? Some transactional systems (cheap notification APIs, misconfigured CRMs, certain payment webhooks-to-email bridges) send once and never retry. These will never clear greylisting on their own. Add their IP to Trusted Hosts.
-
Does the sender publish SPF? If yes and mail is still deferred, confirm Bypass Greylisting for Hosts with Valid SPF Records is enabled. If their SPF is broken, that's their problem to fix — but trust the IP in the meantime.
-
Is it a big provider that slipped through? Confirm the Common Mail Providers list is enabled and current. If a provider rotated into a new IP range that isn't listed yet, add the range to Trusted Hosts until the list updates.
-
Still stuck? Disable greylisting for that one recipient domain via per-domain control.
Watch the first 48 hours
After enabling, tail the log and watch the deferral-to-pass ratio. A healthy server defers a lot of triplets and passes the legitimate ones within minutes:
grep -ci greylist /var/log/exim_mainlog
A steadily climbing count with few user complaints is greylisting doing its job. A spike in "never received" tickets clustered on one sender points you straight back to the decision tree above. If your outbound side is also under pressure, pair this with Exim outbound throttling so a compromised account can't undo the reputation greylisting protects.