How to Troubleshoot Email Delivery Issues in cPanel: A Complete Diagnostic Guide

When email stops flowing the way it should, diagnosing the root cause can feel like hunting for a needle in a haystack. Whether your outgoing messages are bouncing, landing in spam folders, or simply disappearing into the void, cPanel provides a powerful set of diagnostic tools to trace exactly what’s going wrong. Understanding how to use these tools effectively can mean the difference between hours of frustration and a quick fix.

This guide walks through the most common email delivery problems in cPanel and the diagnostic methods you can use to identify, isolate, and resolve them. From mail queue inspection and log analysis to DNS verification and SMTP debugging, you’ll learn the systematic approach that experienced sysadmins use to keep email flowing reliably.

Understanding the cPanel Mail Delivery Pipeline

Before jumping into troubleshooting, it helps to understand how email moves through the cPanel stack. When you send a message from a cPanel-hosted account, it travels through several stages:

The mail client (webmail, Outlook, or mobile app) submits the message to the local mail server via SMTP or submission port 587.
Exim, cPanel’s default Mail Transfer Agent (MTA), receives the message and checks its routing rules.
If the recipient is local (same domain or another domain on the same server), Exim delivers it directly to the local mailbox.
If the recipient is remote, Exim performs a DNS lookup for the destination domain’s MX records, then attempts delivery to the remote mail server.
The remote server either accepts the message (250 OK), rejects it (permanent error), or defers it (temporary error).

A failure at any stage produces different symptoms. Knowing which stage is failing narrows your diagnostic focus considerably.

Checking the Mail Queue and Delivery Logs

Viewing the Mail Queue

The mail queue holds messages that Exim couldn’t deliver immediately. A growing queue often points to a systemic delivery problem.

To view the mail queue in cPanel:

Log in to cPanel and navigate to Advanced → Mail Delivery Manager.
Under Mail Queue, you’ll see a list of undelivered messages with their status (frozen or active), sender, recipient, and last delivery attempt time.

Alternatively, you can check the queue via SSH:

exim -bpc

This returns the total number of messages in the queue. To see details of each queued message:

exim -bp | less

A frozen message means Exim has stopped attempting delivery after repeated failures. You can thaw frozen messages manually from the Mail Delivery Manager interface or via the command line:

exim -Mth <message-id>

Analyzing Delivery Logs

cPanel maintains detailed delivery logs at /var/log/exim_mainlog. This log records every SMTP transaction Exim processes, including connection attempts, authentication, routing decisions, and delivery outcomes.

The quickest way to search the logs is through cPanel’s Mail Delivery Manager → View Message Delivery. Enter the sender or recipient email address, and cPanel displays a timeline of delivery events for recent messages.

For deeper analysis via SSH, use grep to filter specific addresses:

grep "user@example.com" /var/log/exim_mainlog | tail -50

Look for key indicators in the log output:

“=>” indicates successful delivery to a recipient
“->” indicates delivery to an alias or forwarder
“**” indicates a deferral (temporary failure)
“==” indicates a frozen message (permanent failure pending)
“R=dnslookup” means Exim is performing DNS-based routing
“T=remote_smtp” confirms it’s attempting delivery via SMTP

A typical deferral looks like this:

2026-05-17 14:32:10 1RqABC-0000xyz-12 ** user@remote.com
R=dnslookup T=remote_smtp H=mx.remote.com [203.0.113.5]
X=TLS1.3: deferred: 452 4.2.2 mailbox full

The error message (after the colon following “deferred”) tells you exactly why the remote server rejected delivery.

Verifying DNS Records for Email Authentication

Email authentication records — SPF, DKIM, and DMARC — are the primary reason legitimate emails end up in spam folders. This section focuses specifically on verification and troubleshooting these records.

Testing SPF Records

An SPF record tells receiving servers which IP addresses are authorized to send mail for your domain. A misconfigured or missing SPF record is the single most common cause of email delivery problems.

Use the dig command to verify your SPF record:

dig TXT yourdomain.com +short

Look for a line starting with v=spf1. A valid cPanel SPF record typically looks like this:

"v=spf1 +a +mx +ip4:192.0.2.10 ~all"

Common SPF issues include:

Missing include statements when using third-party senders (e.g., include:_spf.google.com for Google Workspace).
Too many DNS lookups (SPF has a hard limit of 10 DNS lookups). Use v=spf1 redirect=_spf.yourdomain.com to consolidate.
Using -all (hard fail) before confirming all senders are listed. Start with ~all (soft fail) during testing.

Verifying DKIM Signatures

DKIM adds a cryptographic signature to outgoing messages. Receiving servers verify the signature against a public key published in your DNS.

In cPanel, navigate to Email Deliverability.
Search for your domain in the list.
Click Manage next to your domain and verify that DKIM shows as “Enabled.”

To verify the DNS record is published correctly:

dig TXT default._domainkey.yourdomain.com +short

You should see a long string starting with v=DKIM1; k=rsa; p=. If this record is missing:

Return to Email Deliverability in cPanel.
Click your domain and then Enable under DKIM.
Click Install/Reinstall to publish the DNS record automatically (assuming cPanel can manage your DNS zone).

Checking DMARC Policies

DMARC tells receiving servers what to do when SPF or DKIM checks fail. A missing DMARC record won’t break delivery, but it means you have no insight into authentication failures.

To check your DMARC record:

dig TXT _dmarc.yourdomain.com +short

A minimal DMARC record looks like:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

The p=none policy is safe for monitoring. Only move to p=quarantine or p=reject after confirming SPF and DKIM are working correctly.

Using SMTP Debugging and Telnet for Manual Testing

When automated diagnostics don’t reveal the problem, testing SMTP communication directly can provide answers that logs and DNS checks miss.

Testing SMTP Connection

From the command line, you can simulate an SMTP session with a remote mail server:

telnet mx.remote.com 25

After connecting, you should see the remote server’s banner. Then you can manually issue SMTP commands:

EHLO yourserver.com
MAIL FROM: <sender@yourdomain.com>
RCPT TO: <recipient@remote.com>
DATA
Subject: Test message

This is a test.
.
QUIT

Each command returns a three-digit SMTP response code. Codes starting with 2 indicate success, 3 indicate more input needed, 4 indicate temporary failures, and 5 indicate permanent failures. A 554 5.7.1 Relay access denied error, for example, means the remote server is explicitly refusing your connection.

Checking Port Availability

Some ISPs and cloud hosting providers block port 25 outbound to fight spam. If you’re getting timeouts on port 25, test alternative submission ports:

telnet mx.remote.com 587

telnet mx.remote.com 465

If port 25 is blocked by your hosting provider, you may need to configure Exim to route outgoing mail through a smart host (SMTP relay).

Common Email Delivery Issues and Their Fixes

Messages Deferred with “Helo Command Rejected”

This error means the remote server rejected your server’s HELO/EHLO greeting because it doesn’t match the server’s reverse DNS (PTR record).

Fix: Ensure your server’s hostname has a matching PTR record. Check your current PTR:

dig -x $(curl -s ifconfig.me)

If the PTR doesn’t match your server’s hostname, contact your hosting provider or data center to update the reverse DNS record.

“535 Authentication Failed” in Logs

This appears when a mail client or script tries to authenticate with incorrect credentials.

Fix: Reset the email account password in cPanel under Email Accounts. If using a script (e.g., PHP’s mail() or a contact form), verify that SMTP authentication credentials in the script are correct.

“550 5.1.1 Recipient Rejected”

The remote mail server reports that the recipient address doesn’t exist. This is often correct for typos, but if you’re sure the address is valid, the remote server might have its own delivery restrictions.

Fix: Double-check the recipient address, and consider verifying the address directly with the recipient’s IT team or using a web-based email testing tool.

Email Going to Spam Despite Correct SPF and DKIM

If SPF and DKIM both pass but messages still land in spam, the issue is typically content reputation, sending IP reputation, or DMARC policy.

Fix:

Check your sending IP against blacklists using dig -x YOUR_IP +short or an online blacklist check tool.
Ensure your DMARC policy is p=none while you monitor reports.
Warm up new sending IPs by gradually increasing email volume from a clean IP.
Avoid spammy content characteristics: excessive links, all-caps subject lines, and misleading headers.

Key Takeaways

The cPanel Mail Delivery Manager provides a graphical interface for viewing queued messages and delivery histories, making it the first stop for any email troubleshooting.
Exim logs at /var/log/exim_mainlog contain granular delivery status indicators including deferrals (“**”), successful deliveries (“=>”), and permanent failures (“==”).
DNS verification of SPF, DKIM, and DMARC records using dig commands can resolve most authentication-related delivery problems without needing to touch the mail server itself.
Manual SMTP testing via telnet on ports 25, 587, and 465 helps isolate network-level issues like port blocking and reverse DNS mismatches.
Reverse DNS (PTR records), sending IP reputation, and DMARC policy monitoring are critical factors that go beyond basic SPF and DKIM configuration.
When all else fails, thawing frozen messages and checking for blacklist inclusion provides additional diagnostic data that can guide the final fix.