Mail problems on a cPanel server rarely “half break.” One bad routing choice or one stalled service can cascade. You end up with webmail login loops, SMTP auth failures, and a support queue that won’t stop.
This cPanel mail server troubleshooting tutorial gives you a repeatable WHM workflow. You’ll isolate the failing layer—DNS, authentication, service health, TLS, routing, or IP reputation. Then you’ll fix it without guesswork.
You’ll work from real logs, confirm daemon health, validate DNS records, and test SMTP/IMAP from the command line.
Examples assume cPanel/WHM on AlmaLinux/Rocky/CentOS Stream. That’s still a common production base for cPanel servers in 2026.
What you’ll fix (and how to avoid blind changes)
- Webmail login fails (roundcube/horde/squirrelmail redirects, “IMAP/POP3 server not available”, password errors)
- SMTP authentication errors in clients and WordPress (“535 Incorrect authentication data”, “no SASL mechanisms”)
- Inbound delivery delays caused by greylisting or routing
- Outbound mail stuck in the Exim queue
- TLS and certificate mismatch warnings for mail services
Rule #1: change one thing, then re-test the same failing action. If you stack changes, you might get lucky. You still won’t know what actually fixed it.
Prerequisites (5 minutes)
- Root or reseller-with-WHM access
- Server hostname (FQDN) and main IP address
- A test mailbox you can reset the password for
- SSH access (recommended)
If you’re building or moving a server, start on a stable platform. A properly sized HostMyCode VPS (or managed VPS hosting if you want patching and monitoring handled for you) gives you predictable CPU/RAM and cleaner IP history options.
Both matter for mail reliability and deliverability.
Step 1: Confirm the obvious in WHM (service status + mail routing)
Before you dig through logs, confirm two basics. The server must run the right services. It must also accept mail for the domain.
-
WHM → Server Status → Service Status
- Exim (SMTP) must be running
- Dovecot (IMAP/POP3) must be running
- cPanel Service Daemon (cpaneld) should be running
-
WHM → Email → Mail Routing Configuration
- For domains hosted locally: set to Local Mail Exchanger
- If you use Google Workspace/Microsoft 365: set to Remote Mail Exchanger
Many “webmail is broken” tickets come down to mail routing set wrong. This is common after a migration, a partial restore, or a DNS cutover.
If your issue is specifically forwarding-related, see the internal guide: Email forwarding troubleshooting tutorial.
Step 2: Reproduce the failure and capture the exact error
Don’t debug from a user’s paraphrased description. Reproduce the failure yourself. Then record the exact error and timestamp.
- Webmail: try https://yourdomain.com/webmail and log in. Note whether it fails instantly, loops, or logs in but won’t open folders.
- SMTP client: send via port 587 (STARTTLS) using the mailbox credentials.
- IMAP: connect via port 993 (IMAPS) and list folders.
Timestamps matter. You’ll use them to match log entries to one specific test.
Step 3: Check DNS records that directly break mail (MX, A, PTR, SPF, DKIM)
Mail leans on DNS more than almost anything else. Exim and Dovecot can be healthy and you can still see bounces, delays, or mail flowing to the wrong place.
Quick DNS checks from your workstation
dig +short MX example.com
dig +short A mail.example.com
Expected: your MX points to a hostname that resolves to the IP where Exim should receive mail.
Reverse DNS (PTR) and hostname alignment
For outbound mail, the server IP should have a PTR record that matches your hostname. That hostname should resolve back to the same IP.
# Replace with your server IP and hostname
dig +short -x 203.0.113.10
dig +short A server1.example.net
Need help setting PTR/rDNS? Use these internal guides:
SPF and DKIM basics (fast validation)
SPF and DKIM won’t usually cause webmail login failures. They do cause bounces and poor inbox placement.
If users say “it sends, but nobody receives it,” check these early.
dig +short TXT example.com
dig +short TXT default._domainkey.example.com
If you need to set DKIM on a VPS or rotate keys safely, follow: DKIM setup tutorial.
Step 4: Verify Exim, Dovecot, and cPanel mail ports locally
Next, confirm the server is listening where it should. Run these over SSH as root.
ss -ltnp | egrep ':(25|465|587|110|143|993|995)\b'
Typical expectations on a cPanel server:
- SMTP: 25 (inbound), 587 (submission), 465 (SMTPS if enabled)
- IMAP: 143 (STARTTLS), 993 (IMAPS)
- POP3: 110 (STARTTLS), 995 (POP3S)
If ports aren’t listening, restart the services. Then confirm why they stopped.
systemctl restart exim dovecot
systemctl --no-pager -l status exim
systemctl --no-pager -l status dovecot
Step 5: Use the right logs (and stop tailing the wrong file)
Once you look in the right place, cPanel mail issues stop feeling mysterious.
- Exim main log:
/var/log/exim_mainlog(delivery, queue, SMTP errors) - Exim reject log:
/var/log/exim_rejectlog(blocked/rejected) - Dovecot log: usually
/var/log/maillog(IMAP/POP auth, mailbox access) - cPanel access errors:
/usr/local/cpanel/logs/error_log(webmail UI and auth handoff issues)
Filter by time and email address
# Replace with the mailbox you're testing
EMAIL='user@example.com'
grep -i "$EMAIL" /var/log/exim_mainlog | tail -n 50
grep -i "$EMAIL" /var/log/maillog | tail -n 50
For live tailing during a test login/send:
tail -f /var/log/exim_mainlog /var/log/maillog /usr/local/cpanel/logs/error_log
Step 6: Fix webmail login failures (Roundcube + Dovecot auth path)
Most webmail login failures fall into a short list:
- Dovecot is down or refusing connections
- Authentication fails (bad password, disabled account, mailbox/index issues)
- TLS/certificate mismatch causes clients to drop before auth completes
6.1 Confirm the mailbox exists and isn’t suspended
In cPanel (per-domain), open Email Accounts. Reset the password for a known test mailbox. Then retry the webmail login.
6.2 Test IMAP directly from the server (fastest truth test)
This bypasses browser sessions. It tests Dovecot directly.
# Install if needed
# AlmaLinux/Rocky: dnf install -y openssl
openssl s_client -connect 127.0.0.1:993 -quiet
After connecting, type:
a login user@example.com YourPasswordHere
a list "" "*"
a logout
If the login fails, you’ll see it immediately. Dovecot usually logs the reason in /var/log/maillog.
6.3 Common Dovecot auth errors and fixes
-
“Authentication failed” and you’re sure the password is correct:
- Check for rate limiting or blocks (see Step 10 on brute-force protection)
- Confirm the account wasn’t renamed and the client isn’t using the old username
-
Timeouts or “Server not responding”:
- Look for storage issues (full disk) and I/O wait
- Run
df -handdf -ito catch inode exhaustion
If you want a dedicated deep-dive for Dovecot symptoms (timeouts, missing folders, login loops), use: Dovecot IMAP troubleshooting tutorial.
Step 7: Fix SMTP auth errors (587/465) without breaking outbound mail
Most “can’t send” reports happen on the submission ports (587/465). Port 25 is usually the wrong place to start.
7.1 Test SMTP AUTH locally with openssl
openssl s_client -starttls smtp -connect 127.0.0.1:587 -crlf -quiet
You should see a banner. Then type:
EHLO test
Look for AUTH in the capabilities. If it’s missing, SMTP AUTH may be disabled or misconfigured.
7.2 Confirm SMTP AUTH is enabled in WHM
- WHM → Service Configuration → Exim Configuration Manager
- Under Basic Editor:
- Ensure “Allow SMTP AUTH” is enabled
- Use “Require clients to connect with SSL or issue the STARTTLS command” for submission where possible
7.3 Typical 535 errors and what they mean
- 535 Incorrect authentication data: wrong password, wrong username format, or a blocked IP
- 535 Authentication failed after a password reset: client cached old password; remove and re-add account
- No AUTH in EHLO: SMTP AUTH disabled, or connecting to the wrong port/host
Step 8: Diagnose delayed inbound mail (greylisting vs routing vs DNS)
Greylisting intentionally slows down unknown senders. If it’s tuned poorly, it slows down legitimate senders too.
8.1 Confirm whether greylisting is enabled
In WHM, search for Greylisting and check its status. If it’s enabled, review your settings.
Also whitelist trusted high-volume senders (transactional providers, business partners, ticketing systems).
8.2 Prove greylisting in Exim logs
Look for temporary rejects (4xx) with a greylisting reason.
grep -i "grey" /var/log/exim_mainlog | tail -n 80
If inbound mail is delayed and it’s not greylisting, focus on MX routing and DNS TTL timing.
If you’re mid-migration, follow: DNS cutover checklist tutorial.
Step 9: Clear stuck outbound mail (queue triage you can do safely)
Resist the urge to delete the queue. Start by identifying the dominant failure pattern.
9.1 Inspect the Exim queue
exim -bp
exim -bpc
If the queue is large, check what has been stuck the longest:
exiqsumm | head
9.2 Read the error for a specific message
# Replace MESSAGEID with an ID from exim -bp
exim -Mvh MESSAGEID
exim -Mvb MESSAGEID
Common causes:
- DNS failures: resolver issue or the recipient domain’s MX is broken/misconfigured
- Rate limits / reputation blocks: remote servers temp-failing your IP
- TLS issues: certificate or protocol mismatch (less common, but it happens)
9.3 Re-try delivery after fixing the root cause
exim -qff
If your server IP is fighting reputation problems—or you’re sending app mail (WordPress forms, order emails)—an outbound relay is often the cleanest fix. It reduces bounces and helps protect your hosting IP reputation.
Use: SMTP relay setup guide tutorial.
Step 10: Check firewall and brute-force blocks (without locking out real users)
Blocks create a predictable pattern. Mail apps time out. Then they switch to “cannot connect,” even while the server looks healthy.
10.1 Confirm ports are reachable from the internet
From a remote machine (not the server), test:
# Replace with your server IP
nc -vz 203.0.113.10 587
nc -vz 203.0.113.10 993
10.2 cPHulk and Fail2Ban checks
- WHM → Security Center → cPHulk Brute Force Protection → check whether the client IP is blocked
- If you run Fail2Ban, confirm your jails aren’t too aggressive
For a clean cPanel-focused brute-force setup that doesn’t punish legitimate clients, follow: cPanel Fail2Ban setup guide.
Step 11: Fix mail TLS warnings (cert mismatch, old ciphers, wrong hostname)
Certificate warnings in Outlook or Apple Mail undermine trust fast. Most of the time, mail still works.
The usual cause is simple: the certificate doesn’t match the hostname the client connects to.
11.1 Confirm which certificate cPanel is using for services
In WHM:
- WHM → Service Configuration → Manage Service SSL Certificates
- Ensure the certificate covers the hostname clients use (often the server hostname)
11.2 Test the certificate on IMAPS/SMTPS
# IMAPS
openssl s_client -connect mail.example.com:993 -servername mail.example.com -brief
# SMTP submission
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -brief
If you’re also hardening web TLS and want consistent modern settings, use: TLS hardening tutorial. (Mail TLS is separate, but the test approach is the same.)
Step 12: A practical “mail is broken” checklist for support queues
Paste this into your runbook and work it in order. It prevents “random fixes” that create new problems.
- Is the domain set to Local or Remote correctly in Mail Routing?
- Do MX records point to the correct host, and does that host resolve to this server IP?
- Are Exim and Dovecot running? Are ports listening (25/587/993)?
- Can you authenticate via IMAP locally using
openssl s_client? - Do logs show rejects (4xx/5xx) or auth failures at the test timestamp?
- Is the client IP blocked by cPHulk/Fail2Ban or upstream firewall?
- Is the disk full or inodes exhausted?
- Is the Exim queue growing? What’s the dominant error in queued messages?
- Does the server IP have working rDNS, and are SPF/DKIM present?
Where hosting choices affect mail stability
Email is unforgiving when a server is short on CPU, memory, or disk I/O. If you host mail for clients, size the machine like a mail server. Don’t size it like a web-only box.
That often means a VPS built for hosting workloads. Move to a dedicated server once mailbox counts and queue volume justify it.
If you’re planning a move, keep it controlled. Lower DNS TTLs, stage the cutover, and plan an easy rollback.
A HostMyCode migration makes sense when you want the server-side steps handled cleanly while you manage customer communication.
If you’re troubleshooting mail every week, the root cause is often the platform—not your process. Run cPanel on a properly sized HostMyCode VPS, or move day-to-day operations to managed VPS hosting so updates, monitoring, and service recovery don’t depend on late-night log digging.
FAQ
Why does webmail work but SMTP sending fails?
Webmail typically talks to IMAP/SMTP on the server’s local network. Desktop and mobile clients connect from the public internet over port 587/465.
If firewall rules, SMTP AUTH settings, or IP blocks (cPHulk/Fail2Ban) affect those ports, sending breaks while webmail still looks fine.
What’s the fastest way to prove it’s a password problem vs a server problem?
Test IMAP auth locally with openssl s_client against 127.0.0.1:993. If that login fails, it’s not DNS or a browser session. It’s authentication, mailbox state, or Dovecot health.
Should I disable greylisting to fix delays?
Not by default. First confirm greylisting is the cause (4xx temporary rejects in the Exim logs).
If it is, tune whitelists and thresholds. Disable it only if it blocks legitimate mail more than it stops spam in your environment.
What causes “mail certificate not trusted” warnings in clients?
Most often, the client connects to mail.yourdomain.com but the server presents a certificate issued for the server hostname (or the other way around).
Fix the assignment in WHM’s service SSL certificate manager, then re-test with openssl s_client.
When should I use an SMTP relay instead of sending directly from my server?
If you send transactional mail (WooCommerce orders, form notifications) and you’re seeing bounces, temporary blocks, or reputation issues, an SMTP relay is often the quickest stability win. It separates web hosting from email reputation management.
Summary
This cPanel mail server troubleshooting tutorial follows a simple order of operations. Check routing and service health first. Prove failures with direct protocol tests. Then use logs to pinpoint the cause.
Stick to the sequence—routing → DNS → ports → auth tests → logs → queue triage—and you’ll fix issues faster with fewer side effects.
If you want a cleaner baseline for cPanel email (and fewer deliverability surprises), run it on a reliable platform like a HostMyCode VPS or move up to dedicated servers once mailbox volume and queue sizes justify it.