SMTP Error 451: Requested Action Aborted. Local Error, Greylisting and Temporary Failures

A 451 reply is a polite "not now, and not by me". In the SMTP standard it means "requested action aborted: local error in processing". It is a temporary failure, written with a leading 4, and the sending server is expected to keep the message in its queue and try again. That makes 451 less alarming than a 550, but it is also easy to ignore for too long. Many 451 replies clear on the next attempt: a greylisting delay, a brief overload, a database restart on the receiving side. Others are the first sign of a real problem, such as a reputation-based throttle, a broken DNS setup on your side or a receiving server whose content scanner never finishes. This guide explains what the code promises, lists the causes in order of frequency, shows how to read the text that accompanies it, gives the commands to inspect your queue on the common mail servers, and explains how to decide between waiting, changing something and escalating.

What 451 means

SMTP replies that begin with 4 are "transient negative completion" replies. They mean the command failed, the failure may not be permanent and the client may try again. RFC 5321 gives each of the common 4xx codes a meaning: 421 is the service closing the channel, 450 is a mailbox that is temporarily unavailable, 451 is a local error in processing, and 452 is insufficient storage or too many recipients. In practice, servers are not strict about this, and 451 has become the general-purpose temporary deferral for anything from a database error to a deliberate delay. The enhanced code tells you more. 4.3.0 is a temporary mail-system problem, 4.4.1 is no answer from the host, 4.4.2 is a connection that was lost, and 4.7.x is a policy or security deferral, which includes greylisting and reputation throttles. Our guide to SMTP reply codes explains the numbering, and the article on 421 and 4.7.0 deferrals covers the sibling code.

The common causes

1. Greylisting

Greylisting is an anti-spam technique. The receiving server notes the combination of sender, recipient and connecting IP address the first time it sees it, answers with a temporary failure and accepts the message only when the same sender retries after a delay, typically a few minutes. Spam software that does not retry never gets through. A typical reply is 451 4.7.1 Greylisted, please try again in 300 seconds. The cost for you is a delay on the first message to each new recipient. Nothing needs fixing, though you should make sure your retry schedule is not too slow, because a first retry after an hour makes every first message late. Our article on queued, deferred and greylisted mail explains how to recognise it.

2. A fault on the receiving server

"Local error in processing" is often literal. The receiving server ran out of disk space or memory, lost its connection to a mailbox database or directory, or restarted a service while your message was in flight. Typical texts are 451 4.3.0 Temporary local problem, 451 Requested action aborted: local error in processing and 451 4.3.2 System not accepting network messages. These clear when the receiving administrators fix them. If you see them for one domain only and for a short time, wait.

3. Rate limiting and reputation throttles

Large providers answer volume they do not yet trust with temporary failures. Microsoft, for example, uses text such as 451 4.7.650 for IP-based rate limiting, and others use 451 4.7.0 or 451 4.7.1 with wording about "too many messages" or "temporarily rate limited". These are deliberate. They tell you to slow down while the receiver learns whether your mail is wanted. Follow the approach in rate limits, retries and backoff, and do not open extra connections to push the messages through.

4. DNS problems on your side or theirs

A receiver that cannot verify your sender domain, your reverse DNS or your HELO name may defer you instead of rejecting you outright: 451 4.1.8 Domain of sender address does not exist or 451 4.7.1 Client host rejected: cannot find your hostname. Check forward and reverse DNS for your sending IP, and the DNS of your envelope sender domain. The article on sender domain not found shows the commands.

5. Content scanning and timeouts

If the receiving side runs a virus or spam scanner that is slow or down, the server may answer 451 4.4.1 or 451 4.5.0 Content scanner temporarily unavailable. Large attachments make this more likely. The fix is on their side, but you can help by keeping messages small; see email size limits and MIME overhead.

6. Too many connections or simultaneous deliveries

Some servers limit the number of simultaneous connections or messages per client address and answer the surplus with a 451 or a 421. This is common on small servers and shared hosts. Reduce your parallelism to that domain.

How to read the text

The first words of the reply usually name the reason. The table shows the shapes you will meet and how to react.

Inspect your own queue

If you run the sending server, check what is waiting and why. Each system keeps the last reply from the remote server next to the queued message.

# Postfix
postqueue -p | head -50          # list queued messages with deferral reasons
postqueue -f                     # try again now (use sparingly)
postcat -q QUEUEID               # read one queued message

# Exim
exim -bp                         # list the queue
exim -Mvl MESSAGEID              # show the delivery log of one message

# Sendmail
mailq

Look at the reason column. A few messages with greylisting or a short local error are normal. Hundreds of messages for the same recipient domain with the same reason mean a systematic problem: check whether the domain is a large mailbox provider, whether you sent a spike of mail and whether authentication and reverse DNS are correct. Do not flush the queue repeatedly. Each forced attempt counts as another connection, and repeated attempts against a server that is throttling you extend the problem.

Retry settings that fit 451

The retry schedule is what turns a temporary failure into either a delay or a loss. A sensible schedule retries soon after the first failure (a few minutes, to cover greylisting), then spaces attempts further apart (ten minutes, half an hour, a few hours) and gives up after several days. Postfix uses minimal_backoff_time and maximal_backoff_time with maximal_queue_lifetime, and Exim uses retry rules. Make sure the first retry is not hours away, or every greylisted message will arrive hours late. For time-sensitive mail, such as one-time passcodes, set a shorter queue lifetime and tell the user to request a new code, since a code that arrives after twenty minutes is useless. The design of such flows is covered in password reset and OTP email best practices.

When a 451 is actually a problem

• The same domain defers you for more than a day. After the queue lifetime the message becomes a bounce. Investigate before then.
• The text mentions reputation, complaints or policy. Treat it as an early warning and read the guidance in the deferral guide, then check blocklists with the blocklist check steps.
• Only your mail is deferred. Other senders reach the same recipients. The issue is your IP, domain or setup, not theirs.
• The rate of 451 replies is rising. Add 451 counts per receiving domain to your monitoring; see delivery monitoring and alerts.
• You are the receiver and your own users complain. Check disk space, the mailbox database, the directory service, the scanner and the greylisting configuration.

If you operate the receiving server

Tune greylisting so it protects without harming. Use short delays, whitelist well-behaved large providers, store entries for days, not minutes, and make sure the message in the reply is clear. Monitor the queue for local errors so you find them before senders do. Keep disk, memory and database connections healthy, and give scanners enough capacity. A temporary failure is a promise that you will accept the message later, so make sure you can.

References and further reading

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• Postfix documentation: Postfix Queue Scheduler