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
- Make sure your sending system actually retries 4xx responses. A proper MTA (and Gmail, Microsoft 365) does; some home-made scripts don't.
- Don't change the envelope sender or sending IP between attempts. Greylisting keys on that combination, so changing it resets the clock.
- 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.