cPanel Mail Queue Tutorial (2026): Diagnose Frozen Exim Queues, Deferrals, and Outbound Rate Issues in WHM

Your WHM server can look “fine” while mail quietly stacks up in the background. The signs are consistent: the Exim queue count rises, customer tickets roll in, and outbound delivery gets unpredictable. This cPanel mail queue tutorial gives you a repeatable way to find what’s stuck, understand why, and clear it without flushing legitimate mail.

This guide assumes a cPanel/WHM VPS or dedicated server running Exim (the default MTA). The workflow matters: observe → isolate → fix root cause → release mail. If you follow that order, the commands below are production-safe.

Before you touch the queue: collect two minutes of facts

Start with a snapshot. You’re trying to answer one question quickly: is this a remote receiver issue, a local policy/rate issue, or a compromise pushing spam?

1. Check queue size and age

   exim -bpc
   exim -bp | head -n 30

   A few deferred messages for an hour or two can be normal retry behavior. Messages sitting for half a day usually aren’t. If you’re seeing mail older than a day, treat it as an incident.

2. Confirm the mail service health

   systemctl status exim --no-pager
   /usr/local/cpanel/scripts/restartsrv_exim --status

   If Exim is restarting or flapping, the journal often tells you why:

   journalctl -u exim -n 100 --no-pager

3. Verify disk space and inode pressure

   df -h
   df -i

   Queue files live under /var/spool/exim. A “mail queue problem” is frequently a “/var is full” or “inodes are exhausted” problem. If you suspect storage latency, see VPS disk I/O troubleshooting.

Understand what “stuck” means in Exim (and why it matters)

Exim retries deliveries on a schedule. A queue that grows doesn’t automatically mean Exim is broken; it usually means failures are happening faster than successful retries.

• Deferrals: temporary failures (4xx) like “try again later,” greylisting, DNS timeouts, or provider throttles.
• Bounces: permanent failures (5xx) like “user unknown,” “blocked,” “no such domain,” or explicit policy rejects.
• Backscatter risk: forcing retries or releasing everything at once can amplify a spam incident and hurt your IP reputation.

Your goal is simple: find the dominant failure reason, fix that first, then let delivery resume.

Step 1 — Find the dominant error reason in the queue

Don’t guess. Pull a few message IDs and read what Exim is actually logging. You’re looking for patterns you can act on.

List common deferral/bounce messages

exim -bp | awk '{print $0}' | head -n 50

The queue listing is terse. For a real diagnosis, inspect a specific message ID:

exim -Mvh <MESSAGE_ID>
exim -Mvb <MESSAGE_ID>
exim -Mvl <MESSAGE_ID>

• -Mvh headers (sender, auth hints, routing context)
• -Mvb body (useful for spotting obvious spam templates)
• -Mvl log for that message (the exact failure text you need)

Search the mainlog for repeated remote responses

On cPanel, Exim logs are usually in /var/log/exim_mainlog and /var/log/exim_rejectlog.

tail -n 2000 /var/log/exim_mainlog | grep -E "SMTP error|defer|rejected" | tail -n 80

If you keep seeing “Connection timed out” or “Temporary lookup failure,” treat DNS as a primary suspect. Verify what resolvers you’re using and whether lookups behave:

grep -E "^nameserver" /etc/resolv.conf
dig +short mx gmail.com
dig +trace yourdomain.com | head -n 30

Also check basic identity signals. rDNS problems can show up as policy deferrals that look like generic “queue issues.” This companion guide covers the clean setup: Reverse DNS setup.

Step 2 — Identify the top sending account or compromised script

On most cPanel servers, a queue “explosion” traces back to one mailbox or one website. Finding the source early protects everyone else sharing the IP.

Use WHM’s built-in tools first

• WHM → Email → Mail Queue Manager for quick filtering and basic views.
• WHM → Email → Mail Delivery Reports to see which accounts are sending and failing.
• WHM → Email → Track Delivery to trace a message end-to-end and read remote response codes.

Find top authenticated SMTP senders

Big bursts with SMTP auth usually mean a mailbox password leaked (or a device is misconfigured and hammering retries).

grep "A=dovecot_login" /var/log/exim_mainlog | awk '{print $0}' | tail -n 200 | wc -l

To summarize by login (crude, but effective):

grep "A=dovecot_login" /var/log/exim_mainlog \
  | sed -n 's/.*A=dovecot_login:\([^ ]*\).*/\1/p' \
  | sort | uniq -c | sort -nr | head

If one user dominates, reset that mailbox password, review forwarders, and confirm the account isn’t being used to relay outbound junk.

Detect PHP/website-originated mail (scripts)

If the queue is being fed by PHP, you’re often looking at a compromised WordPress site, a vulnerable plugin, or a contact form being abused. A quick clue is the working directory captured in Exim logs:

grep "cwd=" /var/log/exim_mainlog | tail -n 50

Paths under /home/username/public_html are your starting point. Check that account for outdated plugins/themes, unexpected file changes, and suspicious cron jobs.

For a structured cleanup process, use cPanel malware scan.

Step 3 — Apply containment: stop the bleeding without killing legitimate mail

Containment buys you time. You’re trying to reduce outbound damage while keeping normal customers working, and you want changes that are easy to roll back.

Temporarily suspend the worst offender (fastest win)

If one cPanel account is clearly responsible, suspend it while you investigate:

whmapi1 suspendacct user=username reason="Outbound mail burst - investigation"

To unsuspend:

whmapi1 unsuspendacct user=username

Enforce sane outbound rate limits (server-wide)

In WHM, review these settings:

• WHM → Security Center → SMTP Restrictions (blocks users from bypassing Exim via alternate SMTP daemons)
• WHM → Tweak Settings → Mail (look for “Max hourly emails per domain” and related knobs)

Start conservative and adjust with real usage. In a typical shared/reseller setup, 200–500/hour per domain is a reasonable initial range, with exceptions documented for legitimate bulk senders.

Make sure your hostname/HELO is clean

A mismatched hostname or bad HELO/EHLO can trigger blocks that show up as repeated deferrals. Confirm the basics:

• Server hostname resolves forward to your main IP.
• Main IP reverse resolves back to that hostname.

If you’re seeing “Bad HELO” responses, use SMTP HELO/EHLO hostname fix.

Step 4 — Fix the common root causes (with exact checks)

Once you’ve contained the sender, fix the reason deliveries are failing. These are the usual culprits on WHM servers.

Cause A: Remote providers throttling or temp-blocking your IP

Symptoms: lots of 421, 451, “rate limited,” “try again later,” or “temporarily deferred.”

1. Check if your IP is listed (common after spam bursts)

   Use WHM’s built-in checks and review recent outbound behavior. If you had an outbreak, pushing the entire queue through immediately can keep you throttled.

2. Verify SPF/DKIM/DMARC alignment

   Bad alignment increases filtering and deferrals. For a clean setup flow, follow cPanel SPF/DKIM/DMARC setup.

3. Confirm rDNS

   Many receivers soft-fail or throttle mail without a matching PTR record. See Reverse DNS setup.

Cause B: DNS resolution failures on the server

Symptoms: “Temporary lookup failure,” “all hosts for domain are failing,” or repeated timeouts contacting MX hosts.

# Quick resolver test
getent hosts gmail.com

# Confirm you can resolve MX reliably
dig +short mx outlook.com

# See whether lookups are slow
time dig +short mx yahoo.com

If lookups are slow or intermittent, move to reliable resolvers and confirm your firewall allows outbound DNS (UDP/TCP 53). On most WHM systems you’ll manage resolver changes in /etc/resolv.conf or through the OS network manager.

Cause C: Storage pressure under /var/spool/exim

Symptoms: spool write errors, sudden queue growth right after a disk alert, or elevated iowait.

du -sh /var/spool/exim
ls -lh /var/spool/exim/input | tail -n 20

If /var is filling because of logs rather than mail, fix log rotation before you delete anything from the queue. Use VPS log rotation to bring retention back under control.

Cause D: TLS/certificate trust problems (less common, but nasty)

Symptoms: remote servers refusing TLS, or Exim failing TLS negotiation. Check system time first; clock drift breaks certificate validation fast.

timedatectl status
chronyc tracking 2>/dev/null || true

If you’re also dealing with browser HTTPS errors, keep web TLS and mail TLS as separate problems. For web stack certificate work, see SSL certificate setup.

Step 5 — Clean the queue safely (targeted removals, not panic deletions)

You’re doing two things here: removing obvious junk, and retrying legitimate mail after the fix. Avoid wiping the entire queue unless you’ve confirmed it’s almost all spam or garbage.

List the largest senders and domains in the queue

Exim can summarize by sender:

exim -bp | exiqsumm

exiqsumm is often installed with Exim utilities on cPanel servers. If it’s missing, fall back to exim -bp and inspect message IDs directly.

Remove messages from a specific sender (surgical)

Example: remove queued mail from baduser@domain.tld:

exim -bp | awk '/<baduser@domain.tld>/{print $3}' | xargs -r exim -Mrm

Read before running: Exim queue output formatting varies. Validate your extraction first by printing IDs only:

exim -bp | awk '/<baduser@domain.tld>/{print $3}' | head

Remove messages stuck for too long

Example: remove messages older than 3 days (adjust as needed):

exiqgrep -o 259200 -i | head
exiqgrep -o 259200 -i | xargs -r exim -Mrm

259200 seconds = 3 days. List IDs first. Then remove.

Retry the queue after fixes

After you’ve fixed the underlying cause (compromised sender, DNS, throttling), you can force a retry run:

exim -qff

On busy systems, aggressive retries can spike load. If CPU or RAM is already tight, stagger retries and watch pressure. For a step-by-step approach to load spikes, use VPS performance troubleshooting.

Step 6 — Prevent the next queue incident (a practical hardening checklist)

Most queue blowups are predictable. This checklist fits typical WHM servers hosting multiple sites and mailboxes.

• Enforce SMTP Restrictions in WHM so user processes can’t bypass Exim.
• Set per-domain hourly limits and document exceptions for legitimate high-volume senders.
• Require strong mailbox passwords; disable unused accounts and shared “role” inboxes.
• Keep WordPress sites updated; remove abandoned plugins and block XML-RPC if it’s not needed.
• Verify SPF/DKIM/DMARC and rDNS for every domain that sends mail.
• Monitor queue size (alert if > 500, or if oldest message age > 60 minutes).

For a broader baseline that won’t break customer setups, see Control Panel Hardening.

Where HostMyCode fits: choose the right hosting for mail reliability

Mail queues get harder to control when the box is CPU-starved, disk-bound, or fighting noisy neighbors. In 2026, most WHM stacks run more predictably on a VPS with dedicated resources and consistent storage performance.

If you’re building or migrating a WHM stack, start with a HostMyCode VPS. If you’d rather offload OS updates, service monitoring, and core hardening, managed VPS hosting is the safer option for production mail.

FAQ

Should I delete the entire Exim queue to “fix” delivery?

Only if you’ve confirmed the queue is almost entirely spam or undeliverable junk. Most of the time, remove mail surgically by sender/domain and retry after you’ve fixed the root cause.

How do I know if the queue is caused by a compromised WordPress site?

Look for bursts tied to one cPanel user, Exim log lines with cwd= pointing at /home/USER/public_html, and repetitive subjects going out to many recipients. Then scan that account and patch or remove vulnerable plugins.

What queue size is “normal” on a WHM server?

There’s no single “normal” number. A healthy server can carry a small queue during remote throttling. Message age is the better signal. Alert when the oldest message exceeds 60 minutes, even if the total count is modest.

Can DNS issues really cause mail queues?

Yes. If your server can’t reliably resolve MX records, Exim defers delivery and retries later. You’ll typically see “Temporary lookup failure” and repeated timeouts reaching MX hosts.

Summary: the safe order of operations

Measure queue size and message age first. Then find the dominant failure reason and the top sender. Contain the offender, fix the root cause (auth, DNS, reputation, disk), and only then retry the queue.

This cPanel mail queue tutorial approach keeps you out of the “delete everything and hope” trap. If you’re hosting WHM for clients and need predictable mail performance, a properly sized VPS is a better foundation than oversubscribed environments. Start with a HostMyCode VPS, and scale to managed VPS hosting if you’d rather not spend nights babysitting queues.