4.7.1

Enhanced Status Code 4.7.1: Delivery Not Authorized - Temporary

Temporary failure High severity Security RFC 3463
What it means

Enhanced Status Code 4.7.1 means “Delivery Not Authorized - Temporary.” The receiving server is refusing your message on security or policy grounds but is inviting a retry. Greylisting, a missing reverse DNS record, rate limiting, and temporary blocklist hits all surface as 4.7.1. It is a soft bounce and must never be suppressed like its permanent twin 5.7.1.

At a glance
Code4.7.1
Bounce typeSoft (temporary)
SeverityHigh
CategorySecurity
What to doQueued and retried automatically
StandardRFC 3463
What it looks like in your mail logs 
450 4.7.1 <[email protected]>: Recipient address rejected: Greylisted, try again in 300 seconds

What does 4.7.1 mean?

Enhanced status code 4.7.1 breaks down as class 4 (a transient failure worth retrying), subject 7 (security or policy), and detail 1 (delivery not authorized, message refused). In plain terms, the receiving server has made a deliberate policy or security decision against your message and is telling your sending server to try again later. It arrives attached to a 421, 450, 451, or 452 reply code, and the reply code tells you at which stage of the SMTP conversation the refusal happened.

There is a well-known gap between the specification and practice here. RFC 3463 defines X.7.1 and then notes that it "is useful only as a permanent error", yet the 4.x form is one of the most frequently emitted deferral codes on the internet. Postfix returns "450 4.7.1 Client host rejected: cannot find your hostname" when reverse DNS lookup fails, greylisting implementations return "450 4.7.1 Recipient address rejected: Greylisted", and Microsoft Exchange returns "451 4.7.1 Please try again later" while it throttles a sender. The enhanced code itself is deliberately generic, so the free text that follows it is where the real cause lives.

For senders, 4.7.1 is an early warning rather than a failure. Mailbox providers throttle before they reject, so a rising share of 4.7.1 deferrals usually precedes 5.x rejections by days or weeks. Two mistakes are common. The first is treating repeated 4.7.1 responses as a hard bounce and suppressing perfectly valid addresses. The second is ignoring them entirely because the mail eventually got through. Track the rate, read the text, and fix the underlying cause while the problem is still only a delay.

How 4.7.1 plays out

Your server attempts delivery
The recipient defers with a temporary 4.7.1 reply
Your server queues the message and retries on a back-off schedule
It delivers on a later attempt, or becomes a hard bounce if it keeps failing

Where 4.7.1 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
4.7.1 is✓ this code

Common causes of 4.7.1

  • Greylisting: the server defers unfamiliar sender, IP, and recipient combinations on first contact
  • Missing or mismatched reverse DNS (PTR) for the sending IP, or a HELO name that does not match it
  • Rate limiting triggered by sending volume or too many concurrent connections to one provider
  • A temporary blocklist listing, or a policy service that returned a deferral rather than a rejection
  • SPF or DMARC evaluation hit a DNS temporary error (temperror) rather than an outright fail
  • Recipient-side policy that defers unauthenticated or low-reputation senders while it re-checks them

How to fix 4.7.1

  • Retry once after 15 minutes; if it then delivers, the cause was greylisting and no action is needed
  • Publish a PTR record for the sending IP and make the HELO/EHLO hostname match it in both directions
  • Check the sending IP against the major blocklists using Blacklist Checker
  • Confirm SPF, DKIM, and DMARC resolve cleanly, since a temperror is a DNS fault, not an alignment fault
  • Lower concurrent connections and hourly volume to the affected provider, then ramp back up gradually
  • Verify your MTA classifies 4.7.1 as a deferral and never moves the address onto a suppression list

Frequently asked questions

What does SMTP error 4.7.1 mean?
SMTP status 4.7.1 means the receiving mail server refused your message for a security or policy reason but is treating the refusal as temporary. The leading 4 marks it as a transient failure, so your sending server should queue the message and retry rather than give up. The most common triggers are greylisting, a reverse DNS (PTR) lookup that failed for your sending IP, rate limiting, and temporary blocklist hits. The enhanced code alone does not identify which one applies, so read the text that follows it in the bounce or the mail log.
Is 4.7.1 a hard bounce or a soft bounce?
It is a soft bounce. The 4 at the start of the enhanced status code means a persistent transient failure, which is an instruction to retry on a back-off schedule. Any properly configured MTA will do this automatically and the message will usually deliver on a later attempt. The important part is that 4.7.1 must not be fed into hard-bounce suppression logic. Sending platforms that flatten repeated 4.7.1 deferrals into a hard bounce end up removing valid, engaged subscribers from the list for what was only a delay.
What is the difference between 4.7.1 and 5.7.1?
They describe the same policy decision at two different levels of finality. 5.7.1 is a permanent rejection: the server will not accept the message and retrying will not help, so the correct response is to suppress the address and fix the root cause. 4.7.1 is the temporary form of the same refusal: the server is deferring the message and expects your MTA to try again. In practice a sender who ignores mounting 4.7.1 deferrals often sees them escalate into 5.7.1 rejections from the same provider, because the underlying reputation or authentication problem never got addressed.
How do I fix "450 4.7.1 Client host rejected: cannot find your hostname"?
This variant comes from Postfix when reverse DNS for your sending IP does not resolve. Ask whoever controls the IP, usually your hosting provider or ISP, to publish a PTR record pointing the IP at a hostname you own. Then make sure that hostname has a matching forward A or AAAA record back to the same IP, so the lookup confirms in both directions, and set your mail server HELO or EHLO name to that same hostname. Forward-confirmed reverse DNS is a baseline requirement at every major mailbox provider, so fixing it resolves this rejection and improves acceptance generally.
Does 4.7.1 mean my mail is being greylisted?
Often, yes. Greylisting is the single most common source of 4.7.1 and is easy to confirm: greylisting defers the first attempt from an unrecognised combination of sending IP, sender address, and recipient address, then accepts the retry. If the message delivers on an automatic retry within roughly 5 to 15 minutes and the deferral text mentions greylisting, that is the cause and nothing needs fixing. If the deferrals persist across hours from one provider, or appear across every provider at once, the cause is reputation or your own outbound configuration instead.

Related bounce codes

5.7.1 Delivery Not Authorized - Message Refused 4.7.0 Other Security or Policy Status - Temporary 450 Mailbox Unavailable - Busy or Temporarily Blocked 451 Local Error in Processing 421 Service Not Available - Try Again Later

Sources & further reading

RFC 3463 · The standard that defines this reply code RFC 3463 section 3.8 · Definition of the X.7.X security and policy status codes, including the X.7.1 detail Postfix configuration parameters · reject_unknown_client_hostname and unknown_client_reject_code, the source of "450 4.7.1 cannot find your hostname" Google Workspace Admin Help · SMTP error reference for the codes Gmail returns, including temporary policy deferrals
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes