Two cPanel tools answer the two questions that come up whenever email is not behaving: where is mail for this domain supposed to go, and what happened to a specific message. Between them they resolve most email investigations without guessing.
Email Routing: local, remote, or automatic
Under Email, Email Routing decides whether this server believes it handles mail for a domain.
Local Mail Exchanger. This server delivers mail for the domain into mailboxes here.
Remote Mail Exchanger. Mail for the domain is handled elsewhere; this server sends it out rather than delivering locally.
Automatically Detect. cPanel decides based on the MX records, which usually works and occasionally does not.
The failure this setting causes
This is the reason the screen matters, and it catches almost everyone who moves mail to an external provider.
You change the MX records to point at the new provider. External mail arrives correctly. The outside world follows MX and delivers there.
But the server still believes it handles mail for the domain, so anything sent by a script on this server is delivered locally instead of going out. Contact form messages, order confirmations and password resets land in a mailbox nobody reads, or nowhere.
The client tests by emailing themselves from Gmail, it arrives, and everything looks correct. Three weeks later somebody notices no enquiries have come through.
Setting the domain to Remote Mail Exchanger fixes it. It is one setting and it is missed almost every time. There is more on the DNS half in understanding MX records.
Track Delivery: what happened to that message
Also under Email, Track Delivery shows the server's own record of recent messages: sender, recipient, time, and the outcome.
That outcome is the useful part. It distinguishes three situations that look identical from outside:
Delivered. The receiving server accepted it. If the recipient says it never arrived, it is in their spam folder or their own filters moved it, and that is a different conversation.
Deferred. Temporarily rejected and being retried. Usually the receiving end being busy or rate-limiting.
Failed. Rejected, with the receiving server's reason attached.
Reading a failure reason
The reason text comes from the receiving server and is usually specific.
Mailbox does not exist. A typo, or an address that was deleted while something still sends to it.
Over quota. The recipient's mailbox is full; theirs, not yours.
Rejected as spam, or a policy reason. Your authentication is failing or your sending address has a reputation problem. Check SPF, DKIM and DMARC first. Understanding SPF, DKIM and DMARC walks through publishing them.
Blocklisted. The sending address is listed. On shared hosting that is usually another account's compromised site rather than anything you did, and it is a support ticket.
Use it before assuming
The order that saves the most time: search Track Delivery for the recipient address before investigating anything else.
If the message shows as delivered, the problem is at the recipient's end and nothing on your server needs changing. If it is not there at all, the message was never sent, which points at the application rather than at mail.
That distinction alone resolves a large share of "my email is not working" reports.
When nothing appears in Track Delivery
The site is not sending. That is an application problem, not a mail one.
The usual cause is the application using the server's basic mail function in a way that fails silently, or a form that is not submitting at all. Configuring the application to send through authenticated SMTP resolves both the visibility and the deliverability. The email troubleshooting guide sets out the wider set.
What Track Delivery cannot see
It records what this server did with a message. Two situations therefore leave no trace at all, and both are commonly reported as "the tool shows nothing".
Mail that never reached this server. If the domain's MX records point elsewhere, incoming mail was delivered to that provider and this server was never involved. Check the records before looking any further:
dig example.com MX +short
Mail sent by an application through an external service. A site sending through a relay bypasses the server's mail system entirely, so those messages appear in the relay's log and nowhere here. Sending application email through a relay service goes into reading that log instead.
Establishing which of the three paths a message took is the first step in any mail investigation, and it is the step that is usually skipped.
Delivered is not the same as read
A green result means the receiving server accepted the message. What happened afterwards is outside this server's knowledge entirely.
The receiving system may have filed it as spam, applied a rule that moved it, or discarded it silently. None of that produces a bounce, so nothing here changes.
That distinction is the single most useful thing this tool provides: it separates "we failed to deliver" from "we delivered and it was not seen", which are different problems with different fixes. The second is a reputation and authentication question. See SPF, DKIM and DMARC.
Checking the same thing from the command line
The panel view is convenient and limited to recent history. For anything older, or for a pattern instead of one message:
grep '[email protected]' /var/log/exim_mainlog | tail -50 exim -bp | wc -l exim -bp | awk '{print $4}' | sort | uniq -c | sort -rn | head
The last command groups the queue by sender, which answers a question the panel cannot: if one account is responsible for nearly all queued mail, that account is compromised and the response is immediate suspension rather than investigation. What to do when an email account is compromised deals with the order.
Routing on a server hosting many domains
The routing setting is per domain, and on an account with addon domains each one has its own.
A common state: the main domain correctly set to remote, an addon domain added later left on automatic, and mail from the site to that addon domain quietly landing in a local mailbox nobody opens.
Check every domain the account serves in place of the one being reported. The symptom appears on one domain and the cause is usually a setting nobody revisited when the domain was added. Splitting DNS between website and email providers goes over the arrangement this setting exists for.