SMTP 450 4.2.0: mailbox unavailable, general

450 4.2.0 is a temporary failure using the general enhanced status within the mailbox-status family. RFC 3463 defines 4.2.x codes for mailbox-related conditions, with 4.2.0 as the unspecified case - the server knows enough to say "this is about the mailbox, and it is temporary," without narrowing it down to full (4.2.2), disabled (4.2.1), or another specific mailbox-status reason. It is deliberately less precise than its siblings.

Who is at fault

The fault is on the recipient's mailbox state, though the exact nature is unspecified by the code itself - it could be a quota issue, a hold, or an internal condition the receiving server does not expose in detail.

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.0 <recipient@example.com>: Mailbox temporarily unavailable

How Gmail, Microsoft 365 and Yahoo word the same general mailbox-unavailable condition

Yahoo is one of the few providers that retains the unspecified 4.2.0 form in practice rather than always narrowing to a more specific subcode, which is consistent with 4.2.0 being intended as a legitimate general-purpose fallback, and is a useful reminder that the absence of detail in a reply is sometimes the provider's own design choice rather than a limitation worth troubleshooting around on your side at all. As with other mailbox-status deferrals, the useful check here is pattern confirmation over a few hours rather than deep inspection of any single reply, since the code itself does not expose enough detail to diagnose further from outside the receiving system.

Diagnostic commands

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  450 4.2.0 <recipient@example.com>: Mailbox temporarily unavailable

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

The ordered fix

1. Let your queue retry on its normal multi-hour schedule - the lack of a specific reason does not change the correct response, which is patience.
2. Space manual checks roughly an hour apart.
3. Note whether it ever narrows to a more specific code (4.2.1 or 4.2.2) on a later attempt - that would tell you more about the underlying cause even though the initial reply did not.
4. If it persists past 2-3 days, contact the recipient through another channel.
5. Do not attempt to infer a specific cause from the general code alone; there is genuinely not enough information in a 4.2.0 to diagnose further from your side.

What not to do

• Do not remove or suppress the address. The leading 4 confirms this is temporary, regardless of the lack of detail in the subcode.
• Do not assume it is the same as a full mailbox (4.2.2) or a disabled one (4.2.1). The general code deliberately does not commit to either, and treating it as one specifically can lead you to recommend the wrong fix to the recipient.
• Do not change your authentication or content in response. Mailbox-status codes are unrelated to SPF, DKIM, DMARC, or message content.
• Do not escalate to the recipient's admin after a single occurrence. Reserve that for persistence beyond a few days.

Watching for a later narrowing of the code

Because 4.2.0 is deliberately unspecific, it is worth checking whether a subsequent retry to the

same address returns a more detailed code - 4.2.1 (disabled) or 4.2.2 (over quota) - rather than

repeating 4.2.0 indefinitely. Mail systems sometimes return the general code on a first attempt and

a more specific one once an internal check completes. If you do see it narrow, treat the more

specific later code as the more reliable description of what is actually happening with that

mailbox, superseding the vaguer initial reply.

Why some providers prefer the unspecified form deliberately

Returning a vague status code can be a deliberate privacy choice: disclosing whether a mailbox is

over quota versus administratively disabled versus held for another reason reveals internal

account state to an external party, which some mail operators would rather not do. If a domain

you send to regularly returns 4.2.0 consistently rather than ever narrowing to a more specific

subcode, that consistency itself is a signal about their operational policy, not a sign that their

mail system cannot tell the difference internally - it most likely can, and has chosen not to say.

MailPilot tracks mailbox-status deferrals, specific or general, as recipient-side signals distinct from sender reputation, so an unspecified 450 4.2.0 does not get misread as a problem with your own domain or mailbox health.