A 451 reply means the server started handling your message and then hit an internal problem. RFC 5321 gives the base text as "Requested action aborted: local error in processing". It is a temporary class of error, so a well-behaved sender queues and retries, but it often points at something broken on the server that said it. First work out which server that is.
postfix/smtpd[2210]: NOQUEUE: reject: RCPT from unknown[203.0.113.50]: 451 4.3.0 <user@example.com>: Temporary lookup failure; from=<a@sender.test> to=<user@example.com> proto=ESMTP helo=<mail.sender.test>
postfix/smtp[3380]: 5C0E31A2B: to=<bob@example.net>, relay=mx.example.net[198.51.100.9]:25, delay=33, dsn=4.3.0, status=deferred (host mx.example.net[198.51.100.9] said: 451 4.3.0 Mail filter failure, try again later (in reply to end of DATA command))
The first line is your own server refusing a sender. The second is a remote server refusing you. The log prefix (smtpd for inbound, smtp for outbound) tells you which.
Causes, most likely first
- A lookup the server depends on is failing: a database, LDAP directory, SQL map or DNS resolver (the "Temporary lookup failure" text).
- A content filter or policy service is down: SpamAssassin, Rspamd, ClamAV, amavis, a milter, or a policy daemon like postgrey or an SPF checker.
- Disk or inode exhaustion on the spool or temp partition.
- Resource limits: memory, file descriptors, process limits.
- Greylisting or rate limiting presented as 451 4.7.x by some filters.
- A bug or outage at the remote provider. Gmail uses 451 4.3.0 for "Email server has temporarily rejected this message".
Step 1: find which side owns it
Outbound deferral to a remote relay= is theirs. Inbound reject from smtpd is yours. If it is theirs, wait and watch the queue; if it persists beyond a few hours, verify the recipient's MX with the MX Lookup and test port 25 with the Port Checker, then contact their admin with the log line.
Step 2: if it is your server, read the matching error
Look a few lines before the 451 in /var/log/mail.log (or /var/log/maillog, or journalctl -u postfix). The real cause is usually logged just above.
sudo grep -E "warning|error|fatal|panic" /var/log/mail.log | tail -n 30
df -h /var/spool/postfix /tmp
df -i /var/spool/postfix
free -m
Typical findings:
warning: dict_mysql: ... server has gone awayorconnect to ldap: restart or fix the backend. The 451 will keep coming until the lookup works.connect to 127.0.0.1:10024: Connection refused: the content filter (amavis, Rspamd proxy) is not listening. Start it and set it to restart on failure.No space left on device: free space; see the next section.warning: Unable to look up ... Temporary failure in name resolution: your resolver is down; check/etc/resolv.confand test withdig example.com. The DNS Checker helps verify the domain resolves from outside.
Step 3: check disk, inodes and memory
A full spool is a classic cause. Mail needs space for the queue plus temp files for filters:
sudo du -sh /var/spool/postfix/* 2>/dev/null | sort -h | tail -n 5
sudo postqueue -p | tail -n 1 # number of queued requests
If a huge queue of undeliverable bounces is eating space, find the root cause first (for example a compromised account sending spam) before purging anything. Look at postqueue -p sender addresses. Deleting the queue with postsuper -d ALL discards legitimate mail as well, so use it only deliberately.
Step 4: make failures fail fast and loud
Keep your filter services supervised. In systemd, set Restart=on-failure for them and monitor the ports. A mail server that returns 451 due to a dead filter delays all inbound mail but loses none, so you only notice from user complaints unless you monitor. Add an Uptime Monitor with a TCP check on port 25 or 587 and alerts to your own address on a different mail system.
Step 5: remote 451 on bulk or reputation grounds
If the remote text says "temporarily rejected", "try again later" or references reputation, treat it like throttling: check your IP on the Blacklist Checker, authentication on the Email DNS Checker, and slow the send rate. The Email Deliverability Test can flag the likely trigger.
How to verify
After the fix, send a test message to a local mailbox and from it to an external address. In the log you should see status=sent and no 451 lines for the same time window. sudo postqueue -f flushes deferred mail so you see results immediately.
Next steps
- See SMTP 421 service not available when the whole connection is refused.
- Read SMTP 452 insufficient storage for disk-specific cases.
- Set up uptime monitoring for your mail ports.
- Check email bounce codes explained.
FAQ
Will the message be lost?
Not if the sending server queues and retries, which standard MTAs do. It is only lost once the queue lifetime expires, 5 days by default in Postfix.
Is 451 my fault or theirs?
It depends on who sent it. Your smtp process log shows the remote host that replied, while smtpd lines show your own server rejecting a sender.
Can 451 mean greylisting?
Yes, some filters answer 451 4.7.1 for greylisting. The retry accepts the message after the delay.
What is the difference between 451 and 421?
421 closes the connection and says the service is unavailable; 451 aborts one command or transaction because of a processing error. Both are temporary.
Get notified when this fix updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.