A 4xx is not a failure, it is a negotiation. How to tell greylisting from reputation throttling, and the retry behaviour that recovers instead of escalating.
A 4xx response is the most information-dense signal a receiving provider gives you, and most sending stacks treat it as noise to be retried away. Unlike a 5xx, which is a verdict, a 4xx is a request to slow down or come back later, and the three-digit code plus the enhanced status plus the human-readable text together describe what the receiver objects to. Senders who parse deferrals find that throttling has been building for days before any placement change becomes visible anywhere else. Senders who do not parse them find out when the mail stops.
The three things a 4xx can mean
Deferrals fall into categories calling for different responses, and conflating them is the root of most bad retry behaviour. Connection-level throttling, typically a 421 carrying a rate-limit message, is the receiver saying you have too many concurrent connections or too high a message rate right now, and it is resolved by reducing concurrency rather than by retrying harder. Greylisting, generally 450 or 451 with a stated delay, is a one-time tax on unfamiliar sender triplets and resolves itself on a retry after the required interval. Reputation-driven deferral, which carries 4.7.x enhanced status codes and often a documentation URL, is the receiver declining your volume because of how your mail is performing, and it is the only one of the three that retrying will not fix.
1421 4.7.0 [TSS04] Messages from 198.51.100.7 temporarily deferred
2 due to unexpected volume or user complaints
3
4450 4.2.0 Greylisted, try again in 300 seconds
5
6421 4.7.28 Our system has detected an unusual rate of unsolicited
7 mail originating from your IP address. Review
8 https://support.google.com/mail/answer/81126Read those three and the operational responses diverge completely. The first names an IP and cites complaints, so the fix sits on the reputation side and the immediate action is to reduce volume to that provider while investigating what changed. The second is purely procedural and requires nothing but a correctly configured retry after the stated interval, and a sender treating it as an error is manufacturing an incident out of routine behaviour. The third looks superficially like the first and points at a policy page, and it usually means a volume ramp has outrun the trust available, which is a warming problem rather than a content problem. A queue that retries all three identically will resolve the second, waste effort on the first, and actively worsen the third.
Retry behaviour that recovers
Queue configuration worth auditing
- Per-destination queues, so a deferral at one provider does not stall delivery to every other
- Exponential backoff starting around 15 minutes and extending across at least 48 hours before a final bounce
- Stated intervals honoured when a receiver supplies one, rather than overridden by a global schedule
- Concurrency limits set per destination and reduced automatically when 4xx rates rise
- Enhanced status codes parsed and stored, not just the three-digit class
- 4.7.x deferral rates tracked per provider against a rolling baseline, alerting on multiples rather than absolutes
- Message expiry set deliberately, since a 72-hour-old marketing message has usually stopped being worth delivering
Deferrals as an early warning
The reason to build this instrumentation is timing. Complaint data at Postmaster Tools lags by two to three days, placement testing samples a fraction of your sending, and deferral rates change in real time on every message you attempt. A doubling of 4.7.x deferrals at one provider, with hard bounce rates flat, is a reputation signal arriving days before anything else will show it, and it is specific enough to act on: it names the provider, it names the IP or domain, and it frequently names the reason. Teams that alert on this catch problems while they are still adjustments, and avoid the blocklist remediation work entirely.
Deferral handling belongs with warming and volume planning rather than with error handling, which is where most stacks file it. A provider that defers is still willing to talk to you, and how you answer determines whether the conversation ends in delivery or in a block. Ramp into the limits along the lines of our warming schedule, retry patiently, watch the 4.7.x rate as a leading indicator, and treat a rising deferral curve as the thing to investigate rather than the thing to survive.
Frequently Asked Questions
How long should a message stay in the queue?
Should I retry from a different IP?
Does a high deferral rate hurt reputation directly?
How do I separate greylisting from throttling in bulk?
Key Takeaways
- A 4xx is a negotiation, and the enhanced status code plus the text names which of three problems you have
- Greylisting resolves on retry, connection throttling needs lower concurrency, and 4.7.x deferrals need less volume
- Aggressive retrying demonstrates the behaviour rate limits exist to suppress and escalates deferral into blocking
- Per-destination queues, exponential backoff over 48 hours, and deliberate expiry are the baseline configuration
- Deferral rates move in real time and lead complaint data by days, making them the best early warning available
Related articles
Half-Year Review: Email in the AI Inbox Era
Six months that rearranged the reading layer: Gemini in Gmail, Microsoft rejecting outright, DMARC finally a standard. What the first half of 2026 means for senders.
Backscatter: The Bounces You Never Sent
When spammers forge your domain as their envelope sender, the bounces come to you. What backscatter is, why it happens, and how to stop causing and receiving it.
Per-Provider Playbooks: Operating Gmail, Microsoft, and Yahoo Differently
The big three score senders differently, expose different data, and fail in different ways. One operating playbook per provider beats one averaged strategy.