SMTP 450 Mailbox Unavailable and Greylisting Explained

A 450 reply means the receiving server did not accept the message this time but expects you to try again. RFC 5321 words it as "Requested mail action not taken: mailbox unavailable", and the 4 means temporary. The most common real-world cause is greylisting, an anti-spam technique where an unknown sender is deliberately told to come back later.

postfix/smtp[9021]: 1B4D2E0A77: to=<sam@example.org>, relay=mx.example.org[198.51.100.7]:25, delay=0.9, dsn=4.2.0, status=deferred (host mx.example.org[198.51.100.7] said: 450 4.2.0 <sam@example.org>: Recipient address rejected: Greylisted, see https://postgrey.example/help (in reply to RCPT TO command))

Exact wording differs by software. Postgrey, Rspamd, Exim and hosted filters each use their own text, and some use 451 4.7.1 instead. If you only need the full code map, see email bounce codes explained.

How greylisting works

The receiver remembers a triplet: sending IP (or network), envelope sender, and recipient. The first time it sees a new triplet, it answers with a temporary 4xx. A legitimate MTA queues the message and retries, typically within minutes. When the retry arrives after the receiver's minimum delay, the triplet is whitelisted and the message is accepted. Spam tools that never retry are filtered out.

For you, the effect is a delay on first contact, commonly a few minutes, sometimes longer if your server's retry schedule starts slowly. After acceptance, later mail between the same parties is normally not delayed.

Causes of a 450, most likely first

1. Greylisting of a new sender or new sending IP.
2. Recipient mailbox busy or temporarily offline, such as a backend maintenance window.
3. Rate limiting, for example Gmail's 450 4.2.1 "The user you are trying to contact is receiving email too quickly".
4. Reputation-based deferral on a new IP or domain.
5. A recipient-verification lookup failing on the receiver side (their directory or database is unreachable).

Step 1: confirm it is deferred, not bounced

A deferral is not a failure. In Postfix, look for status=deferred, and check the queue:

sudo postqueue -p | head -n 20
sudo grep "status=deferred" /var/log/mail.log | tail -n 10

Wait for the next retry. The default Postfix minimal_backoff_time is 300 seconds and maximal_queue_lifetime is 5 days, so a greylist normally clears itself after the first or second retry.

Step 2: read the text after 450

• Contains "Greylisted" or "try again in N seconds": do nothing, or force one retry after the stated time with sudo postqueue -f.
• Contains "receiving email too quickly" or "rate": slow down toward that recipient and avoid bursts to a single address.
• Contains "reputation", "IP" or a blocklist name: check the IP on the Blacklist Checker and read the email blacklist removal guide.
• Contains "mailbox unavailable" or "temporarily" with no more detail: the receiver has a transient problem; keep retrying.

Step 3: make sure your server retries properly

Greylisting only works for senders that retry. If you send through a script that talks SMTP directly and gives up on the first 4xx, greylisted messages are lost without a bounce. Use a real MTA or an email service that queues. Also check that retries come from the same IP and use the same envelope sender. Rotating IPs across a pool, or using unique VERP return-paths per attempt, can restart the greylist clock each time. Large providers that use pools are often exempt for this reason, but small receivers are not.

Step 4: if retries keep failing

When the same message still defers after an hour, treat it as a real problem:

1. Check that the recipient domain's MX is correct and reachable with the MX Lookup and Port Checker on port 25.
2. Verify your own identity: PTR, SPF, DKIM and DMARC through the Email DNS Checker.
3. Run the Email Deliverability Test to see whether authentication or content is triggering the deferral.
4. Contact the recipient's admin with the log line if their server returns a policy message you cannot resolve.

If you run a greylisting server

Greylisting adds delay for legitimate mail, such as password resets and one-time codes, and many modern spam sources retry correctly. Consider exempting known providers and using it alongside reputation checks. Keep it off for addresses that receive time-sensitive messages.

How to verify

Look for the same queue ID with status=sent later in the log. For one delivery, the headers of the received message should show Received lines separated by the greylist delay. Authentication results (spf=pass, dkim=pass) in the final copy confirm your setup is healthy.

Next steps

• Compare with SMTP 421 service not available, the other common transient refusal.
• See how SMTP 451 local error in processing differs.
• Test your sending setup with the Email Deliverability Test.
• Review email warmup for a new domain if new senders keep being deferred.

FAQ

How long does greylisting delay mail?

Usually a few minutes, bounded by the receiver's minimum delay and your retry schedule. Some servers use longer windows, so allow a few hours before escalating.

Do I need to do anything about a 450 greylist?

Normally no. A compliant mail server retries automatically. Only investigate if the message is still deferred after about an hour.

Is 450 the same as 550?

No. 450 is temporary and retried; 550 is permanent and generates a bounce. See email bounce codes explained.

Why does greylisting seem to hit me every time?

Your retries may come from different IPs or use a different sender address each time, so the receiver sees a new triplet on every attempt.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.