Proudly Canadian 
When your server starts slowing down unexpectedly, websites become sluggish, or you notice email delivery delays affecting multiple accounts, an overloaded Exim mail queue is one of the first things worth checking. It is a problem that shows up regularly on shared hosting and VPS environments, and it almost always traces back to either a compromised website or a misconfigured script sending email in bulk without your knowledge.
The key thing to understand upfront is that clearing the queue alone is not a fix. If you delete thousands of queued messages without identifying and stopping the source, the queue will fill up again within hours. This guide walks through how to check the queue, diagnose the source, clear it safely, secure the affected account, and prevent the issue from coming back.
Quick Fix Summary
- Check the current queue size with
exim -bpc - Inspect queued messages to identify the sending account or script
- Review Exim logs to trace the origin of the outgoing mail
- Remove the spam messages from the queue
- Locate and remove or disable the compromised script
- Secure the affected cPanel account and check for blacklisting
What is the Exim Mail Queue and Why Does It Get Stuck?
Exim is the mail transfer agent that cPanel servers use to handle all outgoing email. When a message is sent, whether from a website contact form, a PHP script, or a user's email client, it passes through Exim and sits briefly in the mail queue while Exim attempts delivery. Under normal operation this happens within seconds and the queue stays nearly empty.
The queue gets stuck or overloaded in a few specific situations. The most common is a hacked website running a spam script that fires thousands of outgoing messages per hour. The second is a legitimate but misconfigured plugin, contact form, or newsletter tool that has been triggered to send at a volume the server cannot process in time. The third is a backscatter problem, where your server previously sent spam and is now receiving a flood of bounce messages in response.
In all of these cases, Exim keeps trying to process the queue, spawning new delivery processes as fast as it can. When the queue is large enough, this causes Exim to consume significant CPU and memory, which impacts everything else running on the server. Web pages slow down, databases become unresponsive, and in severe cases the server becomes unreachable entirely.
Step 1: Check the Current Queue Size
The first thing to do is get a clear picture of how many messages are queued. SSH into your server and run:
exim -bpc
This returns a single number representing the total messages currently in the queue. A healthy server should have a queue in the single or low double digits. If you are seeing hundreds, the queue is backed up and something is wrong. Thousands means a serious spam or compromise situation is in progress.
To see the actual messages and their details:
exim -bp
This lists every queued message with its ID, age, size, sender, and recipient. Scan the output for patterns. If you see the same sender address repeated across hundreds of entries, or the same domain appearing constantly in the recipient list, that is your starting point for the investigation.
You can also view the mail queue visually from WHM by navigating to Email, then Mail Queue Manager. This gives you a filterable interface without needing to use the command line, though for large queues the command line tools are faster.
Step 2: Identify the Source of the Problem
Before deleting anything, you need to know where the mail is coming from. The Exim main log is the most reliable source of this information.
grep "cwd=" /var/log/exim_mainlog | awk '{print $6}' | sort | uniq -c | sort -rn | head -20
This command extracts the working directory from Exim log entries, which tells you which directory on the server the sending script was running from. The results are sorted by frequency, so the account or script generating the most mail appears at the top. A line like /home/username/public_html/wp-content/plugins/contact-form points directly to the responsible script.
You can also search the main log for a specific time window to see when the spam started:
grep "$(date '+%Y-%m-%d')" /var/log/exim_mainlog | grep "<<" | awk '{print $5}' | sort | uniq -c | sort -rn | head -20
This shows the most active sending addresses from today's log. If a single address is responsible for thousands of entries, that account needs to be investigated immediately.
In WHM, you can also use the Track Delivery tool under Email to search for messages by sender, recipient, or time range, which gives you a cleaner view if you find the command line output difficult to parse.
Step 3: Remove the Spam Messages from the Queue
Once you have identified the source, you can selectively remove those messages from the queue. If all of the spam is coming from a single sender address, you can remove just those messages:
exiqgrep -f [email protected] -i | xargs exim -Mrm
Replace [email protected] with the actual sender address you identified in Step 2. The exiqgrep tool filters the queue and returns only the message IDs matching your criteria, which are then passed to exim -Mrm for removal.
If the queue is entirely spam with no legitimate messages mixed in, you can remove everything at once:
exim -bp | awk '/^ *[0-9]+[mhd]/{print $3}' | xargs exim -Mrm
Use this with caution. Any legitimate email waiting for delivery, such as password reset messages or transactional emails from your applications, will also be deleted. If there is any possibility of legitimate mail in the queue, use the filtered approach above rather than wiping everything.
After clearing the queue, check the count again with exim -bpc. If the number immediately starts climbing again, the script generating the spam is still running and needs to be dealt with before anything else.
Step 4: Locate and Stop the Compromised Script
Clearing the queue buys you time, but the underlying problem is still there. You need to find the script responsible and either remove it or disable it.
Based on what you found in the Exim logs during Step 2, navigate to the directory identified and look for recently modified files. PHP spam scripts are often injected as unfamiliar files with random-looking names, or inserted into legitimate-looking files as obfuscated code blocks. Run the following to find PHP files modified in the last 24 hours:
find /home/username/public_html -name "*.php" -mtime -1 -ls
Replace username with the actual cPanel account name. Files that were modified recently and that you do not recognise are worth inspecting. Common injection points include WordPress plugin directories, the uploads folder, theme files, and the root of the public_html directory.
Look inside suspect files for signs of obfuscated code. PHP spam scripts frequently use base64 encoding, eval() functions, or compressed strings to hide what they are doing. Legitimate plugin files do not typically contain these patterns.
If you find the script, delete it. If it is injected code inside a legitimate file, remove the injected block and leave the rest of the file intact. After removal, run exim -bpc again and watch whether the queue begins growing. If it does not, you have found and stopped the source.
On WordPress sites specifically, the most common spam injection points are:
- Nulled or outdated plugins, particularly contact form, SEO, or file manager plugins
- Nulled themes or themes downloaded from unofficial sources
- The wp-content/uploads directory, which is world-writable by default and a common place to drop scripts
- The wp-config.php file or .htaccess file if the attacker had write access
Step 5: Secure the Affected Account
Finding and removing the spam script is not the end. If a script was injected, it means the attacker had write access to the file system. You need to understand how they got in and close that entry point, otherwise a new script will appear.
Start by changing the cPanel account password and the FTP password for the affected account. If the site runs WordPress, change the WordPress admin password as well and review the list of admin users for any accounts you do not recognise.
Run a malware scan on the account. From WHM you can use the Virus Scanner under Security Center. For WordPress sites specifically, a plugin like Wordfence or the Malcare scanner will give you a thorough file-by-file inspection that the server-level scanner may miss.
Update everything. Outdated WordPress core, plugins, and themes are the most common attack vector for shared hosting accounts. Run all available updates immediately after removing the malicious files. If a plugin that was compromised is no longer being maintained and has no update available, deactivate and remove it entirely.
Review file permissions. Web-writable directories that do not need to be writable should be locked down. The wp-content/uploads directory needs write access for media uploads, but most plugin and theme directories do not. Setting directories to 755 and files to 644 is a reasonable baseline.
Step 6: Check for IP Blacklisting
If your server was sending spam at volume, there is a real chance your server IP has been listed on one or more email blacklists. This is a serious secondary problem because it affects every account on the server, not just the compromised one. Even after you stop the spam, emails from all accounts may be rejected by Gmail, Outlook, and other providers until the IP is delisted.
Check your IP at MXToolbox Blacklist Check by searching for your server's IP address. This runs the IP against over 100 blacklist providers and shows you which ones have listed you.
Each provider has its own delisting process. Spamhaus has a self-service lookup and removal form at spamhaus.org. Microsoft's Smart Network Data Services at sendersupport.olc.protection.outlook.com handles delisting for Outlook and Hotmail. Barracuda's lookup at barracudacentral.org/rbl/removal-request handles their list. In all cases, you need to have stopped the spam before requesting removal, because these providers verify that the issue is resolved before delisting.
Delisting typically takes between a few hours and a few days. While you are waiting, it is worth setting up or reviewing your server's reverse DNS (PTR record) and ensuring your SPF and DKIM records are properly configured, as these signals help re-establish your IP's reputation with mail providers.
Managing This Through WHMCS
If you are a reseller or your hosting is managed through our client portal, you can open a support ticket directly from your WHMCS client area and request queue investigation. Include your server hostname or IP address and the domain you suspect is the source. Our team has direct access to Exim logs and WHM tools and can trace the source and clear the queue without requiring you to have SSH access.
If you are an existing customer operating a legacy self-managed VPS or dedicated server and have WHM access, the Mail Queue Manager under the Email section provides a visual interface for viewing and deleting queued messages. For the log analysis and script hunting described above, SSH access is required. New infrastructure engagements are scoped as managed services with responsibilities defined in writing.
Common Causes at a Glance
Compromised WordPress installations are responsible for the majority of cases we deal with. Outdated plugins, especially those in the contact form, file management, and SEO categories, are exploited regularly and give attackers a path to upload PHP scripts. Nulled plugins and themes downloaded from unofficial sources frequently contain backdoors that are activated remotely. Weak cPanel or FTP passwords can be brute-forced, giving an attacker direct file system access. Email loops, where a script is configured to forward to an address that bounces back to the same script, can also fill a queue quickly without any external attack being involved.
When to Contact Support
If you have cleared the queue and it continues to fill, but you cannot locate the responsible script in the file system, deeper log analysis at the server level is needed. Similarly, if your IP has been blacklisted by multiple providers and you are not sure how to approach the delisting process, or if you are dealing with a server-wide issue affecting multiple cPanel accounts at once, those situations benefit from direct server access that most shared hosting customers do not have.
Open a support ticket from your client area with your domain name, server hostname, and a note about what you have already tried. The more context you can provide, the faster the investigation goes.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.