SMTP 450 4.1.2: bad destination mailbox address, temporarily

450 4.1.2 is a temporary failure. The enhanced status 4.1.2 ("bad destination mailbox address," temporary variant) sounds like a verdict on the address, but the leading 4 means the server is explicitly declining to make that verdict yet. The most common real cause is greylisting - the receiving server has not seen your sending IP and this recipient pair before, so it defers the first attempt on purpose and expects a retry within a defined window. A second common cause is a pending recipient-verification callout that has not completed.

Who is at fault

This is usually nobody's fault in the sense of broken configuration - it is standard, intentional anti-spam behaviour (greylisting) on the receiving side. If it persists well past the expected retry window, the fault shifts to either a misconfigured greylist exemption on their end, or a genuinely stale address on yours. Some organisations run an allowlist alongside their greylist specifically to avoid repeatedly

deferring known-good senders, keyed off SPF-validated sending domains or specific IP ranges. If

you send to the same domain regularly and keep tripping greylisting on every first message of a

new campaign despite an established sending history, it may be This is a particularly worthwhile conversation to have before a planned large send - a product

launch announcement or a scheduled newsletter spike - since greylisting defaults are tuned for

steady, moderate traffic and are more likely to trigger noticeably against a sudden burst, even

from a sender with an otherwise clean history. Raising volume gradually in the days before a

planned spike, rather than jumping straight from normal volume to peak volume on the day itself,

reduces how often this comes up at all.

The exchange

220 mx.example.com ESMTP
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 26214400
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
450 4.1.2 <recipient@example.com>: Recipient address rejected: greylisted, try again in 5 minutes

How Gmail, Microsoft 365 and Yahoo word the same condition

Greylisting in this explicit form is far more common on self-managed Postfix/Exim installations (using postgrey or similar) than on the big three, which use reputation-based deferral instead of classic greylisting.

Diagnostic commands

Confirm the deferral clears on a properly spaced retry:

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  450 4.1.2 <recipient@example.com>: Recipient address rejected: greylisted, try again in 5 minutes

$ sleep 360 && swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  250 2.1.5 Recipient OK

If the second attempt, spaced several minutes apart, succeeds, you have confirmed classic greylisting rather than a genuinely bad address.

The ordered fix

1. Confirm your own MTA retries on a normal backoff schedule rather than giving up after one 4xx.
2. Wait at least the window the message itself cites (5-15 minutes is typical for greylisting) before re-testing manually.
3. If the retry succeeds, no further action is needed - this was expected first-contact behaviour.
4. If it keeps failing across several hours, check whether your sending IP is new or recently changed; a cold IP triggers greylisting more aggressively on some systems.
5. If it fails for days, treat it as a genuinely temporary address problem and verify the address through another channel.

What not to do

• Do not remove the address after a single 450. This is specifically the kind of code greylisting produces by design on the first attempt from a given IP/sender/recipient triple.
• Do not retry within seconds. Retrying too quickly defeats the purpose of greylisting and can reset its timer, extending your wait rather than shortening it.
• Do not treat this as equivalent to 550 5.1.1. That code is a permanent "no such user"; 450 4.1.2 explicitly is not.
• Do not change your authentication records in response - greylisting is based on the sender/recipient/IP triple and timing, not SPF/DKIM/DMARC status.

Telling greylisting apart from a growing reputation problem

A single greylist-style deferral that clears on retry within minutes is routine and not worth

escalating. What is worth watching is whether the *same* sending IP keeps hitting 450 4.1.2 across

many different, unrelated recipient domains over an extended period - that pattern suggests the IP

itself is new or thin on history broadly, not that any one receiving server is simply running

standard anti-spam defaults. If it is the latter, warming the IP's reputation generally, not

troubleshooting individual recipients, is the actual fix.

MailPilot's warm-up schedule sends gradually and consistently from the same mailbox over time, which is specifically the pattern that stops triggering greylisting repeatedly on new sending infrastructure - a cold, bursty IP is what makes this deferral recur.