The User You Are Trying to Contact Is Receiving Email at a Rate: Reading a 4.2.1
Gmail deferred your message with a 450 4.2.1, and the text reads: the user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered. That sentence is about the person you are sending to, not about you. The mailbox is real. Your domain is not blocked. Your daily quota has not moved. Gmail is declining more mail for that one address right now, and it will take the message later.
That is worth saying plainly because almost everyone reaches for the wrong fix. They go and check their sending limit, or pull the address off the list as a bounce, or hit resend a few times. All three make things slightly worse and none of them touches the cause. The 4 at the front of the code is an instruction to your mail server: hold the message and try again. If your queue is doing its job, you do not have to do anything at all.
Three messages ship under one 450 4.2.1
Here is the part that trips people up. Google's own SMTP error table lists three separate messages under the same 450 4.2.1, and they do not all point the same direction:
| What Gmail actually returns | Whose limit it is |
|---|---|
| "The user you are trying to contact is receiving email too quickly. Please resend your message at a later time." | The recipient's |
| "The user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered." | The recipient's |
| "Peak SMTP relay limit exceeded for this customer. This is a temporary error." | Yours |
Two are inbound throttles on a mailbox you do not control. The third is Google Workspace throttling your own tenant's use of its SMTP relay. Same code, same class, opposite diagnosis — and if your monitoring buckets bounces by code, which most tooling does by default, those three land in one pile and you will guess wrong a third of the time.
So read the string, not the code. In a Postfix log it is on the same line, after the status; in most ESP dashboards it is the "raw response" or "SMTP reply" field rather than the summarised reason.
What the 4 promises and what the 2.1 admits
The enhanced status code is two claims stacked on top of each other, and each is defined in a spec you can check.
The leading 4 is the class. RFC 3463 calls it a persistent transient failure, and defines it as the case where "the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay of attempts to send the message." Compare that to the 5 class, which is "not likely to be resolved by resending the message in the current form." RFC 5321 says the same thing about the bare SMTP number: a 4yz reply means the condition is temporary and the command can be retried, while a 5yz means it will fail permanently if you retry with the same sender, recipient and data.
The 2.1 is the specific subject. RFC 3463 defines X.2.1 as: "The mailbox exists, but is not accepting messages." That sentence does two useful things for you. It confirms the address is real, so this is not a hard bounce and the address should not be scrubbed or suppressed. And paired with the 4, it says the not-accepting part is a state, not a property of the mailbox.
Put together: valid address, valid message, wrong moment.
The codes this one gets confused with
| Bounce | SMTP code | Whose side | Should you retry? |
|---|---|---|---|
| 4.2.1 "receiving email at a rate…" | 450 | Recipient | Yes — leave it queued |
| 4.2.1 "Peak SMTP relay limit exceeded for this customer" | 450 | Yours (Workspace relay) | Yes, but slow the send down too |
| 4.7.28 "Gmail has detected an unusual rate of email…" | 421 | Yours (IP, domain or netblock reputation) | Yes, and back off hard |
| 5.4.5 "Daily user sending limit exceeded" | 550 | Yours (per-user quota) | No — the send must wait for the reset |
| 5.7.1 "This email has been rate limited" | 550 | Yours | No |
| 5.2.2 "The recipient's inbox is out of storage space and inactive" | 452 | Recipient | Not usefully |
Two of those deserve a note. 5.4.5 is the one people confuse with this most often, because both feel like "too much mail" — but it is a permanent 550 about your own daily sending quota, which is a completely different counter from a recipient's inbox. I wrote that one up separately in 5.4.5 Daily User Sending Limit Exceeded: Which Quota You Hit.
And 5.2.2 is a genuine oddity in Google's table: a transient-looking 452 carrying a permanent 5.x.x enhanced code. If your queue software keys its retry decision off the enhanced code rather than the SMTP number, those two disagree, and it is worth knowing which one your MTA believes.
The receiving caps Google publishes, and the one it doesn't
For Google Workspace mailboxes, the documented receiving limits are:
- 60 messages per minute
- 3,600 messages per hour
- 86,400 messages per day
- 50 MB per message on Enterprise Standard, 70 MB on Enterprise Plus
- Up to 500 attachments in a single email
None of those is the number that produced your deferral. A throttle fires long before anyone hits 3,600 messages in an hour, and Google does not publish the threshold that triggers it or the window it measures over. So do not model your send against the published ceilings and conclude you are safe — the caps above are the outer wall, not the tripwire. There is no real figure to put on the tripwire, and a made-up one would just send you optimising against fiction.
A retry schedule you can defend
RFC 5321 gives two figures worth holding onto: retries should be spaced at least 30 minutes apart, and a message that still has not gone through after 4 to 5 days should be given up on. Every mainstream MTA ships defaults in that shape:
| MTA | Default behaviour after a temporary failure |
|---|---|
| Postfix | minimal_backoff_time 1000s, backing off toward a maximal_backoff_time ceiling of 4000s; the deferred queue is scanned every 300s (queue_run_delay); message returned after maximal_queue_lifetime of 5d |
| Exim | Default rule * * F,2h,15m; G,16h,1h,1.5; F,4d,6h — every 15 minutes for the first 2 hours, then a 1-hour interval multiplied by 1.5 each time out to 16 hours, then every 6 hours until 4 days have passed |
Work that through on a real send. Say you push a 5,000-recipient campaign at 09:00 and six Gmail addresses come back 450 4.2.1. On stock Postfix, those six sit in the deferred queue; the first retry is roughly 17 minutes later, the gap widens toward about 67 minutes, and the message is not returned to you as failed until five days have gone by. There is no action for you at 09:05, or at 10:00. The correct move for the first few hours is to watch the queue drain.
What breaks this is impatience. postqueue -f in a loop, or a "resend failed" button clicked repeatedly, adds to exactly the rate that caused the throttle. So does an application that treats any 4xx as a hard failure and re-enqueues a fresh copy — now you have two messages racing for one slot.
Tracing one deferral to its cause
- Count the affected recipients. One address, or a handful, out of a large send is recipient-side and genuinely about those mailboxes. Every Gmail recipient at once is a different animal — go back and read the message string, because that pattern fits the relay-limit variant.
- Read the exact text, not the code. Three messages, one code.
- Ask what else is hitting that mailbox. The recurring real-world causes are load or stress testing aimed at a real hosted mailbox instead of one you control, a single address that several senders acquired at the same time and all mailed at once, bot submissions on a signup form, and a campaign that went out twice.
- Check for duplicates on your side. Two sends of the same campaign to the same list will throttle themselves.
- Check the neighbouring log lines. A
4.2.1sitting next to a run of4.7.28is a reputation story, not a recipient story, and needs a different response.
What to change, and what to leave alone
Leave alone: the recipient address, which is valid and should not be suppressed; your daily sending quota, which this error says nothing about; and your SPF, DKIM and DMARC records, which are not implicated by a 4.2.1 at all.
Worth changing: deduplicate before the send so one address never gets two copies in flight; pace per recipient rather than only capping your global throughput, since this counter is per mailbox; stop manual resends while a message is still deferred; and leave your queue lifetime at the RFC-shaped 4 to 5 days instead of bouncing after a few hours. If you got the relay-limit variant instead, spread the same volume over a longer window.
The short version: a 4.2.1 on a Gmail address is the receiving end asking you to wait, and waiting is a thing your mail server already knows how to do.
Frequently asked questions
Does a 450 4.2.1 mean my emails are being blocked by Gmail?
No. A 450 is a temporary deferral, not a block, and 4.2.1 points at the recipient's mailbox rather than your sending IP or domain. Your message stays in your queue and is retried; nothing about your domain's standing with Gmail has changed because of it.
Should I remove an address that returns 4.2.1 from my list?
No. RFC 3463 defines X.2.1 as a mailbox that exists but is not accepting messages right now, so the address is valid and suppressing it would cost you a real contact. Treat it as a deferral and let your queue retry rather than recording a hard bounce.
How is 4.2.1 different from 5.4.5 daily user sending limit exceeded?
4.2.1 is a temporary 450 about the rate at which the recipient's mailbox is taking mail, while 5.4.5 is a permanent 550 about your own daily sending quota. One resolves by waiting a short while and retrying the same message; the other means that message will keep failing until your quota resets.
How long should my server keep retrying a deferred message?
RFC 5321 suggests spacing retries at least 30 minutes apart and giving up after 4 to 5 days. Postfix and Exim both ship defaults in that range, with Postfix returning a message after a 5-day queue lifetime and Exim's default rule running out at 4 days, so leaving the defaults alone is usually the right call.