How to audit email forwarders in cPanel and track Exim traffic volume

Managing Linux mail servers running cPanel/WHM can make it challenging to remember offhand where every configuration file lives on the filesystem. Over time, aliases and email forwarders created through the web interface accumulate, silently multiplying incoming messages and consuming resources in the background.

I recently had to audit the exact infrastructure impact generated by email forwarders on a domain with high message volume. The core question was straightforward: how much of that traffic was simply being written to local mailboxes, and how much was being forwarded out to third-party mail hosts, burning outbound bandwidth and risking IP reputation?

In this practical guide, I cover how to inspect forwarder rule files, extract accurate delivery metrics from Exim logs, and separate local mailbox storage from outbound SMTP transactions.

The architecture of email forwarders in cPanel#

In cPanel, email forwarding rules exist at two distinct layers:

1. At the individual cPanel account level: User forwarder definitions are saved inside the account home directory:

/home/username/etc/domain.com/forwarders

1. At the global MTA server level: Exim references the definitive routing tables located centrally in:

/etc/valiases/domain.com

When working directly in the SSH terminal as root, the /etc/valiases/ directory is the authoritative source for all domain alias mappings.

Inspecting the aliases file#

Checking a domain's alias file reveals how each address routes incoming messages:

cat /etc/valiases/company.com

The file structure is human-readable:

contact@company.com: ops@company.com,finance@company.com
director@company.com: manager@externalprovider.com
supervisor@company.com: supervisor@externalprovider.com
audit@company.com: audit@externalprovider.com
import01@company.com: analyst01@externalprovider.com
import02@company.com: analyst02@externalprovider.com
billing@company.com: finance@company.com
logistics@company.com: supervisor@externalprovider.com,coordinator@externalprovider.com
sales01@company.com: sales01@externaldistributor.com
*: :fail: No Such User Here

When an alias file contains hundreds of entries, manual inspection is slow. To instantly identify addresses configured to forward to multiple destinations (which generate the heaviest message multiplication load), use this awk command:

awk -F': ' '{print NF-1 " -> " $0}' /etc/valiases/company.com | sort -rn

This one-liner uses : as the field separator, counts the number of destinations per line, and sorts them from highest to lowest. Addresses forwarding to multiple targets float directly to the top.

However, configuration files only describe the rules, not actual traffic. To evaluate live mail volume, these aliases are cross-referenced against the MTA log.

Analyzing Exim logs: calculating actual message volume#

The /var/log/exim_mainlog records every incoming transaction, delivery, rejection, and deferral on the server.

1. Gross delivery count#

To determine how many total messages were delivered for the domain (both to local mailboxes and through forwarders), run exigrep filtering for completed deliveries (=>):

exigrep "company.com" /var/log/exim_mainlog | grep "=>" | awk '{print $4}' | sort | uniq -c | sort -rn

This outputs the aggregate volume of successful deliveries processed by Exim for that specific domain.

2. Message volume by byte size with eximstats#

If you need to evaluate throughput in megabytes to measure bandwidth or storage impact, the built-in eximstats utility aggregates byte volumes:

eximstats -ne -nr /var/log/exim_mainlog | grep -A 10 "Deliveries by destination address"

To produce a comprehensive visual HTML report for detailed review, run:

eximstats /var/log/exim_mainlog > /root/exim_report.html

3. Identifying the highest volume recipients#

This command parses the log to isolate the destination addresses receiving the most messages:

grep "=>" /var/log/exim_mainlog | grep "company.com" | awk '{print $5}' | cut -d'<' -f2 | cut -d'>' -f1 | sort | uniq -c | sort -rn

The terminal output shows who receives the bulk of the traffic:

    440 support
    202 sales
    181 finance
     89 system
     89 analyst01@externalprovider.com
     82 operations
     79 supervisor@externalprovider.com
     55 coordinator@externalprovider.com
     52 logistics
     42 frontdesk
     26 purchasing
      9 consultant@externalprovider.com
      8 bounce+985221-analyst01=company.com@bounceservice.com

Separating local mailbox deliveries from external forwarders#

Looking at the extracted recipient list, traffic falls into two distinct categories with very different operational impacts:

Local accounts: storage and disk i/o impact#

Recipients such as support (440 messages), sales (202), and finance (181) represent local cPanel mailboxes.

The operational overhead here is disk write I/O inside user Maildir directories and mailbox storage capacity. The server accepts the incoming message over SMTP, writes it to disk, and completes the transaction.

External forwarders: outbound bandwidth and IP reputation risk#

The true cost and risk reside in addresses redirecting messages to external mail domains:

• analyst01@externalprovider.com: 89 external relays
• supervisor@externalprovider.com: 79 external relays
• coordinator@externalprovider.com: 55 external relays

Every time Exim forwards a message externally, it must initiate a new outbound SMTP OUT connection to the receiving mail server, consuming network bandwidth and connection slots.

Worse still is the threat of IP reputation damage from spam and bounce relaying.

Notice this line in the log: 8 bounce+985221-analyst01=company.com@bounceservice.com

Forwarded accounts often receive third-party promotional mail and automated bounce notices. Because the forwarding rule blindly relays every incoming message to external destinations (like Google Workspace, Outlook, or external MX hosts), your server's IP address appears to destination security filters as the source of that spam. If external providers reject forwarded messages repeatedly, your server IP gets listed on RBLs and DNSBLs.

Automating external forwarder volume counting#

To isolate only messages that were relayed to external servers for accounting, monitoring, or quota auditing:

grep "=>" /var/log/exim_mainlog | grep "company.com" | grep -E "externalprovider.com|externaldistributor.com" | wc -l

This command outputs the precise count of outbound forwarded messages dispatched for that domain.

Best practices to manage email forwarders and protect IP reputation#

Based on these audit insights, here are practical rules to keep mail servers healthy:

1. Discourage blind forwarding to external personal accounts: Encourage users to configure their mail clients (Outlook, Thunderbird, mobile apps) directly using IMAP rather than forwarding all company email to free third-party inboxes.
2. Audit multi-destination forwarders regularly: Run the awk one-liner on /etc/valiases/ periodically to catch forwarders splitting messages into multiple external recipients.
3. Enable Sender Rewriting Scheme (SRS): In cPanel/WHM, verify that SRS is enabled under Service Configuration > Exim Configuration Manager > Enable Sender Rewriting Scheme. SRS rewrites the envelope sender so forwarded messages pass SPF validation at receiving mail servers.
4. Decommission forwarders on retired accounts: When employees leave, forwarders are frequently left active indefinitely. These abandoned aliases keep absorbing and forwarding newsletters and spam for years, draining outbound bandwidth.

Using command-line utilities like exigrep, awk, and eximstats gives you complete visibility into your server's true mail flows, going far beyond default web interface summaries.

See also

Email Domain Whitelist vs. RBL Blocking in cPanel and Exim: Why Whitelisting Fails and How DNSBLs Operate

Email Crontab kernel mechanics, Linux logging differences, and Exim mail spool maintenance

Email Anatomy of an email stuck in queue: mail server logs, domain typos, and Exim smarthost mechanics

This post is licensed under CC BY-NC.