Is 450 4.2.1 a bounce? Did my mail fail?

No. The leading 4 makes it a transient failure, not a bounce. In SMTP, a 4xx reply means "I can't take this right now, try again later," and any competent sending server treats it exactly that way: it holds the message in its queue and retries on a schedule for hours or days. A bounce is a 5xx — permanent — and 4.2.1 only becomes a real failure if it keeps repeating until your server gives up and times the message out. If you saw a single 450 4.2.1 in a log and the mail arrived later, nothing failed; the retry worked.

The error says the recipient is receiving mail too quickly. Is that my fault?

Usually not. The standard Gmail text — "The user you are trying to contact is receiving mail too quickly" — describes the recipient's mailbox being flooded faster than Gmail will let it accept, which most often means that person is caught in a forwarding loop, subscribed to a burst of high-volume lists, or being mail-bombed. It's their inbox hitting a rate limit, not your server. You can't fix someone else's inbox; you just let your queue retry. It only becomes yours to fix if you're the one sending the flood — for example an app looping on the same address.

I use Google Workspace SMTP relay and I'm getting 450 4.2.1. Same thing?

Different cause, same code — read the text. If the message says something like "Peak SMTP relay limit exceeded for this customer," that's a sender-side limit on your Workspace relay throughput, not the recipient's inbox. It's still transient (4xx), so it clears on retry, but the lasting fix is to smooth out your sending rate so you don't spike past the relay's peak allowance. Check the exact wording after 450 4.2.1 before deciding whether the problem is the recipient or your own relay.

Views: 9

450 4.2.1 Receiving Mail Too Quickly (Gmail)

450 4.2.1 from Gmail: the recipient is receiving mail too fast — a temporary, retryable limit. Know when to wait and when it's your relay. Free instant check.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your mail server logs a 450 4.2.1 reply from Gmail — commonly with the text “The user you are trying to contact is receiving mail too quickly. Please resend your message at a later time.” The message hasn’t bounced; it’s been deferred.

Symptoms

A 450 4.2.1 appears in your mail log or a delayed-delivery notice, not a hard bounce.
The affected mail is to one or a few Gmail recipients, not all of them.
Messages eventually arrive after your server retries — or a delivery warning shows the item still queued.
If you send through Google Workspace SMTP relay, the same code appears with text about a “peak SMTP relay limit,” affecting your own outbound generally rather than one recipient.

What 450 4.2.1 Actually Means

Two things are encoded in that string, and the first digit is the one that matters. In SMTP, a reply starting with 4 is a transient failure — RFC 3463 calls the 4.x.x class a “persistent transient failure.” It means “not now, try again,” and a correctly configured sending server does exactly that automatically: it keeps the message queued and retries on its normal schedule. Compare 5.2.1, which is the permanent version of the same enhanced code (X.2.1 = “mailbox disabled, not accepting messages” in RFC 3463) and is a real bounce. The difference between “wait” and “dead” is a single digit.

The enhanced code 4.2.1 points at the mailbox, not your domain, your authentication, or your message content. Gmail’s plain-language text spells it out: the recipient is receiving mail faster than Gmail will let their mailbox accept it. That is a rate limit on their inbox. The usual reasons are on the recipient’s side — a forwarding loop dumping mail into their account, a sudden pile-up from high-volume mailing lists, or an actual mail-bomb — none of which you can reach from your sending server. So for the ordinary case, the honest answer is uncomfortable but simple: there is nothing to fix. Let your queue retry, and the mail lands when the recipient’s inbox drains.

There’s one variant worth separating out. If you relay through Google Workspace and the text mentions a “peak SMTP relay limit,” the same 450 4.2.1 is describing your relay exceeding its throughput allowance, not the recipient’s inbox. Still transient, still clears on retry — but now the durable fix is on your side: stop spiking your send rate.

Top 3 Causes

The recipient’s mailbox is being flooded. A forwarding loop, a burst of list traffic, or a mail-bomb has that inbox accepting mail slower than it’s arriving. The tell: 450 4.2.1 to one or a few Gmail addresses, with the “receiving mail too quickly” text, that resolves on its own after retries. Not your problem to fix.
You are the flood. An application bug, a runaway cron, or a retry storm is hammering the same recipient from your side, and Gmail throttles you. The tell: the 450s cluster around a single destination you’re sending to repeatedly and stop when you fix the loop.
Google Workspace relay peak limit. Your outbound through Workspace SMTP relay is spiking past its allowed peak rate. The tell: the text says “peak SMTP relay limit exceeded,” and it affects your sending broadly, not one recipient.

Diagnose with DechoNet

Email Check confirms your sending domain’s SPF, DKIM, and DMARC are clean. A transient 4.2.1 isn’t an authentication failure, but if these are broken you’ll be firefighting real rejections next — rule them out so you know the 450 is purely a rate issue and not a symptom of a domain that’s about to get throttled harder.
Reverse DNS Lookup verifies your sending IP has a valid PTR. Good reverse DNS won’t clear a recipient-side 4.2.1, but if you’re relaying volume and want Gmail to trust your throughput, a forward-confirmed PTR is table stakes.

Resolution Checklist

Read the whole reply, not just the code: does it say “receiving mail too quickly” (recipient’s inbox) or “peak SMTP relay limit” (your relay)?
Confirm your server is actually retrying 4xx replies rather than treating them as permanent — a single 450 that never retries is a misconfigured queue, not a Gmail problem.
For the recipient-flood case: do nothing but let the queue retry. Only escalate if the message finally times out (turns into a delivery failure) after your full retry window.
If the 450s cluster on one address you send to often, check your own side for a loop — a buggy retry, a cron firing repeatedly, or duplicate sends.
For a Workspace relay peak limit, smooth your send rate: batch and pace outbound instead of bursting, and review your relay’s documented throughput.
Run Email Check to rule out any real SPF/DKIM/DMARC problem so you’re certain the 450 is a rate limit and nothing more.

When to Escalate

Escalate only if a 4.2.1 keeps repeating for a specific Gmail recipient past your server’s entire retry window and turns into a permanent delivery failure — at that point the recipient’s inbox is stuck, and the recipient (or their admin) is the one who has to resolve it.
For a persistent Workspace relay peak-limit 4.2.1 that pacing doesn’t fix, take your sending volume and the exact reply text to Google Workspace support.