SMTP 421 and 450: What Gmail, Yahoo and Outlook Are Actually Telling You

A 5xx SMTP code means stop - the message is permanently refused, and resending it unchanged won't help. A 4xx code means something completely different: try again later. Codes 421 and 450 are the two you'll see most, and they're not a deliverability failure so much as a mailbox provider actively managing how fast it lets any one sender through.

What each code is saying

• 421 (Service unavailable / connection-level): the receiving server is temporarily unwilling to accept the connection at all, often specifically because of your current sending rate - Gmail's 421 4.7.28 explicitly means an IP is rate-limited
• 450 (Mailbox unavailable, temporary): the connection was accepted but this specific message is deferred - Gmail's 450 4.7.1 "sending limit exceeded" is the classic version of this
• 451/452: a local error or resource limit on the receiving side, less commonly about your sending behavior specifically

None of the big three publish fixed numeric limits. Gmail, Yahoo and Outlook all throttle dynamically, adjusted continuously against a sender's reputation - so the same volume that sails through on a well-established IP can trigger throttling on a new or shaky one. Yahoo in particular has a documented escalating code system (TS01 through higher tiers) that fires fastest on cold, unwarmed senders.

What a well-behaved sending system should do

• Honor the deferral - queue the message and retry later, rather than treating a 4xx as a bounce and dropping it
• Back off the sending rate for that provider, not just retry the one message at the same speed that triggered the throttle
• Watch which provider is throttling and how often - persistent 421/450s from one specific provider is a targeted signal, not general bad luck

Most ESPs and SMTP relays already implement retry-with-backoff automatically - which is exactly why this is worth understanding rather than acting on directly: the fix usually isn't a setting to change, it's reading the pattern. Frequent throttling from one provider despite queuing correctly means the actual sending rate is still outrunning what that provider currently trusts you with.

Reading it from the receiving end

If you have access to headers of a message that eventually arrived late, the delay is visible directly in the Received chain - each hop's timestamp shows where time was lost, which is often a throttling queue rather than a slow network.

See exactly which hop a delayed message sat at with the Email Header Analyzer

A 421 or 450 is the mailbox provider's way of saying "not never - just not this fast." The fix is almost always volume and pacing, not a technical workaround.