451 4.7.1: Temporarily deferred, often greylisting

At a glance

• Type: temporary failure (class 4, RFC 3463 §2). The sending server keeps the message and retries later (RFC 5321 §4.5.4.1); it bounces only if the problem lasts until the message expires.
• Basic code 451: “Requested action aborted: local error in processing” (RFC 5321 §4.2.3).
• Enhanced code 4.7.1: “Delivery not authorized, message refused” in the IANA registry (RFC 3463), in the group security or policy status (RFC 3463 §3.8).

A 451 4.7.1 reply means "not now, try again later". Very often it is greylisting: the receiving server turns away a sender it has not seen before and accepts the same message when it comes back.

What it means

The 451 code is a transient failure (RFC 5321 §4.2.1): the client keeps the message and retries. The enhanced code X.7.1 means delivery was not authorized, the result of filtering per host or per recipient (RFC 3463 §3.8). RFC 3463 calls X.7.1 useful only as a permanent error, but servers send 4.7.1 anyway to mean "not now"; RFC 6647 §5 makes no specific recommendation for the 4xx code a greylisting server uses.

How greylisting works

RFC 6647 describes greylisting. The receiving server remembers who has tried to send to it. An unknown client gets a temporary refusal. A normal mail server queues the message and tries again later; by then it is known, and the message goes through. Software that sends once and never retries is filtered out. RFC 6647 §2 lists the points where a server can do this: on connect, at HELO/EHLO, at MAIL, at RCPT, or after DATA.

451 4.7.1 is a common greylisting reply, but not the only one. Other greylisting setups answer with other 4xx codes, and the text often says "greylisted" or asks you to try again later.

Common causes

• First message from a new IP address, or for a new sender and recipient pair.
• Retries leave from a different IP each time (a large sending pool), so every attempt looks new.
• Your server retries before the receiver's waiting period has passed.
• Not greylisting at all: a temporary policy block or rate limit that uses the same code.

How to fix it

1. For a single deferral, do nothing. Let your server retry. RFC 5321 §4.5.4.1 says retries should be at least 30 minutes apart, with a give-up time of generally at least 4 to 5 days.
2. Check that your system retries at all. A script or app that talks SMTP directly may treat any error as final. Send through a real mail server or relay that keeps a queue.
3. If you send from a pool, retry from the same IP when you can.
4. If the deferral lasts for days, it is not greylisting. Read the text after the code and contact the recipient's postmaster.
5. If you run the receiving server, RFC 6647 §2.7 covers exceptions, such as known partners you do not want to delay.

What to do with the address

Keep it. A greylisting deferral says nothing about the mailbox. If the message finally expires in the queue, see 4.4.7 and look at the last error your server recorded.

Related codes

• 421 4.7.0: Temporarily refused: reputation, DNS or TLS
• 550 5.7.1: Delivery not authorized: refused for policy reasons
• 450 4.2.1: The recipient is receiving mail too fast: try later

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.