The Exim black hole, DMARC alignment failures, and restoring IP reputation

Few issues in mail server administration cause more stress than watching a server's IP address land on reputation blocklists (RBLs) when no customer mailbox was compromised and no bulk spam campaign was sent.

Frequently, IP reputation degradation does not originate from external intrusions, but from silent feedback loops inside the server itself: autoresponders causing DMARC alignment failures, unrouted system notifications bouncing against Exim's spool, and continuous retry loops that trip heuristic monitors at providers like TrendMicro, Broadcom, and Google.

In this guide, we break down a real incident on an AlmaLinux server running cPanel and Exim, explain how the never_users directive impacts delivery, rule out secondary compromise vectors, and apply permanent CLI fixes.

1. Warning signs and error log analysis#

The investigation began after outbound delivery rejections surfaced across major email providers. Searching /var/log/exim_mainlog revealed three distinct failure signatures:

Signature 1: Relay rejection at messagelabs / broadcom#

2026-04-19 01:45:03 1wDRH7-00000003l3z-1Dde H=cluster9.us.messagelabs.com [67.219.246.213] SMTP error from remote mail server after RCPT TO:<[email protected]>: 453-you are trying to use me as a relay, but I have not been configured to let you [192.0.2.1, host.provider.com] do this.

The remote gateway issued error code 453 immediately following RCPT TO. This occurs when the recipient gateway treats the connection as unauthenticated open relay traffic, typically due to misaligned reverse DNS (PTR) records or missing authorizations in the recipient's edge security policies.

Signature 2: Heuristic block at trendmicro ers-qil#

2026-04-19 03:00:03 1wDiS5-00000004s2s-07As H=schulz.in.tmes.trendmicro.com [18.208.22.77] SMTP error from remote mail server after RCPT TO:<[email protected]>: 450 4.7.1 <[email protected]>: Recipient address rejected: Mail from <192.0.2.1> was refused due to the sender IP found in ERS-QIL.

Listing on TrendMicro ERS-QIL (Quick IP List) is dynamic and heuristic: when sensors observe spikes in connection rejections or deliveries to non-existent mailboxes (characteristic of backscatter), the sending IP is downgraded temporarily. This returns 450 4.7.1 codes that force Exim to spool and retry messages repeatedly.

Signature 3: Authentication failure rejection at Gmail#

2026-04-19 12:15:02 1wETrR-00000007cN3-3ZrX ** [email protected] ([email protected]) <[email protected]> R=dkim_lookuphost T=dkim_remote_forwarded_smtp H=gmail-smtp-in.l.google.com [172.253.122.27] : SMTP error from remote mail server after end of data: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. DKIM = did not pass, SPF [] with ip: [192.0.2.1] = did not pass

Google completed the initial SMTP handshake, but terminated the session with permanent error 550 right after receiving the end-of-data delimiter. The empty brackets in SPF [] indicate that the resolver could not locate a valid domain in Envelope-From during its real-time DNS lookup.

2. Root cause 1: autoresponders triggering DMARC alignment failures and backscatter#

Inspecting a spooled message with exim -Mvh 1wDRH7-00000003l3z-1Dde:

bertolisegurosco 1008 984
<[email protected]>
-ident clientuser
-received_protocol local
-auth_id clientuser
-auth_sender [email protected]
From: "[email protected]" <[email protected]>
Precedence: auto_reply
Subject: Email auto reply notification
X-Autorespond: Out of office automated response.

What these headers revealed#

1. Locally generated message: -received_protocol local and -auth_id clientuser confirm the message originated from the local /usr/local/cpanel/bin/autorespond utility, not an external compromised mailbox.
2. Mismatched From header: the user configured their display name using a different email address:

   From: "[email protected]" <[email protected]>

1. DMARC alignment failure: external validators compare the RFC 5321 Envelope-From (clientdomain.com) against the RFC 5322 visual Header-From (anotherclient.com). Because the domains did not match, recipient DMARC checks failed.
2. Replying to automated robots: the original email received by the mailbox was an automated notification from a no-reply address (donotreply@). The server autoresponder attempted to reply to a robot that rejects inbound messages, creating an escalating backscatter loop.

3. Root cause 2: the root alias black hole and the never_users directive#

Checking messages addressed to the server's own hostname (host.provider.com) using exim -Mvl:

2026-04-19 14:00:53 Received from <> R=1wEVVt-00000007hTy-051k U=mailnull P=local S=2279 T="Mail delivery failed: returning message to sender"
2026-04-19 14:00:53 [email protected] ([email protected]) <[email protected]> R=localuser_root : root cannot accept local mail deliveries
*** Frozen (delivery error message)

Why Exim rejects local deliveries to UID 0#

In Exim's compiled defaults, never_users prevents the MTA from delivering files directly into accounts with root privileges:

never_users = root

When system daemons (like CSF/LFD firewall alerts or cron jobs) dispatch mail to root, Exim processes the local router. Before writing to disk with setuid(0), it checks whether the destination UID is 0. Finding root, it aborts local delivery to prevent file overwrite exploits.

Frozen message pileup#

Because the notification was already a delivery status notification (Received from <>), Exim cannot generate a bounce of a bounce. The item is marked Frozen and stays in /var/spool/exim/input/.

Without an active alias configured in /etc/aliases, every system security alert froze on disk. On each scheduled queue run (exim -q), the MTA swept the spool and generated spurious connection attempts, degrading the server's sending reputation score.

4. Ruling out compromise vectors and rogue outbound traffic#

Before applying changes, verify that the server is not emitting unauthorized traffic:

Edge case 1: Raw socket traffic on port 25#

Confirm no background binary is bypassing Exim by opening direct sockets to external port 25:

# Add temporary logging rule in iptables
iptables -I OUTPUT -p tcp --dport 25 -m owner ! --uid-owner mailnull -j LOG --log-prefix "SMTP_BYPASS_ATTEMPT: "

# Monitor kernel logs in real time
dmesg -w | grep "SMTP_BYPASS_ATTEMPT"

If no non-mailnull UIDs appear, all outbound port 25 traffic originates from Exim.

Edge case 2: Inbound HELO spoofing#

External hosts attempting to masquerade as your server IP can pollute log searches:

grep "rejected MAIL" /var/log/exim_mainlog | grep -E "Invalid HELO|HELO name" | head -n 5

If logs show closed by DROP in ACL, the acl_check_helo rule is blocking incoming spoof attempts at connection time.

Edge case 3: Mail forwarding without sender rewriting scheme (SRS)#

When users forward mail to external providers like Gmail without envelope rewriting, SPF verification will fail. Verify SRS is enabled:

grep -i "srs" /etc/exim.conf

If missing, enable SRS in the cPanel Exim Configuration Manager to preserve SPF alignment on forwarded messages.

5. Command playbook for diagnosis and resolution#

Here are the terminal commands used to normalize the environment:

Step 1: Assign a valid non-privileged alias for root#

Direct root system mail to an active, monitored virtual mailbox:

# Add or update root alias in /etc/aliases
echo "root: [email protected]" >> /etc/aliases

# Rebuild the compiled aliases database
newaliases

# Test delivery routing for root
exim -bt root

Expected output:

[email protected]
    <-- [email protected]
  router = virtual_user, transport = dovecot_virtual_delivery

Step 2: Purge frozen messages from the spool#

Clean out accumulated delivery status notifications and loop remnants:

# Purge all frozen messages from the queue
exiqgrep -z -i | xargs -r exim -Mrm

# Flush legitimate pending deliveries
exim -qff -v

Step 3: Validate reverse DNS and SPF alignment#

Confirm that the server's public IP PTR matches its HELO hostname:

# Verify PTR alignment
host 192.0.2.1

# Check SPF TXT record
dig txt infrastructure.com +short

Operational habits to maintain high IP reputation scores#

Once root mail was redirected and the frozen spool was cleared, Exim ceased dropping internal system mail. Eliminating backscatter loops allowed the TrendMicro ERS-QIL sensors to register normal error ratios, removing the IP from blocklists within 24 hours.

Key takeaways for reliable operations:

1. Always maintain an active root alias: never leave root unrouted in /etc/aliases. System notifications must land in a valid mailbox to avoid spool freezing.
2. Monitor autoresponder configurations: ensure users do not embed third-party email addresses in display names, preventing DMARC alignment breaks.
3. Audit frozen queue volume regularly: run a simple cron check that flags administrators when frozen messages exceed twenty items in the spool.

See also

Email Anatomy of a dangling pointer in Exim: debugging the "transport not found" error in cPanel with smarthost and SRS

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

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

This post is licensed under CC BY-NC.