451 Temporary local problem: it is your server, not the recipient

451 Temporary local problem - please try later is a message from your own mail server, not

from the recipient's. The word "local" is the whole diagnosis: Exim generated this reply while

your message was still in its hands, before any connection to the destination MX was attempted.

The recipient address is irrelevant, their mailbox is fine, and checking their DNS will waste

your afternoon.

It is also a 4xx, which means transient. The message is still in your queue. Nothing has

bounced yet.

Who sent it

If you are on a cPanel, DirectAdmin or Plesk host, or any shared hosting with mail, your outbound

MTA is Exim and this string is Exim's. The equivalent from Postfix reads `451 4.3.0 Error: queue

file write error, and Gmail's unrelated-but-similar reply is 451 4.3.0 Mail server temporarily

rejected message`. Only Exim phrases it as "temporary local problem".

Confirm it in one command:

$ exim -bp | head
 2h  4.1K 1xQpZa-0003Jk-7B <sender@yourdomain.com>
          test@mailpilots.in

$ grep -n "1xQpZa-0003Jk-7B" /var/log/exim_mainlog
2026-10-14 09:12:03 1xQpZa-0003Jk-7B <= sender@yourdomain.com H=localhost ... S=4213
2026-10-14 09:12:04 1xQpZa-0003Jk-7B == test@mailpilots.in R=dkim_lookuphost T=remote_smtp
   defer (-53): retry time not reached for any host
2026-10-14 09:12:04 1xQpZa-0003Jk-7B Temporarily rejected after DATA:
   malware acl condition: clamd: unable to connect to UNIX socket

The == line is a deferral, not a failure. The line underneath it is the actual reason, and in

this case it is unambiguous: the virus scanner socket is down.

The five causes, in order of how often they are the answer

1. ClamAV or SpamAssassin is not running. Exim's ACL calls the scanner over a UNIX socket at

DATA time. If clamd or spamd is stopped, dead or out of memory, the ACL defers every

message and the log says Temporarily rejected after DATA. Restart the scanner, then find out

why it died - on small VPSes it is usually the OOM killer.

1. The spool disk is full, or inodes are exhausted. Exim cannot write the queue file, so it

defers at acceptance. df -h /var tells you about space; df -i /var tells you about inodes,

and a mail spool with millions of tiny files runs out of inodes long before it runs out of

gigabytes.

1. An ACL fails to expand after a control-panel update. cPanel and DirectAdmin rewrite

/etc/exim.conf on update. A custom ACL or filter referencing a file or variable that no

longer exists produces an expansion failure, and Exim's safe behaviour on expansion failure is

to defer. The log line names the ACL.

1. Sender verification defers. With verify = sender in the ACL, Exim performs a callout to

the sender domain's MX. If that callout times out, the verification defers and so does your

message. A related and very common variant is `lowest numbered MX record points to local

host`, which means your server believes it is the final destination for a domain it is

actually trying to send to - usually a leftover local domain entry after a DNS move.

1. Per-account rate limits. Shared hosts apply ratelimit ACLs per hosting account. Exceed

the per-hour allowance and every subsequent message defers until the window moves.

How long before it becomes a bounce

Exim retries on the schedule in its retry configuration. The common default retries frequently

for the first few hours, then with growing intervals, and gives up after several days - four days

is a typical configured cutoff on cPanel hosts, and the RFC-recommended floor is four to five

days. Only when the retry timeout expires does the message become a real bounce, at which point

the sender receives a delivery status notification and the class changes from 4xx to permanent.

Check your own cutoff rather than assuming:

$ grep -A5 "^begin retry" /etc/exim.conf
begin retry
*  *  F,2h,15m; G,16h,1h,1.5; F,4d,6h

That reads: fixed 15-minute retries for 2 hours, then geometric backoff for 16 hours, then every

6 hours up to 4 days.

The ordered fix

1. Find the message in the queue with exim -bp, and get its full log with

exim -Mvl <msgid>.

1. Read the line after the `==` deferral. That is the cause. Do not proceed on a guess.
2. Check disk and inodes - df -h and df -i. Five seconds, and it rules out the cause that

is hardest to spot from the log alone.

1. Check the scanners are up - systemctl status clamav-daemon spamassassin, or your host's

equivalents.

1. Only then flush the queue, once, with exim -qf. If the underlying cause is unfixed the

messages will simply defer again.

What not to do

• Do not loop `exim -qff`. Forcing the queue repeatedly against a broken scanner socket

generates load and log noise and delivers nothing. Fix the cause, flush once.

• Do not count this as a bounce or suppress the recipient. No connection to their server was

ever made. A classifier that matches on 451 and suppresses the address removes a valid

contact.

• Do not count it against your sender reputation either. The rejection happened inside your

own infrastructure. No receiving provider saw it, so none of them formed an opinion.

• Do not delete the queued messages to "clear the error". They are deliverable; the deferral

is a hold, not a verdict.

• Do not raise your rate limits to get past cause five. If a shared host is rate-limiting

you, the correct move is fewer messages per hour or a dedicated sending path, not a higher

ceiling on a shared server.

MailPilot does not run your Exim, but it does make the distinction visible: because it tracks

per-mailbox reputation and per-provider inbox placement separately, a deferral that never left

your own host shows up as a stalled send rather than as a reputation problem - which stops you

"fixing" a healthy domain while the real fault sits in a stopped scanner process.