Contents
Why 421 deferrals matter
A 421 deferral from a major receiver is a signal, and how a sender reads and responds to that signal makes a real difference to deliverability. A 421 is the receiver telling the sender to slow down. Read correctly and answered with a reduction in volume, a 421 pattern usually eases and the mail delivers. Read wrong, or ignored, and pushed against, a 421 pattern can escalate, with Gmail in particular, into permanent rejections and lost mail.
This guide exists because 421 deferrals from Gmail and Microsoft are common, are frequently misunderstood, and have a counterintuitive correct response, slow down, not push harder. The structure of this guide: why 421 deferrals matter, what a 421 deferral actually means, why a 421 is not a bounce, the Gmail 421 deferrals, the dangerous Gmail 421-to-550 escalation pattern, the Microsoft 421 deferrals and their relationship to SNDS reputation, reading 421 deferrals in the PowerMTA accounting log, the correct response, and the diagnostic workflow when 421 deferrals persist.
What a 421 deferral means
A 421 is a temporary deferral code. SMTP response codes are grouped by their first digit: codes beginning with 4 are temporary or transient failures, codes beginning with 5 are permanent failures.
A 421 specifically signals that the service is unavailable to the sender at this moment. The receiving server is declining the message right now, but the sender should try again later. The common reasons a receiver returns a 421:
- Throttling. The receiver is rate-limiting the sender, accepting less mail than the sender is offering.
- Connection closing. The receiver is closing the connection, often as part of throttling.
- Temporary unavailability. The receiver is temporarily not accepting more mail from this source.
The key word is temporary. A 421 says not now, try later, not no, never. It is the receiver applying the brakes, asking the sender to ease off, with the implication that mail will be accepted again once the condition clears.
An occasional 421 is entirely normal. Receivers manage their load, and a transient 421 here and there is just ordinary mail-flow texture. What matters is the pattern: a steady or rising rate of 421 deferrals from a particular receiver is that receiver signalling, with growing emphasis, that it wants the sender to slow down. Distinguishing a normal occasional 421 from a 421 throttling pattern is the heart of deferral analysis.
Why a 421 is not a bounce
An important point: a 421 is not a bounce, and PowerMTA does not treat it as one.
When PowerMTA receives a 421 for a message, it does not mark the message as failed. It queues the message for retry, because the 421's temporary condition may clear and a retry may succeed. PowerMTA then retries the 421-deferred message according to its retry schedule.
| Aspect | 421 deferral | 550 bounce |
|---|---|---|
| Code type | 4xx, temporary | 5xx, permanent |
| PowerMTA's action | Queue for retry | Bounce, no retry |
| The message | Still in the queue, will deliver if condition clears | Failed, will not be delivered |
| Recoverable | Yes | No |
This retry behavior continues until one of two things happens: the message is delivered, the 421 condition cleared and a retry succeeded, or the bounce-after time limit is reached, PowerMTA has been retrying for the configured maximum time and finally gives up, at which point it bounces the message.
So a 421 in the accounting log is a transient event, not a delivery failure. The message is still in PowerMTA's queue, still going to be delivered if the condition clears within the bounce-after window. This is why the response to 421 deferrals is about easing the condition so the queued messages deliver, rather than about the messages being lost. The mail is recoverable, as long as the operator responds correctly and the condition clears before bounce-after expires.
Gmail 421 deferrals
Gmail uses 421 deferrals to throttle senders whose reputation or sending pattern concerns it.
When Gmail has a concern about a sender, the reputation has dipped, the volume spiked, the complaint rate rose, it begins deferring the sender's mail with 421 codes. A common Gmail 421 is 421 4.7.28, whose diagnostic text references an unusual rate of unsolicited mail or a reputation concern. Gmail also uses 421 codes referencing rate limits.
The Gmail 421 is Gmail's way of saying: something about your sending concerns us, slow down. It is a graduated response, Gmail starts with the temporary 421, giving the sender the opportunity to respond appropriately.
The diagnostic text of a Gmail 421 is informative and should be read. It frequently points at the reason, a rate issue, a reputation issue, an unsolicited-mail concern, which tells the operator what to address. Gmail's 421 deferrals also typically reference Gmail's sender guidelines, a pointer to the practices Gmail expects.
The correct response to Gmail 421 deferrals, covered in detail below, is to reduce volume and address the underlying concern. The wrong response, pushing through, is what triggers the escalation pattern that the next section covers, and that escalation is the specific reason Gmail 421 deferrals must be taken seriously.
The Gmail 421-to-550 escalation
The Gmail 421-to-550 escalation is the most important thing to understand about Gmail 421 deferrals, because it is what turns a recoverable situation into lost mail.
The pattern works like this. Gmail begins deferring a sender's mail with 421 codes because of a reputation or rate concern. The 421 is temporary and recoverable, and the correct sender response is to reduce volume and let the condition ease. But if the sender ignores the 421 signal and keeps sending at full pressure, hammering Gmail with the same volume that triggered the 421, Gmail interprets the continued pressure as confirmation that the sender is not a careful, legitimate sender, a careful sender would have slowed down.
At that point Gmail escalates. The temporary 421 deferrals become permanent 550 rejections.
The escalation matters because a 421 and a 550 have completely different consequences. A 421-deferred message is queued and recoverable, it will deliver when the condition clears. A 550-rejected message is hard-bounced, it will not be delivered, that mail is lost. When a sender pushes through Gmail's 421 deferrals instead of slowing down, and Gmail escalates to 550, the sender has converted recoverable, queued mail into permanently rejected mail. The escalation is the concrete, costly reason the correct response to 421 deferrals is to slow down. A sender who reads the 421 as the warning it is and reduces volume generally sees the condition ease and the mail deliver. A sender who pushes harder against the 421 deferrals risks the escalation and the loss.
The escalation pattern is, in a sense, Gmail testing the sender's behavior. The 421 is the test: a legitimate, careful sender responds to a 421 by easing off; an aggressive or careless sender pushes through. Gmail escalates against the senders who push through. Understanding this reframes the 421 deferral, it is not just a throttle, it is a behavioral signal the sender's response to which determines whether the situation recovers or escalates.
Microsoft 421 deferrals
Microsoft, the Outlook and Hotmail family, also uses 421 deferrals to throttle senders, and the Microsoft 421 deferrals are closely tied to the sender's reputation as Microsoft sees it.
Microsoft's view of a sender's reputation is informed substantially by SNDS, the Smart Network Data Services system, which gives Microsoft data on the sender's IPs, their complaint rates, their sending patterns, their trap hits. When Microsoft's assessment of a sender, informed by SNDS, is poor, Microsoft throttles the sender, and 421 deferrals are part of that throttling.
A Microsoft 421 deferral, like a Gmail one, is temporary and is a signal to slow down. The Microsoft 421 diagnostic text uses Microsoft's own phrasing and codes, including the S-prefixed codes, and the text frequently points at the reason and may reference Microsoft's sender support resources.
The relationship to SNDS is the useful diagnostic angle for Microsoft 421 deferrals: if Microsoft is deferring a sender with 421 codes, the sender should look at their SNDS data, the SNDS reputation color, the complaint rate SNDS reports, the trap data, because SNDS will frequently show what Microsoft's concern is. A poor SNDS reputation reading explains the 421 deferrals and points at what to fix. Microsoft also provides a deliverability support process for senders facing delivery problems.
The correct response to Microsoft 421 deferrals is the same as for Gmail: reduce volume, read the diagnostic text and the SNDS data to understand the concern, address the underlying cause, and recover gradually.
Reading 421 deferrals in the accounting log
PowerMTA records 421 deferrals in the accounting log, and reading them there is how the operator detects and analyzes a 421 pattern.
A 421 deferral is recorded as a transient-failure event, a t record, with the SMTP code and the diagnostic text. To analyze 421 deferrals, the operator queries the accounting log for the transient failures, grouped by receiving domain, and reads the diagnostic text.
SELECT
rcptDomain,
dsnStatus,
count() AS n
FROM pmta_accounting
WHERE type = 't'
AND timeLogged >= now() - INTERVAL 6 HOUR
GROUP BY rcptDomain, dsnStatus
ORDER BY n DESC;What to look for:
- The rate of 421 deferrals per receiver. A steady or rising count of 421 deferrals from Gmail or Microsoft is the throttling pattern. An occasional 421 is normal; a sustained pattern is the signal.
- The diagnostic text. Read the dsnDiag text of the 421 deferrals. It carries the receiver's specific reason, the Gmail 4.7.28 unsolicited-mail phrasing, the Microsoft code, a rate-limit reference, which points at what to address.
- The trend. Is the 421 rate stable, rising, or easing? A rising trend means the situation is worsening; an easing trend after a volume reduction means the response is working.
- Whether queues are in backoff. A sustained 421 pattern usually puts the affected queue into PowerMTA's backoff mode.
The accounting log is the instrument for both detecting a 421 pattern early and confirming, after a response, that the pattern is easing. Monitoring the transient-failure rate per receiver is part of good operational monitoring precisely because a rising 421 rate is an early warning that a receiver is becoming unhappy.
The correct response
The correct response to a pattern of 421 deferrals is to reduce volume to that receiver and address the underlying cause, not to push harder. The steps:
Step 1: confirm it is a pattern. Confirm the 421 deferrals are a real, sustained pattern from a particular receiver, not just normal occasional transient deferrals.
Step 2: read the diagnostic text. Read the dsnDiag text of the 421 deferrals to understand the receiver's stated reason, a rate concern, a reputation concern, an unsolicited-mail concern.
Step 3: reduce the volume. Lower the max-msg-rate on the receiver's domain block. Sending less to a receiver that is signalling it wants less is the direct, correct response. For Gmail and Microsoft families, ensure the queue-to family collapsing means the reduction applies to the whole family.
Step 4: let backoff work. If PowerMTA has put the queue into backoff because of the 421 deferrals, let the backoff operate rather than forcing the queue out of it.
Step 5: address the underlying cause. A 421 pattern reflects something, a volume spike, a reputation decline, a complaint increase, a list-quality problem. Investigate and fix the cause, because the 421 condition will not clear durably until the underlying reason is addressed. For Microsoft, the SNDS data points at the cause.
Step 6: recover gradually. When the 421 condition eases, raise the rate back up slowly, not in a jump back to full volume, which could re-trigger the deferrals.
The entire response is about respecting the receiver's signal. The 421 says slow down; the sender slows down, finds out why the receiver wanted them to slow down, fixes that, and ramps back carefully. The instinct to push through a deferral, to keep sending and hope it resolves, is exactly wrong, and against Gmail it courts the 421-to-550 escalation.
When 421 deferrals persist
When 421 deferrals persist despite a response, the diagnostic workflow:
Step 1: confirm the volume reduction took effect. Verify the max-msg-rate reduction was applied and PowerMTA reloaded, and that the actual sending rate to the receiver has genuinely dropped.
Step 2: re-read the diagnostic text. Read the current 421 deferrals' diagnostic text. Has the receiver's stated reason changed? The text guides what to address.
Step 3: assess the reputation. Persistent 421 deferrals usually mean a reputation problem that volume reduction alone does not fix. Check Google Postmaster Tools for Gmail and SNDS for Microsoft. A poor reputation reading is the real issue.
Step 4: address the reputation cause. If reputation is the issue, the cause, complaints, list quality, engagement, must be addressed. Reputation recovers slowly, so persistent 421 deferrals during a reputation recovery are expected and ease as reputation improves.
Step 5: watch for escalation. Monitor specifically for 421 deferrals becoming 550 rejections, the Gmail escalation. If 550s start appearing, the situation has escalated and volume must come down further.
Step 6: check bounce-after. If 421 deferrals persist long enough that messages are reaching the bounce-after limit and bouncing, the persistent deferral is now causing actual mail loss, which raises the urgency of resolving the reputation cause.
An operator we worked with noticed their accounting log filling with 421 deferrals from Gmail. Their reaction was the wrong one, and it is a common wrong reaction. They reasoned that a 421 was temporary, that PowerMTA would retry, and that the mail would get through eventually, so the deferrals were not really a problem, just a delay. They did not reduce volume; they kept sending to Gmail at full rate, and they assumed the retries would deliver the deferred mail. For a while, that seemed to work, some of the deferred mail did deliver on retry. But the 421 rate from Gmail kept rising, and then the operator started seeing something worse in the accounting log: 550 rejections from Gmail, where before there had only been 421 deferrals. The 550 count grew, and 550-rejected mail does not retry, it bounces, so the operator was now losing mail to Gmail outright. What had happened was the Gmail 421-to-550 escalation. Gmail had begun deferring with 421 because of a reputation concern, the operator's signal to slow down. By continuing to push full volume into the 421 deferrals, the operator had shown Gmail exactly the aggressive, non-responsive sending behavior that Gmail escalates against. Gmail had concluded the sender was not going to slow down on its own, and had escalated from temporary 421 deferrals to permanent 550 rejections. The recoverable situation, queued mail that would have delivered, had become an unrecoverable one, mail hard-bounced and lost. The operator then did what they should have done at the first 421 deferrals: they sharply reduced their volume to Gmail, read the deferral diagnostic text, found it pointed at a reputation concern, checked Google Postmaster Tools and found their reputation had dipped, and began addressing the list-quality issues behind the reputation decline. Over the following weeks, with reduced volume and the reputation work, the 550 rejections stopped, the 421 deferrals eased, and delivery recovered, but the mail lost to 550 during the escalation was gone. The lesson is the central one of this guide: a 421 is a warning, and the correct response is to slow down, immediately, not to reason that the retries will sort it out. Pushing full volume through 421 deferrals, especially Gmail's, is precisely the behavior that triggers the escalation to permanent 550 rejections, turning a recoverable deferral into lost mail.
A 421 deferral from Gmail or Microsoft is a temporary signal, not a bounce: the message is queued and recoverable, and PowerMTA will retry it until it delivers or reaches the bounce-after limit. An occasional 421 is normal; a sustained pattern of 421 deferrals from a receiver is that receiver asking the sender to slow down. The correct response is exactly that, slow down: reduce the volume to the receiver, read the deferral diagnostic text to understand the concern, address the underlying cause, which is usually a reputation or volume issue, and recover gradually. The response that must be avoided is pushing through, continuing at full volume against the 421 deferrals, because with Gmail in particular that triggers the 421-to-550 escalation, turning recoverable queued mail into permanently rejected, lost mail. For Microsoft, the SNDS data illuminates what is behind the 421 deferrals. Operators who read 421 deferrals in the accounting log as the early warning they are, and respond by easing off and fixing the cause, see the condition recover; operators who treat 421 deferrals as a mere delay and keep pushing risk the escalation and the loss.