Exim handles mail for every account on a cPanel server. WHM exposes its configuration as a form under Service Configuration → Exim Configuration Manager, and most of it can be left alone.
The settings that matter are the ones that decide whether other servers accept what yours sends.
Sender verification
This refuses mail claiming to come from an address that does not exist. It is on by default and should stay on.
It occasionally causes a real problem: an application sending from a made-up address like noreply@ that was never created as a mailbox. The correct fix is to create the address, not to disable verification for the whole server.
Rate limits
The per-account hourly maximum is what stands between one compromised account and your server's reputation.
A compromised account sends continuously until something stops it. Without a limit, the something is a blocklist, and the blocklist applies to every customer on that address, not just the compromised one.
Set a number that ordinary use never reaches. A business account sending a few dozen messages a day is nowhere near a limit of a few hundred an hour, and the limit only ever fires when something is wrong.
Genuine bulk sending should not go through your mail server at all. For that, see sending a newsletter properly.
Which address mail leaves from
On a server with several addresses, Exim can be told to send from the account's own address or from the server's main one.
The choice only matters because of what the domain's SPF record says. If SPF authorises one address and mail arrives from another, receiving servers treat it as forged, which produces the situation where mail was configured correctly, sends without error, and is rejected everywhere.
Pick one behaviour, then make the DNS match it. Understanding SPF, DKIM and DMARC goes over writing the record.
Reverse DNS
Not an Exim setting, but the thing most likely to be wrong.
The sending address must have a reverse DNS entry resolving to the server's hostname, and that hostname should resolve back to the address. Many receiving servers reject mail from addresses without matching reverse DNS before looking at anything else.
Reverse DNS is set by whoever controls the IP address rather than in your zone file: understanding PTR and reverse DNS deals with it, and the email deliverability tool checks the whole set from one screen.
Reading the log
Every message's outcome is recorded. This is where mail questions are actually answered.
tail -f /var/log/exim_mainlog grep '[email protected]' /var/log/exim_mainlog | tail -50 exim -bp | tail -20
What you are looking for is which of two very different situations you have. Rejected here. The log shows a refusal with a reason, and the fix is on your server. Accepted and delivered. The log shows success, and the message was discarded at the other end, which is a reputation problem instead of a configuration one.
To the person reporting it, both look like "my email did not arrive". They have nothing else in common.
A queue that is growing
exim -bp lists queued mail. A queue of a few messages is normal; thousands means something is wrong.
Look at who is sending. If one account is responsible for nearly all of it, that account is compromised, and the correct first action is to suspend it, not to clear the queue, which only removes the evidence while the sending continues. Suspending accounts goes over doing it quickly and reversibly.
What not to change
The Exim Configuration Manager includes an advanced editor for the raw configuration. It is there for genuine need, and a mistake in it stops mail for the whole server.
Everything in the form view is reversible and documented. Reach for the raw editor only when the form cannot express what you need, and take a copy of the working configuration first.
A delayed message with two log entries a few minutes apart is usually not a fault at all. Greylisting in WHM: What It Does and When to Turn It Off goes into recognising it.
Confirm what the server is telling the world
Before changing any setting, look at how the mail server identifies itself. A mismatch here causes rejections that no configuration screen explains.
exim -bP primary_hostname hostname -f dig -x $(curl -s ifconfig.me) +short
All three should agree, and the reverse lookup is the one that is usually wrong. Large providers check that the sending address resolves back to the name the server announces, and reject when it does not.
Reverse DNS is set by whoever controls the address rather than in your zone, which is why it is the item most often left undone. Understanding PTR and reverse DNS explains arranging it.
Reading the queue properly
exim -bp | wc -l
exim -bp | awk '{print $4}' | sort | uniq -c | sort -rn | head
exim -bpc
The count alone says little. Grouping by sender answers the question that matters: is this a broad delay or one account producing everything?
One account responsible for most of the queue is a compromise, and the response is suspension before investigation. The sending is doing damage to every other customer on the address while you look.
To inspect why a specific message is stuck:
exim -Mvl MESSAGE-ID # the log for that message exim -Mvh MESSAGE-ID # its headers
Clearing the queue is not a fix and it removes the evidence. There is more on the order in what to do when an email account is compromised.
Signing outgoing mail
Sender policy says which servers may send for a domain. A signature proves the message was not altered, and it is what survives forwarding, which sender policy does not.
That distinction matters: a message forwarded by a mailing list or an alias fails the policy check at its final destination and passes the signature check. A domain with only the first is delivering unreliably in exactly the situations people notice.
Enable signing per domain and publish the corresponding record, then verify from outside rather than from the panel. Reading email headers goes over checking that a real recipient saw both checks pass.
Where the limits should sit
Three numbers are worth setting deliberately instead of leaving at their defaults.
Per-account hourly maximum. The cap on what a compromised account can do before anyone notices. Set it above ordinary use and far below what a spam run needs.
Maximum message size. Too small and legitimate attachments bounce; too large and one message can occupy the queue.
Retry duration. How long a temporary failure is retried before giving up. The default is usually several days, which is right, shortening it turns a receiving server's brief outage into permanently lost mail.
The email deliverability tool checks the records these settings depend on.