450 4.2.1: The recipient is receiving mail too fast: try later
At a glance
- Type: temporary failure (class 4, RFC 3463 §2). The sending server keeps the message and retries later (RFC 5321 §4.5.4.1); it bounces only if the problem lasts until the message expires.
- Basic code 450: “Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)” (RFC 5321 §4.2.3).
- Enhanced code 4.2.1: “Mailbox disabled, not accepting messages” in the IANA registry (RFC 3463), in the group mailbox status (RFC 3463 §3.3).
This is a temporary deferral, not a final bounce. The recipient's mailbox is getting mail faster than the provider allows, so your server is asked to slow down and try again later.
What it means
A 4yz reply is a transient failure: the request was refused this time, but the same request may succeed later, and the sending server should retry (RFC 5321 §4.2.1). The basic code 450 says the mailbox is unavailable for now, for example busy or temporarily blocked for policy reasons (RFC 5321 §4.2.3).
RFC 3463 §3.3 names X.2.1 "mailbox disabled, not accepting messages" and notes it can be a transient error when the mailbox is only temporarily disabled. Gmail uses the 4.2.1 form for a specific case: too much mail arriving at one mailbox.
Common causes
- Many messages sent to the same recipient in a short time, such as alerts, notifications or a loop of automated replies.
- A burst to one shared mailbox, such as a support or sales address, from a campaign or a form.
- In Google Workspace, an organization's outbound mail through Google's SMTP relay service passing its peak rate.
How providers use it
Gmail returns 450 4.2.1 when the user is receiving mail at a rate that prevents further delivery for now, and asks the sender to try again later. Google uses the same code when an organization reaches the peak limit of its SMTP relay (Google's SMTP error reference). Gmail also has a permanent form for the same situation: its 550 5.2.1 covers a receiving rate that blocks delivery for good.
How to fix it
- Let your mail server retry. RFC 5321 §4.5.4.1 says retries should generally wait at least 30 minutes, and that a sender should generally keep trying for at least 4 to 5 days before giving up.
- Find what sends so much to one address. Combine frequent alerts into a digest, and add a limit per recipient per hour in your application.
- Check for loops: two auto-responders or forwarding rules answering each other keep generating new messages until one side stops.
- If you relay through Google Workspace, spread bulk sends over time, or move them to a service built for bulk mail.
What to do with the address
Keep it. A 450 4.2.1 says nothing bad about the address itself; it is about how fast mail reaches it. Only act if the deferrals turn into a permanent 5.2.1.
Related codes
- 550 5.2.1: The mailbox is disabled and takes no mail
- 421 4.7.28: Unusual sending rate or unsolicited mail: rate limited
- 421 4.7.0: Temporarily refused: reputation, DNS or TLS
- 452 4.2.2: The mailbox is full
See every bounce code in the dictionary.
Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.
How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.