clement

451 4.7.1: Temporarily not authorized (greylisting or policy)

The receiver temporarily refused delivery for a policy reason, most often greylisting a sender it hasn't seen before.

Bounce type
Soft bounce (temporary)
What to do
Retry later
Returned by
Any mail server

What 451 4.7.1 means

4.7.1 is RFC 3463's 'Delivery not authorized, message refused' in its transient form. With 451, the receiver is saying it won't accept the message right now for a policy reason, and expects you to try again.

The classic cause is greylisting: the server rejects the first attempt from an unfamiliar sender IP + sender + recipient combination, and accepts it when a legitimate server retries a few minutes later. Spam tools that never retry are filtered out. Some filters also use 451 4.7.1 while a reputation lookup or rate check is pending.

Why cold emailers see 451 4.7.1

  • Greylisting on the recipient's server, common with self-hosted mail, smaller ISPs and some security gateways.
  • A new sending domain or IP with no history at that receiver.
  • Per-sender rate limits on the receiving side.
  • A reputation or DNS-based check that timed out and was deferred rather than failed.

How to fix 451 4.7.1

  1. Make sure your sending system actually retries 4xx responses. A proper MTA (and Gmail, Microsoft 365) does; some home-made scripts don't.
  2. Don't change the envelope sender or sending IP between attempts. Greylisting keys on that combination, so changing it resets the clock.
  3. If deferrals persist for more than a few hours at one domain, slow down and check whether your IP or domain is listed on a public blocklist.

Will it retry on its own?

Retry, don't suppress. A greylisted message is normally delivered on the second or third attempt, 5–30 minutes later.

Reading the code

The basic code 451 means "Local error in processing, action aborted (temporary)" under RFC 5321. In 4.7.1, the 4 is the class (persistent transient failure) and the 7 is the subject (security or policy). The detail number 1 is registered in RFC 3463 / the IANA registry as "Delivery not authorized, message refused".

Class 4
Persistent transient failure
A temporary condition delayed delivery. The message itself is valid, and sending again later may succeed.
Subject 7
Security or policy
A security or policy decision: spam filtering, authentication, blocklists, permissions.
Detail 4.7.1
Delivery not authorized, message refused

Check the rest of your setup

Paste the headers of a message that did get through into the email header analyzer to confirm SPF, DKIM and DMARC pass, and check your domain with the SPF, DKIM & DMARC checker. The deliverability checklist covers the rest of a healthy sending setup.

Got a different bounce? Paste it into the SMTP error code lookup to decode it.

FAQ

Is 451 4.7.1 a hard bounce or a soft bounce?

451 4.7.1 is a temporary failure (a soft bounce). Your sending server should retry automatically, and the message is often delivered on a later attempt. If it keeps failing for days, the server gives up and reports a final bounce.

Should I remove the contact after a 451 4.7.1 bounce?

No. Retry, don't suppress. A greylisted message is normally delivered on the second or third attempt, 5–30 minutes later.

What does 4.7.1 mean in the error code?

In 4.7.1, the 4 is the class (persistent transient failure) and the 7 is the subject (security or policy). The detail number 1 is registered in RFC 3463 / the IANA registry as "Delivery not authorized, message refused".

Related SMTP codes

See all SMTP error codes

Sources

Try Clement free for 14 days

Clement reads the bounces that land in your Gmail and SMTP inboxes and tells dead addresses apart from policy blocks: it suppresses the first across every campaign and keeps the contact on the second, so you don't have to decode bounces by hand.

Start free trial