Greylisting is one of the cheapest anti-spam measures there is, and one of the most complained about. Both facts come from the same mechanism.
What it does
When a message arrives from a combination of sender, recipient and address the server has not seen before, it is refused with a temporary error rather than accepted.
A legitimate mail server treats a temporary error as an instruction to try again shortly, and does. On the retry, the combination is recognised and the message is accepted, and remembered, so future mail from that sender arrives immediately.
Most bulk spam software does not retry. It has a list to get through and moves on.
The result is a large reduction in unwanted mail with no content inspection at all, which is why it costs almost nothing to run.
Where it lives
In WHM, Email → Greylisting. It can be enabled server-wide and disabled per domain, which matters; the per-domain control is what makes it workable when one customer cannot tolerate the delay.
What it costs
The first message from any new correspondent is delayed by the retry interval. Some servers retry within a minute; some wait considerably longer.
The problem is which messages that affects. Ordinary correspondence arriving four minutes later is unnoticeable. What people notice is:
Password resets. The user is sitting on the page waiting.
Confirmation and verification codes. Often expire before they arrive.
Two-factor codes by email. Frequently unusable by the time they land.
Order confirmations. The customer assumes the order failed and orders again.
These are precisely the messages someone is actively waiting for, which is why greylisting generates support tickets out of proportion to how often it actually delays anything.
The right response is usually the bypass list
Disabling greylisting entirely gives up a real benefit because of a handful of senders.
The bypass list accepts addresses and ranges that skip greylisting completely. Add the services whose mail is time-critical: your payment provider, the services your customers' sites send through, any transactional mail platform in use.
That keeps the delay for unknown senders, which is where the benefit is, and removes it where it hurts.
cPanel also maintains common trusted senders, which handles the largest providers without your intervention.
When to turn it off for a domain
Turn it off when the mail that domain receives is predominantly automated and time-sensitive. A shop receiving gateway notifications, an application receiving webhooks by mail, a support address behind a ticketing system that reacts badly to delays.
Leave it on for ordinary business mail, where a few minutes on a first message from a stranger is not a cost anyone experiences.
Recognising it in the log
grep -i greylist /var/log/exim_mainlog | tail -20
A greylisted message appears as a temporary rejection with a reason. Two entries for the same message a few minutes apart, the second successful, is greylisting working exactly as designed.
This is worth checking before investigating a delayed message any further. It distinguishes an intentional delay from an actual delivery problem, which look identical to the person waiting. Understanding email bounces and delivery codes walks through reading the temporary code itself.
What it does not do
It examines no content, so it stops nothing from a sender that retries, which includes every targeted attempt and any spam sent through a real mail server.
It is one layer. Content filtering, sender authentication and rate limits are the others: configuring spam filters and Exim configuration and mail routing cover them.
And it does nothing about mail your server sends. That is a separate question of reputation and records. The email deliverability tool picks it up from there.
Measure the delay before deciding it is a problem
Complaints about delayed mail are frequently about this and occasionally about something else, and the log distinguishes them.
grep -i 'greylist' /var/log/exim_mainlog | tail -20 grep -ciE 'greylist' /var/log/exim_mainlog exim -bp | wc -l
What you want is the gap between the first refusal and the successful delivery for the same sender. A well behaved sender retries within minutes; a poorly configured one may wait an hour or not retry at all.
A queue that is long for other reasons produces the same complaint with a different cause, which is why reading the queue length alongside is worth the extra command.
The senders that never retry
The technique assumes a temporary refusal will be retried, and a specific category of sender does not.
Transactional systems that send one message and treat any refusal as failure are the usual case: a password reset, an order confirmation, a verification code from a service that expects immediate delivery.
grep -iE 'greylist' /var/log/exim_mainlog | awk '{print $NF}' | sort | uniq -c | sort -rn | head
Read which senders appear repeatedly without a matching delivery. Those are the ones to permit explicitly, and each one you find is a message somebody never received.
Permit rather than disable
The choice is presented as on or off and the useful setting is in between.
Adding the senders that matter to a bypass list keeps the benefit for everything else, which is where most of the value is. Disabling it entirely for the server removes the protection from every domain because one domain had a problem.
Where a customer insists, disabling it for that domain alone is the proportionate answer. Record why, since the setting will otherwise be found years later with nobody able to say whether it is still needed. The email deliverability tool covers the other checks that affect delivery.
Record the decision
Whatever you choose for a domain, write down the date, the reason and who asked. A setting like this is found years later by somebody who cannot tell whether it was a considered decision or an accident, and without a note the safe assumption is always to leave it alone. That is how a temporary exception becomes permanent. The note costs one line and it is the difference between a configuration somebody can review and one nobody dares to change.