Back to tutorials
Tutorial

cPanel Mail Queue Troubleshooting Tutorial (2026): Fix Deferred Emails, High Load, and “Frozen” Exim on WHM

cPanel mail queue troubleshooting tutorial (2026) to clear deferred mail, stop spam bursts, and restore Exim delivery fast.

By Anurag Singh
Updated on Jul 26, 2026
Category: Tutorial
Share article
cPanel Mail Queue Troubleshooting Tutorial (2026): Fix Deferred Emails, High Load, and “Frozen” Exim on WHM

Your WHM server can look “fine” until Exim stops draining the queue. Then CPU climbs, load averages rise, and users miss password resets and invoices. This cPanel mail queue troubleshooting tutorial gives you a repeatable workflow to see what’s stuck, why it’s stuck, and how to clear it without deleting legitimate mail.

The steps below assume a typical cPanel/WHM stack: Exim + Dovecot on AlmaLinux/Rocky/CloudLinux. Most WHM builds in 2026 use the same core checks.

What you’ll need before you touch the queue

  • WHM root access (SSH preferred) and a maintenance window if you expect heavy changes.
  • A snapshot/backup point if you’ll edit Exim configuration or disable accounts.
  • Disk headroom: keep at least 10–15% free space on the filesystem holding /var.

On crowded servers, mail usually shows capacity issues first. A HostMyCode VPS gives you predictable CPU/RAM for Exim and SpamAssassin. It also gives you room to scale before the queue becomes a daily incident.

Baseline the incident in 5 minutes (don’t guess)

Collect quick numbers up front. Use them to confirm whether your changes help.

# Queue size
exim -bpc

# Top-level summary (who is sending)
exim -bp | exiqsumm | head -n 30

# Exim process pressure
ps aux --sort=-%cpu | head -n 15

# Disk and inode health
df -h /var
df -ih /var

# Quick load view
uptime

Interpretation:

  • Queue size spiking + many Exim processes usually means a spam burst or remote delivery retries piling up.
  • Queue size steady but delivery slow often points to DNS/rDNS, provider throttling, or content-filter delays.
  • Low disk space or inode exhaustion can make Exim look “frozen” because it can’t write spool files.

Confirm Exim is actually running and not wedged

On WHM, Exim is typically managed by systemd. Check status first.

Don’t restart blindly. Grab a quick log sample so you keep the context.

systemctl status exim --no-pager
journalctl -u exim -n 200 --no-pager

# cPanel logs (often more useful)
tail -n 200 /var/log/exim_mainlog
tail -n 200 /var/log/exim_rejectlog
tail -n 200 /var/log/exim_paniclog

Red flags to look for:

  • paniclog entries about permissions, spool corruption, or failed lookups
  • Repeated temporary lookup failures (DNS), which can keep mail deferred for hours
  • Errors like no space left, too many open files, or cannot create spool file

If you need a DNS refresher for mail routing and MX behavior, pair this with our email routing troubleshooting tutorial. It helps you fix the cause instead of chasing symptoms.

Find out what’s filling the queue (sender, domain, script)

Most queue blow-ups fall into three buckets. It’s usually a compromised account sending spam, a legitimate app sending too fast, or remote providers deferring you due to reputation/DNS/TLS issues.

1) Identify top senders quickly

# Top senders and recipients
exim -bp | exiqsumm | head -n 50

# See just the sender addresses
exim -bp | awk '/<=/{print $4}' | sort | uniq -c | sort -nr | head -n 30

One cPanel “gotcha”: the visible sender may be a local user. The real source can still be a PHP script.

Next, map messages back to the account and file path.

2) Map message IDs to the originating account/script

Pick a message ID from exim -bp. Then inspect it:

# Replace with a real message ID from exim -bp
MSGID="1sAbCd-000XYZ-9a"

exim -Mvh $MSGID   # headers
exim -Mvb $MSGID   # body
exim -Mvl $MSGID   # log lines for that message

Useful indicators:

  • X-PHP-Script: (often includes the domain and path)
  • Received: lines that show local submission details
  • authenticated_id in the message log (for SMTP-auth users)

3) Check for SMTP-auth compromise

# Shows successful SMTP authentications (common location)
grep -i "AUTH" /var/log/exim_mainlog | tail -n 200

# Look for one user authenticating from many IPs
grep -i "authenticated_id" /var/log/exim_mainlog | awk '{print $NF}' | sort | uniq -c | sort -nr | head

If this looks like credential stuffing or a leaked password, lock it down fast.

Enable MFA for WHM/cPanel logins and review access. Our cPanel 2FA setup guide walks through a safe rollout.

Diagnose the “deferred” reason (the queue tells you why)

Deferred mail isn’t a mystery. Exim records the remote host involved and the reason it backed off.

Group deferrals by reason. Fix the biggest bucket first.

# Show queue with error reasons (compact view)
exim -bp | exiqsumm | sed -n '1,80p'

# Pull common deferral phrases from logs
grep -i "defer" /var/log/exim_mainlog | tail -n 300

Common deferral buckets and what they usually mean:

  • “Connection timed out” / “No route to host”: remote is down, a firewall blocks you, or you’re hitting IPv6 trouble.
  • “Temporary lookup failure”: your server’s DNS resolver is failing or slow.
  • “Rate limited” / “Try again later”: you’re sending too quickly, or reputation is weak.
  • “TLS required” / “handshake failure”: TLS mismatch, cert issues, or policy constraints (sometimes MTA-STS).

If TLS policy expectations are part of the problem, the controlled rollout in our MTA-STS setup guide helps you tighten security without breaking delivery.

Fix DNS and rDNS first (it’s the fastest reputation win)

Queues often explode after an IP change, a migration, or a new VPS deployment where rDNS wasn’t set. When your IP identity doesn’t check out, some providers slow-roll you with deferrals.

Quick checks

# What is your sending IP?
curl -4s https://ifconfig.co

# Does the IP have PTR (rDNS)?
host $(curl -4s https://ifconfig.co)

# Does PTR map back to an A record?
PTR=$(host $(curl -4s https://ifconfig.co) | awk '{print $NF}' | sed 's/\.$//')
host $PTR

A clean baseline looks like this: your IP resolves to a hostname (PTR). That hostname resolves back to the same IP (forward-confirmed rDNS).

If it doesn’t, fix rDNS and allow time for propagation.

Use our step-by-step rDNS setup guide for the exact record format and verification checklist.

Stop the bleeding: throttle, suspend, or block the source safely

Once you know whether the queue is spam or legitimate mail under strain, apply the smallest effective control.

Avoid nuking the whole queue unless you’ve confirmed it’s junk.

Option A: Suspend a compromised cPanel account

From WHM: Account Functions → Manage Account Suspension. It’s blunt, but it stops both web and mail sending.

If you need CLI:

# Replace USERNAME
whmapi1 suspendacct user=USERNAME reason='Outbound mail incident - investigation'

Option B: Temporarily block outbound mail for one domain/user (Exim deny list)

In WHM, go to Exim Configuration Manager → ACL Options. During incident response, blocking a sender or sender-domain can buy you time.

Exact paths vary by build, but common local deny lists include:

  • /etc/alwaysrelay and /etc/neverrelay (cPanel-managed)
  • Custom ACL includes under /etc/exim.conf.local (if you use advanced config)

After changes, rebuild the config and restart Exim from WHM, or via CLI:

/scripts/buildeximconf
systemctl restart exim

Option C: Reduce outbound rate to keep remote providers accepting mail

If the mail is legitimate (newsletters, invoices) but volume is too high, set rate limits in WHM’s Exim settings. Your goal is to prevent provider throttles from turning into hours of retries.

Start conservative per domain/hour. Raise limits once deferrals drop.

Re-check the queue and logs every 15 minutes while you tune.

Clean up the queue the right way (review, then remove)

Queue cleanup should be surgical. Clear obvious spam and keep transactional mail moving.

Most importantly, avoid collateral damage.

1) Freeze suspicious messages instead of deleting immediately

Freezing stops retries while you investigate.

# Freeze a specific message
exim -Mf MSGID

# List frozen messages
exim -bp | grep -i frozen | head

2) Bulk-remove messages by criteria (be careful)

On production WHM servers, don’t “delete everything older than X” until you’ve verified the sender. Target by sender, sender domain, or a known spam pattern.

# Remove messages from a specific sender address
exiqgrep -i -f user@example.com | xargs -r exim -Mrm

# Remove messages from a sender domain
exiqgrep -i -f @example.com | xargs -r exim -Mrm

# Remove messages older than 2 days (use only if you’ve confirmed they’re junk)
exiqgrep -o 172800 | xargs -r exim -Mrm

Pitfall: On multi-tenant servers, bulk deletion can erase real password resets and receipts.

If you have to purge, export message IDs first. That gives you an audit trail.

3) Re-queue or force delivery after fixes

After DNS/rDNS/rate issues are corrected, try a delivery run:

# Attempt a queue run
exim -qff

# Or just let the daemon handle it (preferred) after stabilizing rate limits

Fix the underlying cause: common patterns and exact next steps

Pattern 1: PHP mail abuse from a single WordPress site

Symptoms: thousands of messages with similar subjects, X-PHP-Script pointing to one domain, and bursts right after plugin/theme changes.

What to do:

  1. Suspend the account or block outbound mail temporarily.
  2. Scan the account’s web root for recently modified files and suspicious wp-admin lookalikes.
  3. Rotate the site’s admin passwords and database credentials.
  4. Disable vulnerable plugins/themes and update WordPress core.

If the site is business-critical and you want less operational risk, consider moving it to HostMyCode WordPress hosting. Resource isolation and WordPress-focused guardrails reduce “one site ruins mail for everyone” incidents.

Pattern 2: Remote providers deferring because your IP is new or “cold”

Symptoms: lots of “try again later,” “rate limited,” or temporary 4xx responses from large providers.

What to do:

  • Warm up sending: lower hourly limits per domain, then ramp over several days.
  • Verify SPF/DKIM/DMARC alignment for each sending domain.
  • Ensure PTR is set and forward-confirmed.

For the mail-auth checklist, follow our email authentication setup guide. If DKIM is already in place and you need to rotate keys safely, use the playbook in DKIM key rotation tutorial.

Pattern 3: DNS resolver issues on the server

Symptoms: “Temporary lookup failure” in Exim logs, slow deliveries, and timeouts resolving MX records.

# Check resolver config
cat /etc/resolv.conf

# Test lookups
getent hosts gmail.com
host -t mx gmail.com

# If using systemd-resolved (varies by OS)
resolvectl status 2>/dev/null | head -n 40

What to do next:

  • Use stable resolvers (your provider’s, or reputable public resolvers) and keep them consistent.
  • Avoid broken split-DNS setups unless you have a clear reason and test coverage.
  • Re-test lookups, then re-run the queue.

Pattern 4: The queue is fine; the server is just underpowered

Symptoms: mail delivers, but spikes keep load averages high. SpamAssassin/ClamAV stalls.

Exim processes may stack up during bursts. That’s expected when CPU and I/O are tight.

Checklist:

  • Confirm CPU steal time isn’t high (on VPS): top or mpstat
  • Check memory pressure and swapping: free -m, vmstat 1 10
  • Review concurrent delivery settings and spam scanning policies

If you run email, multiple sites, and backups on one box, upgrading to managed VPS hosting is often cheaper than repeated queue emergencies.

You get help tuning limits, monitoring, and capacity planning. You still keep familiar WHM workflows.

Hardening measures that prevent the next queue incident

After delivery stabilizes, spend 30 minutes on prevention. This is where you save the most time later.

  • Enable MFA for WHM and cPanel users and stop sharing admin credentials.
  • Limit PHP mail where you can; prefer authenticated SMTP for apps and websites.
  • Set sane per-domain/hour limits and exceptions for known transactional senders.
  • Monitor the queue: alert on queue size, deferral rate, and reject spikes.
  • Keep rDNS, SPF, DKIM, DMARC aligned after migrations and IP changes.

Queue monitoring doesn’t need a big stack. A simple cron job can check exim -bpc and email admins at a threshold.

# Example: alert if queue > 500
Q=$(exim -bpc)
if [ "$Q" -gt 500 ]; then
  echo "Exim queue is $Q on $(hostname)" | mail -s "[ALERT] Exim queue high" admin@yourdomain.tld
fi

Post-incident checklist (use this every time)

  1. Record queue size, top senders, and top error reason.
  2. Confirm disk/inodes and Exim status.
  3. Verify rDNS forward-confirmation.
  4. Identify the source (SMTP-auth vs PHP script vs remote deferrals).
  5. Apply the smallest containment (suspend, block sender, throttle).
  6. Remove only confirmed spam from the queue; freeze suspicious items first.
  7. Re-test delivery to major providers and review logs for 10–15 minutes.
  8. Implement one prevention control (limits, MFA, monitoring) before closing.

If you run WHM mail for customers, the queue should stay boring. HostMyCode VPS plans give you dedicated resources for Exim and spam filtering, and managed VPS hosting helps you tune limits and monitoring before deliverability slips.

FAQ

Is it safe to delete the entire Exim queue on cPanel?

Only if you’re certain it’s all junk. On multi-tenant WHM servers, deleting everything can wipe legitimate password resets and receipts. Prefer removing by sender or freezing messages while you identify the source.

Why do I see thousands of “deferred” messages but no obvious errors?

Remote servers often reply with temporary 4xx codes that look harmless. Check exim -Mvl for a sample message and group log deferrals by phrase (rate limiting, DNS lookup failures, TLS policy).

How do I tell if spam is coming from SMTP login or a website script?

SMTP-auth spam usually shows authenticated_id in Exim logs. Scripted spam often includes X-PHP-Script headers or local submission logs tied to a domain path.

What’s the fastest fix if deliverability tanked after an IP change?

Set correct PTR (rDNS) for the new IP, confirm forward resolution matches, then verify SPF/DKIM/DMARC alignment. If you’re on WHM and changed server IPs, plan a careful re-IP workflow so mail and DNS stay consistent.

How can I prevent queue issues on a busy hosting server?

Use per-domain rate limits, enforce MFA, monitor queue size, and keep DNS/rDNS clean. If the server routinely runs hot during mail bursts, add CPU/RAM or separate workloads onto a larger VPS.

Summary: get mail flowing, then make it boring

A stuck mail queue is rarely “an Exim problem.” It’s usually a compromised sender, a DNS/rDNS identity mismatch, or a server that can’t keep up with scanning and retries.

Baseline the queue, identify the source, contain it with the smallest control, and remove only confirmed junk.

If you want fewer queue incidents and more headroom for normal spikes, run WHM on a HostMyCode VPS sized for mail and web, or hand operational tuning to managed VPS hosting while keeping your control-panel workflow intact.