Emails Not Sending? A cPanel & Exim Troubleshooting Guide
An invoice sits unsent. A password reset never arrives. A growing mail queue creates uncertainty across the business. The fastest route to recovery is to follow one message through the system and fix the point where it stops.
1. Define what “not sending” means
Email passes through several separate stages: the application or mail client submits it, the sending server accepts it, a delivery attempt reaches the destination, and the recipient system decides where to place it. A Sent folder confirms a client-side action; it does not prove inbox delivery.
Start with one recent example. Record the sender, recipient, approximate time and timezone, application used, full error or bounce text, and any available message identifier. Avoid repeated resend attempts while investigating: they can create duplicates and obscure the original timeline.
Scope the incident. Does it affect one mailbox, one recipient domain, website forms only, or every account? A single failing desktop client points to different checks from a server-wide queue increase.
2. Check submission before investigating delivery
If the mail client reports a connection, certificate or authentication error, first verify the hostname, encryption method, port and username against the hosting provider’s supplied settings. Check whether outgoing mail is suspended or held, and whether account limits have been reached. Never bypass a certificate warning as a permanent fix.
Send one controlled message from webmail and another from the affected application to a mailbox you control. If webmail works while a website form fails, inspect the application’s SMTP configuration and its own error log. A successful form submission screen can appear even when its mail integration fails.
If no local mail record exists, confirm which server the application actually uses. An external SMTP provider’s messages will need tracing at that provider.
3. Trace the message in cPanel and WHM
In cPanel → Email → Track Delivery, search for the affected recipient and inspect the result details. Administrators can use WHM → Email → Mail Delivery Reports for broader investigation. Match the report to the exact test, rather than assuming the most recent entry belongs to it.
Interpret the delivery stage carefully:
- Deferred: delivery has been postponed. Read the destination’s response and determine what must change before a retry can succeed.
- Failed or rejected: capture the complete SMTP response. The enhanced status code and accompanying explanation matter more than the status label alone.
- Remote server accepted: investigate the recipient’s spam folder, quarantine, filtering rules or downstream forwarding. Acceptance does not guarantee inbox placement.
Track Delivery depends on stored Exim statistics. An empty report is not conclusive proof that no message was sent; reporting availability, retention and third-party mail processing can affect results. Ask the server administrator to verify the underlying logs when the report and observed behavior disagree.
4. Inspect the queue without destroying the evidence
In WHM → Email → Mail Queue Manager, filter by the sender or recipient and inspect a representative queued message. Compare its age and last delivery error with other affected messages. Queue size alone is a poor diagnosis: ten old messages may indicate a persistent destination problem, while a brief increase during legitimate traffic may clear normally.
Look for patterns. One destination suggests a remote policy, routing or connectivity issue. Many unrelated destinations suggest a shared dependency such as outbound connectivity, DNS resolution, a relay problem or local resource exhaustion. Unexpected senders and a sudden burst of traffic warrant an abuse investigation.
Do not delete the entire queue to make the number look healthy. Deletion discards pending messages and does not repair the cause. Before retrying or removing anything, establish ownership, legitimacy and the intended recovery action.
5. Use read-only Exim checks when administrator access is available
The following examples are for authorized server administrators. They inspect the queue and a specific log trail without forcing delivery or deleting mail. Replace MESSAGE_ID with the Exim queue identifier from your own report; it is not necessarily the Message-ID header shown in a mail client.
# Count queued messages
exim -bpc
# List the queue
exim -bp
# Find entries for one Exim queue ID in the current main log
rg -F -- 'MESSAGE_ID' /var/log/exim_mainlog
# Inspect that queued message's headers and message log
exim -Mvh MESSAGE_ID
exim -Mvl MESSAGE_IDIf rg is unavailable, use grep -F -- 'MESSAGE_ID' /var/log/exim_mainlog. Older events may be in rotated logs. A message may already have left the queue even though its historical log entries remain. Headers and logs can contain personal information; redact addresses, identifiers and authentication details before sharing them outside the support team.
6. Match the error to the right correction
Temporary remote deferrals
A destination may defer traffic because of rate controls, temporary service trouble or reputation checks. Read its exact response and follow its published guidance. Repeated forced retries can add load without improving delivery. Resolve the cause and allow the normal retry process, or make one controlled attempt when appropriate.
Permanent recipient or policy errors
Confirm the destination address and use the bounce explanation to separate an invalid mailbox from a policy rejection. For authentication or reverse-DNS errors, inspect the actual sending IP, relay and domain identity. Our SPF, DKIM, DMARC and PTR guide explains that part of the investigation. Change records only at the authoritative DNS provider and avoid unrelated edits.
Local routing and storage problems
After a migration, verify whether mail should be delivered locally or to an external provider. Review the domain’s routing configuration alongside its MX records. Check filesystem space, inodes and mailbox quotas when logs indicate local write or storage failures. Do not remove spool files manually to free space.
Unexpected outbound volume
If a compromised mailbox or website is generating mail, contain the affected source, preserve relevant logs, rotate exposed credentials and repair the entry point. Only then decide which queued messages are legitimate. Raising limits or releasing the whole queue before containment can prolong the incident.
7. Verify recovery with a small test matrix
After the targeted correction, send a few uniquely identifiable tests through the affected paths: webmail, the original desktop client or application, and more than one destination provider. Record submission time, delivery result and actual receipt. Where relevant, test inbound mail separately.
Watch queue age as well as count. New messages should progress, legitimate older messages should clear as conditions allow, and the original error should stop recurring. Remote acceptance confirms the handoff; recipient confirmation establishes where the message actually arrived.
Build a useful escalation request
When you contact support, include the affected domain, sender and recipient, timestamp with timezone, Exim queue ID if available, exact error, scope of impact and recent changes. Supply sensitive details through a private support channel. This evidence lets an administrator trace the failure without asking you to recreate the incident repeatedly.
HostGree helps businesses investigate mail queues, routing errors, authentication failures and server-side delivery incidents. Explore our email deliverability service or request an investigation with the message details you have collected.
Frequently asked questions
Should I restart Exim whenever mail is delayed?
Restarting a service does not correct an invalid recipient, remote rejection, routing mistake or compromised account. Check service health and the recorded error first; restart only when the evidence supports it and the operational impact is understood.
Can a delivered message still be missing from the inbox?
Yes. A receiving server can accept a message and then place it in spam, quarantine it or apply a forwarding rule. Continue the trace at the receiving system when the sending log shows a successful remote handoff.
Should I force the whole queue to deliver?
Establish the cause and check for abusive traffic first. After a fix, use a selected legitimate message to verify delivery before considering broader queue action.
Official references
Interface availability and permissions depend on your hosting provider. References checked October 21, 2026.