SMTP 450 4.2.1: mailbox temporarily unavailable, not disabled

450 4.2.1 is a temporary failure specifically about mailbox status, not address status. RFC 3463 defines 4.2.1 as "mailbox disabled, not accepting messages" - temporarily. This differs meaningfully from 4.1.2 (the server has not yet confirmed whether the address is even valid) and from a permanent 550 5.2.1 (mailbox administratively disabled, permanently). A 450 4.2.1 tells you the server knows the mailbox exists and knows exactly why it cannot accept mail right now - a hold, a migration, a storage quota being cleared - and expects that state to change.

Who is at fault

The fault is on the recipient's mailbox administration, not yours and not a bad address on your list. Common real causes: the account is mid-migration between mail systems, an admin placed a litigation or compliance hold on it, or the user exceeded quota and the provider has not yet converted that into a harder failure. Corporate email migrations - moving a company from one hosted provider to another, or between

on-premises Exchange and a cloud platform - are a particularly reliable source of this exact

condition, because mailboxes are typically migrated in batches over days or weeks, with a

transitional state where the account exists in the directory but cannot yet accept new mail

through the old system. If you know (or the recipient confirms) that their organisation is

mid-migration, this code is almost certainly a byproduct of that process rather than anything

specific to your message, and it will clear once their migration batch completes.

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.2.1 <recipient@example.com>: Recipient address rejected: mailbox temporarily disabled

How Gmail, Microsoft 365 and Yahoo word the same condition

Microsoft 365's wording is essentially identical to the generic phrasing, since this is one of the more literally-implemented RFC codes across providers.

Diagnostic commands

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  450 4.2.1 <recipient@example.com>: Recipient address rejected: mailbox temporarily disabled

$ for i in 1 2 3; do sleep 3600; swaks --to recipient@example.com \
  --from sender@yourdomain.com --server mx.example.com; done

Spacing probes an hour apart over several hours is more appropriate here than the five-minute spacing used for greylisting, since mailbox holds and migrations typically resolve on the order of hours to a day or two, not minutes.

The ordered fix

1. Confirm your queue is retrying on a normal, multi-hour-to-multi-day schedule.
2. Avoid manual re-tests more than once every few hours - this condition resolves on an administrative timescale, not a network one.
3. If it persists beyond 2-3 days, reach the recipient through another channel; a hold or migration that long usually means the recipient is aware and can tell you when to expect it to clear.
4. Do not reclassify the address as invalid just because it is taking longer than a typical deferral - 4.2.1 explicitly confirms the mailbox exists.
5. Resume normal sending once a retry returns 250, without needing to re-verify anything on your side.

What not to do

• Do not suppress or remove the address. The enhanced code explicitly confirms the mailbox exists; this is categorically different from a 550 "no such user."
• Do not retry faster than every hour or two. Rapid retries will not speed up an administrative hold or migration and just add noise to your own queue logs.
• Do not treat this as a reputation signal. Nothing about your sending triggered this; it is entirely about the state of one recipient's mailbox.
• Do not change your authentication configuration. Mailbox status holds are unrelated to SPF, DKIM or DMARC.

Reading the timeline when it eventually resolves

Once a 450 4.2.1 clears, check whether it resolved to a plain 250 (the hold was lifted, message

delivered normally) or whether a subsequent message to the same address later returns a 550

(the account was actually closed during what looked like a migration). The second outcome means

the "temporary" label was technically correct at the time but the underlying situation changed -

worth noting in your own records so you do not re-attempt that address again without checking

first, even though nothing in the original 450 reply predicted that outcome.

MailPilot's per-mailbox reputation model separates recipient-side mailbox-state deferrals from genuine sender-reputation events, so a handful of 450 4.2.1 responses from mailboxes under administrative hold will not register as a problem with your own sending domain.