How to Fix '451 Temporary local problem - please try later' Error in Exim and cPanel

When an email transaction fails with the SMTP status code 451 Temporary local problem - please try later, the receiving Mail Transfer Agent (MTA)—in this case, Exim on a cPanel/WHM Linux server—is issuing a soft rejection (SMTP 4xx). Unlike a permanent 5xx bounce (such as 550 No Such User Here), a 451 error informs the connecting client or sending server that an internal system failure, scanner timeout, permission deadlock, or database lock prevented Exim from completing message validation or delivery routing.

Because the sending server treats this as temporary, it will queue the message and retry repeatedly (often every 15 to 60 minutes for up to 4 to 5 days). If the underlying server fault is not resolved, inbound mail queues swell, outbound deliveries stall, and legitimate senders eventually receive non-delivery notifications (NDRs).

This diagnostic runbook covers the architecture of Exim delivery phases in cPanel, the exact telemetry in /var/log/exim_mainlog, and how to resolve the five distinct root causes that produce this error.

---

Understanding Exim Architecture and the 451 SMTP Response

Exim processes inbound SMTP transactions through Access Control Lists (ACLs) and Router chains before passing messages to a transport (such as Dovecot’s lmtp or /usr/libexec/dovecot/dovecot-lda). The 451 error is emitted during either:

1. The acl_smtp_data or acl_smtp_predata Phase: Content inspection modules (ClamAV / cPanel MailScanner / SpamAssassin) fail to respond, return a socket communication error, or exceed execution time limits.
2. The Recipient Verification / Routing Phase: Exim attempts to read transport hints, verify domain ownership in /etc/localdomains, check quota databases, or evaluate sender reputation against DNSBLs, but encounters locked Berkeley DB files, missing files, or DNS timeouts.

In high-concurrency environments, such as multi-tenant hosting platforms or enterprise business mail servers, resource starvation frequently triggers these conditions. Organizations hosting mission-critical mail services often transition from noisy shared environments to Dedicated Servers or regionally tuned Dedicated Servers in Pakistan to ensure dedicated memory pools, unmetered I/O throughput, and isolated mail scanner processes.

---

Real-World Log Telemetry: Identifying the Fault

Before executing corrective commands, inspect /var/log/exim_mainlog and /var/log/maillog to extract the exact internal sub-condition. Exim records the failure reason directly following the recipient address:

# Stream live Exim rejections filtering on 451 errors
tail -fn0 /var/log/exim_mainlog | grep -E "451|Temporary local problem"

Log Signature A: Anti-Virus / ClamAV Daemon Deadlock

2026-10-12 14:22:01 1t9A1b-0004f2-H7 H=mail-out-01.externaldomain.com [198.51.100.25]:41234 F=<[email protected]> temporarily rejected after DATA: clamav-milter: connect to /var/clamd failed: Connection refused
2026-10-12 14:22:01 1t9A1b-0004f2-H7 H=mail-out-01.externaldomain.com [198.51.100.25]:41234 F=<[email protected]> 451 Temporary local problem - please try later

Log Signature B: SpamAssassin Socket Timeout

2026-10-12 14:35:10 1t9B8k-0005d1-Lk H=mail-sender.network.com [203.0.113.88]:58190 F=<[email protected]> temporarily rejected after DATA: spam acl condition: cannot test spam status: connect to spamd on /var/run/spamd.sock failed: Connection timed out

Log Signature C: Corrupted Spool Hint Database

2026-10-12 14:40:22 1t9CGm-0006e8-Px H=relay.partner.org [192.0.2.14]:39912 F=<[email protected]> temporarily rejected RCPT <[email protected]>: failed to expand ACL string "${lookup ratelimit:...}": Berkeley DB error: /var/spool/exim/db/ratelimit: DB_PAGE_NOTFOUND: Requested page not found

Log Signature D: DNS Resolver Timeout during RBL/RDNS Verification

2026-10-12 14:48:09 1t9DPa-0007g2-Mn H=mx.sourcehost.net [198.51.100.44]:52110 F=<[email protected]> temporarily rejected RCPT <[email protected]>: host lookup did not complete: DNS query timed out

Log Signature E: Domain Routing & Ownership Permission Failure

2026-10-12 14:52:15 1t9ESt-0008h4-Qv H=smtp.vendor.com [203.0.113.12]:44102 F=<[email protected]> temporarily rejected RCPT <[email protected]>: error in check_local_domains router: cannot read /etc/localdomains: Permission denied

---

Root Cause 1: ClamAV Daemon Socket Disconnects and OOM Terminations

In cPanel servers with ClamAV enabled via WHM (cPanel cAddons / Manage Plugins), Exim connects to clamd via a UNIX domain socket (typically /var/clamd or /var/run/clamav/clamd.sock).

Because ClamAV maintains virus signature databases containing millions of hash definitions, clamd consumes between 1.2 GB and 2.5 GB of resident RAM. On systems undergoing memory pressure, the Linux kernel Out-Of-Memory (OOM) killer frequently issues a SIGKILL to clamd. When an incoming email reaches the DATA ACL, Exim attempts to pipe the message payload to the dead socket, encounters Connection refused, and issues the 451 error.

Diagnostic Steps

Verify if clamd is running and check whether it was terminated by the OOM killer:

# Check service status via cPanel service manager
/scripts/restartsrv_clamd --status

# Check system journal and dmesg for OOM killer invocations
dmesg -T | grep -i -E "clamd|oom-killer|killed process"
journalctl -u clamd -n 50 --no-pager

Verify socket permissions and ownership:

ls -la /var/clamd /var/run/clamav/clamd.sock

The socket must be owned by the service user and readable by the mailnull or exim user.

Remediation

1. Restart the ClamAV Daemon:

   /scripts/restartsrv_clamd

2. Fix Socket Permissions: If the socket path is /var/clamd, ensure mailnull has access to the enclosing directory:

   chmod 755 /var
   chmod 777 /var/clamd

3. Configure Memory Limits in cPanel: In WHM, navigate to Service Configuration → Service Manager. Ensure ClamAV Daemon is monitored by ChkServd. If memory constraints are persistent, assign swap space or configure clamd resource overrides in /etc/systemd/system/clamd.service.d/override.conf:

   [Service]
   OOMScoreAdjust=-500
   Restart=always
   RestartSec=5s

   Apply the systemd change:

   systemctl daemon-reload
   systemctl restart clamd

---

Root Cause 2: SpamAssassin Daemon (spamd) Timeout Exhaustion

Exim evaluates message spam metrics inside the acl_smtp_data block using spamd. When incoming connection rates exceed the configured number of SpamAssassin child processes (--max-children), or when SpamAssassin plugins (such as Pyzor, Razor2, or DCC) hang on external network queries, Exim’s socket read call hits its timeout limit (default: 30 seconds).

Exim handles an unresponsive anti-spam socket by failing closed with 451 Temporary local problem.

Diagnostic Steps

Inspect active spamd processes and check Exim active workers:

# Check active spamd processes
ps aux | grep spamd

# Check what Exim processes are currently waiting on
exiwhat

# Inspect SpamAssassin log messages
grep -i "spamd: timeout" /var/log/maillog

Remediation

1. Increase SpamAssassin Child Workers: Edit /etc/sysconfig/spamd (on RHEL/CentOS/AlmaLinux) or navigate to WHM → Service Configuration → Exim Configuration Manager → Apache SpamAssassin Options:

   # In /etc/sysconfig/spamd
   SPAMDOPTIONS="-d -c -m 10 --timeout-child=15"

   Adjust -m (max children) according to available physical RAM (allocate ~60 MB per worker).

2. Reduce DNS Latency in SpamAssassin Plugins: If external blacklists are delaying processing, configure localized timeouts in /etc/mail/spamassassin/local.cf:

   rbl_timeout 3
   clear_headers
   bayes_auto_learn 1

3. Restart the SpamAssassin Daemon:

   /scripts/restartsrv_spamd

---

Root Cause 3: Corrupted Exim Spool Hint Databases

Exim uses Berkeley DB files located in /var/spool/exim/db/ to track operational metadata:

• ratelimit: Tracks sender and IP transaction rates.
• retry: Maintains host retry schedules for deferred deliveries.
• wait-remote_smtp: Tracks active connections to destination mail servers.
• callout: Caches sender callout verification results.

If the server experiences an unexpected reboot, power outage, high disk latency, or an Exim process termination while writing to these database files, the .db files can become corrupted. Subsequent Exim worker threads encountering a corrupted page or lock conflict will abort routing and return 451 Temporary local problem.

Diagnostic Steps

Examine /var/spool/exim/db/ for database corruption warnings:

# Check Exim mainlog for Berkeley DB errors
grep -i "Berkeley DB" /var/log/exim_mainlog

# Inspect the directory contents and file sizes
ls -lh /var/spool/exim/db/

Test database integrity using Exim internal maintenance tools:

/usr/sbin/exim_tidydb -t 1d /var/spool/exim retry
/usr/sbin/exim_tidydb -t 1d /var/spool/exim ratelimit

If this outputs DB_PAGE_NOTFOUND or Invalid argument, the hint files are corrupted.

Remediation

Because files in /var/spool/exim/db/ are volatile operational caches, they can be safely flushed and rebuilt without losing queued mail messages:

# 1. Stop Exim to release file locks
/scripts/restartsrv_exim --stop

# 2. Archive and remove corrupted database files
mkdir -p /root/exim_db_backup
mv /var/spool/exim/db/* /root/exim_db_backup/

# 3. Recreate the DB directory structure with correct permissions
mkdir -p /var/spool/exim/db
chown -R mailnull:mail /var/spool/exim/db
chmod 750 /var/spool/exim/db

# 4. Start Exim
/scripts/restartsrv_exim --start

Exim will automatically regenerate clean Berkeley DB files upon the next transaction.

---

Root Cause 4: DNS Resolver Timeouts during Reverse DNS and RBL Lookups

During the initial connection handshake (acl_smtp_connect and acl_smtp_rcpt), Exim performs several synchronous DNS queries:

1. Reverse DNS (PTR) lookup of the connecting client IP.
2. Forward DNS (A/AAAA) lookup of the resulting hostname to verify FQDN consistency.
3. DNSBL / RBL reputation queries (e.g., Zen Spamhaus, SpamCop, Barracuda).

If the nameservers configured in /etc/resolv.conf are unreachable, dropping packets, or rate-limiting queries, Exim threads stall until the internal resolver timeout expires. If the ACL enforces strict sender verification, this timeout aborts the handshake with 451 Temporary local problem or 451 Host lookup did not complete: DNS query timed out.

Public Resolver Rate-Limiting Trap

Using public resolvers like 8.8.8.8, 1.1.1.1, or 9.9.9.9 in /etc/resolv.conf on a mail server frequently causes Spamhaus and other RBL providers to return NXDOMAIN or query-refused error codes (127.255.255.254). When Exim cannot parse the query error response correctly under load, connections fail with 451.

Diagnostic Steps

Test local DNS resolution latency and RBL response times:

# Benchmark PTR lookup latency
time dig -x 198.51.100.25

# Check if public resolvers are blocking RBL queries
dig 2.0.0.127.zen.spamhaus.org +short

If the query to Spamhaus returns 127.255.255.254 (Blocked/Refused query due to open resolver usage), your server cannot validate senders through public DNS.

Remediation

1. Deploy a Local Caching Resolver (Unbound or BIND): Install and enable a local caching resolver that performs root iteration rather than forwarding through shared public resolvers:

   # Install unbound on AlmaLinux / Rocky Linux
   dnf install -y unbound
   systemctl enable --now unbound

2. Update /etc/resolv.conf: Configure /etc/resolv.conf to query the loopback address first:

   nameserver 127.0.0.1
   nameserver 127.0.0.53
   options timeout:2 attempts:2

3. WHM Configuration Check: In WHM, navigate to Networking Setup → Resolver Configuration. Ensure primary and secondary resolvers point to local datacenter caching nameservers rather than public recursive resolvers.

---

Root Cause 5: Domain Routing and Ownership in /etc/localdomains vs /etc/remotedomains

cPanel routes email destinations using two configuration files:

• /etc/localdomains: Domains for which Exim accepts and stores messages locally into user maildirs.
• /etc/remotedomains: Domains whose mail is handled elsewhere (e.g., Google Workspace, Microsoft 365), instructing Exim to route outbound to external MX records without performing local mailbox delivery.

If a domain is absent from both files, or if file permissions prevent the exim / mailnull user from reading them, Exim’s local delivery router (check_local_domains) fails with an internal routing error, resulting in a 451 response.

Diagnostic Steps

Use Exim’s built-in address test mode (-bt) to trace recipient routing:

# Test address routing for a recipient domain
exim -bt [email protected]

If the domain routing fails due to a configuration mismatch, output similar to the following will appear:

[email protected] cannot be resolved at this time:
  error in check_local_domains router: cannot read /etc/localdomains: Permission denied

Verify permissions and file attributes:

ls -la /etc/localdomains /etc/remotedomains /etc/userdomains

The correct file ownership is root:mail with permissions 0644.

Remediation

1. Reset File Ownership and Permissions:

   chown root:mail /etc/localdomains /etc/remotedomains /etc/userdomains
   chmod 644 /etc/localdomains /etc/remotedomains /etc/userdomains

2. Rebuild the Exim User and Domain Maps: Run cPanel’s built-in mail configuration generators:

   /scripts/updateuserdomains
   /scripts/buildeximconf

3. Verify Routing Selection in cPanel: If a client recently configured an external mail provider, confirm their routing mode in WHM → DNS Functions → Email Routing Configuration or cPanel’s Email Routing interface. Ensure the domain is designated as Local Mail Exchanger if mailboxes reside on the server, or Remote Mail Exchanger if hosted externally.

---

Command Reference: Sysadmin Diagnostic Toolkit

Keep these essential Exim CLI diagnostic commands ready during active troubleshooting:

Command	Function	Target Diagnosis
exim -bp	Displays the current mail queue status	Detects queue spikes and stuck deliveries
exim -bt <email>	Runs address routing resolution test	Validates /etc/localdomains and router rules
exim -bh <ip>	Simulates an SMTP session from an IP	Traces ACL evaluation step-by-step
exiwhat	Shows what each Exim worker is currently doing	Identifies hung child processes or deadlocks
exim_dbmbuild	Compiles DBM database files	Validates DBM format integrity
exim_tidydb <spool> <db>	Cleans old records from Exim hint databases	Diagnoses corrupted database structures
/scripts/buildeximconf	Re-compiles /etc/exim.conf from cPanel templates	Fixes syntax errors and missing macros
/scripts/restartsrv_exim	Restarts the Exim MTA service	Restores service after configuration updates

---

Step-by-Step Resolution Runbook

Follow this sequential checklist to diagnose and resolve a live 451 incident systematically:

[Incoming Mail Failure: 451 Temporary local problem]
                         │
                         ▼
        Inspect /var/log/exim_mainlog
                         │
         ┌───────────────┼───────────────┬────────────────┬──────────────┐
         ▼               ▼               ▼                ▼              ▼
   [ClamAV Down]   [spamd Timeout] [DB Corrupt]     [DNS Timeout]  [Router Fault]
         │               │               │                │              │
   Restart clamd    Increase -m     Flush /var/      Fix resolv.conf Check /etc/
   Fix /var/clamd   Adjust child    spool/exim/db    Deploy local   localdomains
   permissions      timeout         Restart Exim     caching DNS    Run buildeximconf
         │               │               │                │              │
         └───────────────┴───────────────┼────────────────┴──────────────┘
                                         ▼
                            Run: exim -bt [email protected]
                                         │
                                         ▼
                            Simulate: exim -bh <client-ip>
                                         │
                                         ▼
                            Verify clean queue: exim -bp

1. Identify the Specific Root Cause

Run the live log monitor to capture the failing transaction ID:

grep "451 Temporary local problem" /var/log/exim_mainlog | tail -n 20

2. Isolate and Recover the Failing Subsystem

• If ClamAV: Execute /scripts/restartsrv_clamd. Verify socket existence.
• If SpamAssassin: Execute /scripts/restartsrv_spamd. Increase workers if CPU permits.
• If Spool DB: Move /var/spool/exim/db/* to a backup location and restart Exim.
• If DNS: Test nameserver queries using dig and configure local caching nameservers.
• If Permissions: Restore root:mail permissions on /etc/localdomains and run /scripts/buildeximconf.

3. Verify Address Resolution

Simulate message receipt for an affected recipient to verify that Exim resolves the router pipeline:

exim -bt [email protected]

4. Perform an End-to-End SMTP Handshake Simulation

Use Exim’s debug mode (-bh) to trace every ACL statement without sending real data:

exim -bh 198.51.100.25

During the simulated session, enter:

HELO mail.sender.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Test Diagnostic
This is a test body.
.
QUIT

Exim will display verbose ACL evaluation steps, confirming whether clamd, spamd, rate-limiting databases, and DNS lookups succeed.

---

Long-Term Server Hardening and Prevention

To prevent 451 errors from recurring on production mail infrastructure, implement these hardening measures:

1. Configure Exim Scanner Fail-Open Fallbacks

If high availability takes precedence over strict quarantine during scanner degradation, configure Exim to fail open rather than rejecting incoming mail when scanners timeout.

In WHM → Exim Configuration Manager → Advanced Editor, locate the acl_smtp_data custom section and wrap scanner calls with conditional timeout handling:

warn
  condition = ${if def:acl_m_clamav_failed}
  logwrite  = CLAMAV FAILURE: Message accepted without virus scan due to scanner timeout

2. Protect Server Memory and Swap Space

To prevent clamd and spamd from being terminated by the OOM killer, calculate memory headroom accurately. Reserve at least 3 GB of free RAM for mail filtering on servers processing over 50,000 messages daily. Ensure at least 4 GB to 8 GB of swap space is active on high-volume systems:

# Verify active swap space
swapon --show
free -m

3. Schedule Spool Maintenance

Add a weekly cron task to clean old records from Exim hint databases before fragmentation leads to corruption:

# /etc/cron.weekly/exim_tidy.sh
#!/bin/bash
/usr/sbin/exim_tidydb -t 7d /var/spool/exim retry >/dev/null 2>&1
/usr/sbin/exim_tidydb -t 7d /var/spool/exim ratelimit >/dev/null 2>&1
/usr/sbin/exim_tidydb -t 7d /var/spool/exim wait-remote_smtp >/dev/null 2>&1

Make the script executable:

chmod +x /etc/cron.weekly/exim_tidy.sh

---