451 4.7.1: delivery not authorized, try again later
A policy check on the receiving server deferred your message. The 4 means try again later; the 7.1 means delivery was not authorized under the receiver's policy.
What 451 4.7.1 means
An enhanced status code has three parts. The first digit is the class: 4 means a persistent transient failure that may succeed later. The middle number is the subject: 7 is security or policy. RFC 3463 defines X.7.1 as "Delivery not authorized, message refused": the sender is not authorized to send to the destination, as a result of per-host or per-recipient filtering.
RFC 3463 describes X.7.1 as useful only as a permanent error, yet the IANA registry lists 451 among the basic codes it appears with. When a receiver sends 451 4.7.1, it is using a policy reason with a temporary class: your mail is held back for now, not rejected for good. Greylisting, rate limits and reputation checks that may pass later are typical reasons. RFC 6647 describes greylisting as a 4xx deferral that a correctly retrying sender gets past.
The text after the code is the useful part. A first-contact deferral that succeeds on retry needs no action. A deferral that repeats for hours, especially one mentioning your IP, reputation or authentication, needs a fix on your side.
Likely causes
- Greylisting: the receiver defers first contact from an unknown sender.
- Your IP address or domain is being rate limited.
- A reputation or blocklist check that the receiver treats as temporary.
- SPF, DKIM or DMARC couldn't be confirmed at that moment.
How to fix it
If you sent the message
- Let your server retry. A greylisting deferral normally clears on a later attempt.
- If it repeats for hours, check your sending IP on public blocklists and confirm its PTR record.
- Make sure SPF and DKIM pass for the domain you send from.
If you're the recipient or their admin
- If a partner's mail is delayed, check your greylisting and rate-limit settings and allow their servers.
Frequently asked questions
What is the difference between 451 4.7.1 and 550 5.7.1?
Both report a policy decision against your message. With 451 4.7.1 the receiver is deferring it, so your server keeps it and retries. With 550 5.7.1 the receiver has refused it, and the message bounces back to you.
Is 451 4.7.1 always greylisting?
No. Greylisting is one common reason, but receivers also use temporary policy codes for rate limits and reputation checks. Read the text after the code. If the message gets through on a retry minutes later, greylisting is the likely explanation.
Sources
- RFC 3463: Enhanced Mail System Status Codes
- IANA: SMTP Enhanced Status Codes registry
- RFC 6647: Email Greylisting, an applicability statement for SMTP
Provider messages are quoted as the provider publishes them. Servers can change their wording, so the bounce you received may differ slightly.
Related codes
Related guides
How to get your domain or IP removed from an email blacklist
How to check if your mail server IP or domain is on a DNS blocklist, find the real cause, and request removal from Spamhaus, SpamCop, Barracuda and Microsoft.
9 min read Email security basicsHow do spam filters work?
How inbound spam filters decide what reaches your inbox: connection checks, reputation, SPF/DKIM/DMARC, content rules, attachment scans and quarantine.
9 min read SPF, DKIM & DMARCSPF vs DKIM vs DMARC: what each one proves, and what it doesn't
A plain-English comparison of SPF, DKIM and DMARC: what each checks, what it can't prove, how they work together, and where MTA-STS and BIMI fit.
8 min read