SMTP error 450, what it means and what to do
RFC 5321 defines 450 as "Requested mail action not taken: mailbox unavailable", with examples like mailbox busy, and it is a 4xx temporary failure. The modern cause people meet most is greylisting: an anti-spam technique where a receiving server deliberately refuses the first delivery attempt from an unknown sender, knowing legitimate servers retry and spam software usually does not. The retry succeeds minutes later, so most 450s are invisible to anyone not reading mail logs.
The fix, in order
- Do nothing first, if the mail is server-to-server. Sending mail servers retry 450 automatically, commonly within 15 to 60 minutes. A message that shows 450 in the log and then a successful delivery was greylisted, and the system worked as intended.
- If sending from a desktop client: leave the message in the Outbox and let the client retry on its next send cycle, or resend after half an hour. Immediate repeated manual resends can keep tripping the greylist window.
- Read the enhanced code and text. Variants matter: 4.7.1 with text about greylisting or trying later is the standard deferral. Text naming SPF with a temporary error (4.7.24 family) means the receiving server could not check the sender's SPF record, usually a DNS hiccup, which also clears on retry.
- Check the mailbox-locked variant. A mailbox being migrated, restored, or locked by another active session (a POP3 client holding it open) returns 450 until the lock clears. If one recipient at an organization always 450s while colleagues receive fine, that mailbox's state is the lead.
- If you run the sending server and 450 never clears: verify the retry schedule is actually running (a stalled queue makes temporary errors permanent), and confirm the server retries from the same IP, because greylisting tracks the IP and sender pair; retries from rotating IPs restart the greylist clock each time.
- If you run the receiving server: check greylist settings and mailbox locks before anything else; an over-long greylist delay or a lock that never releases turns a protective feature into a delivery fault your users will report.
If it still happens
The line between normal and abnormal for 450 is duration: under a few hours is anti-spam weather; beyond a day of continuous 450 for the same recipient means something structural, a locked mailbox, a DNS problem for SPF checks, or a queue that is not retrying, and the logs at the sending server will show which.
Common questions
What is greylisting, in one sentence? The receiving server refuses the first delivery attempt from an unknown sender and accepts the retry, because real mail servers always retry and most spam senders never do.
Why did my newsletter get 450 from some providers but deliver to others? Each receiving provider runs its own deferral rules and thresholds. New sending IPs and domains are greylisted and rate-limited more aggressively until they build history, which is why the same send behaves differently per destination.
Related errors