SMTP 422: a Yahoo-specific temporary mailbox-quota hold

422 is worth stating plainly: it is not part of the RFC 5321 base reply-code table, but it is a genuine, documented reply used by Yahoo's mail infrastructure, distinct from purely fabricated numbers elsewhere in similar lists. Yahoo uses 422 for a temporary mailbox-related hold - commonly the recipient approaching a sending or receiving rate limit, a mailbox under temporary migration, or another short-lived administrative state - without necessarily meaning the mailbox is over quota in the hard sense that 452 4.2.2 implies.

Who is at fault

The fault is on the recipient's mailbox state at Yahoo, and it is explicitly temporary. Nothing about your sending domain's reputation or authentication caused this condition for any single, isolated occurrence against one recipient, and no change on your end is needed beyond the normal patience any other temporary deferral calls for. Because Yahoo documents less detail about this specific condition than other providers publish for their own equivalents, spaced re-testing every twenty to thirty minutes remains the most practical diagnostic available from outside their infrastructure. Treat anything that clears within that window as routine and not worth further attention.

The exchange

220 mta7.am0.yahoodns.net ESMTP ready
EHLO mail.yourdomain.com
250-mta7.am0.yahoodns.net
250 SIZE 41943040
MAIL FROM:<sender@yourdomain.com>
250 ok
RCPT TO:<recipient@yahoo.com>
422 Recipient's mailbox is temporarily unavailable

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

Gmail's and Microsoft's equivalents both use the more RFC-conventional 450 4.2.1 pairing for the same underlying situation, which underscores that Yahoo's 422 is a vendor-specific label for a condition the rest of the industry expresses through standard enhanced status codes.

Diagnostic commands

$ swaks --to recipient@yahoo.com --from sender@yourdomain.com --server mta7.am0.yahoodns.net
<~  422 Recipient's mailbox is temporarily unavailable

$ for i in 1 2 3; do sleep 1800; swaks --to recipient@yahoo.com \
  --from sender@yourdomain.com --server mta7.am0.yahoodns.net; done

The ordered fix

1. Let your queue retry on its normal schedule - this is explicitly a temporary hold.
2. Space manual checks at least 30 minutes apart.
3. If this recurs across many different Yahoo recipients at once, check your own sending rate to Yahoo overall; Yahoo applies rate limits per sending domain/IP, and a 422 appearing broadly (not just to one address) can indicate you are bumping against that ceiling.
4. If it is isolated to one address, there is nothing further to do beyond waiting for the normal retry to succeed.
5. Reduce concurrent connections or messages per hour to Yahoo if the pattern suggests a rate-related cause rather than a single mailbox's own state.

What not to do

• Do not remove or suppress the address. The leading digit and Yahoo's own documentation both confirm this is temporary.
• Do not search broadly for "SMTP 422" expecting RFC documentation. It is a Yahoo-specific extension, not part of the core specification.
• Do not treat a single occurrence as a sign of a rate-limit problem. Only treat it that way if it appears across multiple distinct Yahoo recipients in a short window.
• Do not change your authentication configuration. This condition is about mailbox/rate state at Yahoo, unrelated to SPF, DKIM or DMARC.

Distinguishing a single account's state from a sending-rate problem

The fastest way to tell these apart: check whether the same recipient address returns 422 on

every attempt over several hours (a single account's own, possibly longer-lived state) versus

whether different Yahoo addresses each return it once and then succeed on retry while new ones

keep appearing (a rate pattern tied to your own overall Yahoo-directed volume). The first pattern

needs no action beyond patience with that one address; the second needs an adjustment to your

sending rate to Yahoo as a whole, not more patience with any individual recipient.

Why Yahoo's rate thresholds are less publicly documented than Gmail's

Yahoo publishes less detailed guidance on its exact sending-rate thresholds than Gmail or

Microsoft do, which means senders mostly learn the practical limits by observing exactly this kind

of deferral pattern rather than reading an official number. If you send meaningfully to

Yahoo-hosted domains, treating the first appearance of 422 across several different addresses in

a short window as an early warning - and reducing rate proactively rather than waiting for a

harder block - is the more reliable strategy given the lack of a published ceiling to plan against

directly.

MailPilot's per-provider sending pace, including for Yahoo specifically, is designed around each major provider's known rate characteristics during warm-up, which is the direct countermeasure to broad, rate-driven 422 patterns across many recipients at once.