421 4.7.0 throttling / 'try again later' — how to fix it

A wall of 421 4.7.0 deferrals looks alarming, but it's the mildest kind of bad news: a temporary throttle, not a rejection. The receiver is telling you to slow down. The mistake that turns it into a real problem is responding by sending harder. Handled calmly, a 421 fades on its own as your sending settles; handled badly, it escalates into a reputation block that takes weeks to climb out of. The whole skill is reading what the receiver is asking for and giving it exactly that.

It's a deferral, not a bounce

The leading 4 in both 421 and the enhanced 4.7.0 means "temporary — try again later." PowerMTA keeps the message queued and retries it; nothing is lost yet. It only becomes a bounce if it keeps being deferred past your bounce-after window. So the goal isn't to rescue individual messages — it's to stop earning the throttle.

Two kinds of throttle

Before reacting, work out which of two situations you’re in, because they recover very differently. A rate limit is the gentle one: the receiver simply wants you to slow down, and the moment you do, delivery resumes. There’s no lasting mark against you — you were going too fast for a moment, you eased off, done. A reputation block dressed up as a deferral is the harder one: the receiver is throttling because it doesn’t trust your IP or domain yet, and no amount of slowing down alone fixes that — it needs sustained good behaviour over days before the throttle lifts.

The tell is whether slowing down clears it. If easing your rate makes the deferrals stop within a send or two, it was a rate limit and you’re done. If they persist even at a crawl, you’re looking at reputation, and the work moves from the queue to the sender: complaints, engagement, authentication and list quality. Diagnosing which one you have first saves you from “fixing” a reputation problem with throttle settings that were never the issue.

What the variants mean

• Gmail "unusual rate" / 4.7.28 — you're sending faster than your reputation supports.
• Microsoft "temporarily rate limited" — throttled on rate or reputation at Outlook/Office 365.
• Yahoo/AOL "[TSS04]" — a complaint-based deferral; recipients are marking you as spam.

Throttle per provider — don't push harder

The right lever is per-provider throttling: enable mx-rollup so all domains behind one provider share a queue, set a sensible max-msg-rate and max-smtp-out per provider, and let backoff reduce your rate when you're deferred. Raising the rate to "clear the queue" does the opposite — it digs the reputation hole deeper.

“Too many concurrent connections”

A common flavour of 4.7.0 is specifically about connections, not message volume: you’ve opened too many simultaneous connections from one IP to a single receiving provider. Receivers cap concurrency per IP, and the cap is usually dynamic — a sender with strong reputation is allowed more parallel connections than one whose standing is unknown or shaky. That’s why there’s no universal number to aim for: the limit you can sustain is a function of how much the provider trusts you.

The fix is to cap your outbound connections per provider rather than chase a magic figure. Even a moderate total volume can trip this if it arrives as a burst of parallel connections, so reducing simultaneous connections — and sending a few more messages per connection instead of opening new ones — often clears it without lowering your actual throughput much. And because the ceiling tracks reputation, the durable answer is the same as everywhere else: a healthier sender earns more headroom.

Why insisting makes it worse

The instinct under a pile of deferrals is to push the queue through — more connections, faster retries, raise the rate to “catch up.” It’s exactly backwards. A receiver that’s throttling you is watching how you respond, and persistence at the same pressure reads as hostile: Gmail in particular treats continued hammering as a signal you’re behaving like a spam source, and escalates. Aggressive retries against a throttling server create more failed attempts, more queue pressure and a stronger negative signal — the opposite of what you wanted.

This is why retry discipline matters as much as rate. The worst possible response to a 421 is to re-queue the same batch at the same speed and let it pound the receiver; each rejected attempt deepens the hole. Back off, widen your retry interval, and let the rate fall — the deferral is a request to reduce pressure, and the fastest route out is to grant it rather than fight it.

The recovery playbook

When a provider route is throttling hard, a simple, disciplined sequence recovers it without making things worse:

1. Pause. Stop that provider’s route for at least ten minutes so the pressure clears and the receiver stops counting failed attempts against you.
2. Retry small. Restart with a single connection and a low rate, then add one connection at a time, watching the response after each step rather than ramping blindly.
3. Find the cause. While it’s paused, check complaint rate, bounce patterns, authentication and the quality of the segment you were sending — the deferral is usually pointing at one of these.
4. Recover. Once it’s flowing, hold a conservative rate for five to seven clean days before testing higher throughput again, so reputation has time to settle.

The thread running through all four is patience: you’re rebuilding the receiver’s willingness to accept you, and that’s earned by steady, modest sending, not by forcing volume through a door that’s being held half-closed.

Tuning the engine’s backoff and throttling

PowerMTA already classifies a 421 4.7.0 correctly as a temporary failure, so out of the box it queues and retries rather than bouncing — KumoMTA behaves the same way. The work is in tuning how it retries and at what rate, because the defaults are generic and a throttling provider wants something gentler than a generic default. Four levers do most of the job, all set per receiving provider via MX rollup so that all the domains behind one provider share a single, coordinated queue:

• max-msg-rate — the messages-per-time ceiling for that provider; the primary throttle.
• max-smtp-out — the cap on simultaneous connections, which addresses the concurrency flavour above.
• max-msg-per-connection — send more messages down each open connection instead of opening many, easing connection pressure.
• retry / backoff interval — widen the time between attempts so a deferred message isn’t hammering the receiver every few seconds.

The trap to avoid is over-aggressive retry configuration. A short retry interval combined with high concurrency turns a polite deferral into a self-inflicted flood that triggers the receiver’s defences further — the misconfiguration does more damage than the original throttle. Set conservative per-provider rates, a sane backoff, and let the engine ease itself back up as the deferrals stop. The point of the config isn’t to maximise speed; it’s to make your sending match what each provider will currently accept.

Fix the cause

Throttling only buys time; the deferrals stop for good when you fix what triggered them. For complaint-based deferrals, bring your complaint rate down through list hygiene and opt-in — check it with the deliverability calculator. For cold IPs, warm them up before sending at volume. For a broader reputation slump, work the emails-going-to-spam diagnostic.

Group your deferrals by code first

Before deciding anything, sort the deferrals by their exact code, because a queue of “421s” is usually several different problems mixed together and each needs a different response. Split 421, 451, 452 and any 550 events apart, and read the human-readable text beside each — it names the real driver. A message about “unsolicited mail” points at reputation or complaints; “the user is receiving mail too quickly” is recipient-level throttling you can’t fix by changing your overall rate; “delivery time expired” means the message sat in retry until your engine gave up.

Treating them as one undifferentiated pile is how people apply the wrong fix to most of the queue. Use the SMTP code lookup to decode the variants, then act per group: throttle the rate limits, fix the cause behind the complaint deferrals, and warm the IPs behind the no-history ones. Diagnosis by code turns a scary wall of red into three or four small, separately fixable problems.

New IPs and domains: warm up before you trigger it

A large share of 421 deferrals come from sending too much, too soon, on infrastructure with no track record. A brand-new domain or IP has zero history, so receivers have nothing to evaluate and default to suspicion — a fresh setup can be deferred at volumes that would be trivial for an established sender. The deferral here isn’t a misconfiguration to fix after the fact; it’s the predictable result of skipping warm-up.

The answer is to ramp deliberately: start low, raise volume gradually over days and weeks, and let each provider build a picture of you as a consistent, wanted sender before you push toward target throughput. A structured warm-up avoids the deferrals entirely, which is far cheaper than triggering them and then recovering reputation. If you’re standing up new IPs for a migration or an expansion, plan the warm-up into the timeline rather than discovering the limits the hard way on launch day.

How the big providers throttle differently

The same 421 means slightly different things depending on who sent it, so tailor the response. Gmail throttles on per-IP volume and velocity relative to your IP’s history — a sudden jump in volume is a classic trigger — and it interprets continued pressure as hostile, so easing off and checking Postmaster Tools for your reputation is the move. Microsoft (Outlook/Office 365) defers on a mix of rate and reputation; consistent, modest sending and a clean IP recover it, and SNDS shows your standing.

Yahoo and AOL lean heavily on complaints, and their TS-style codes (the [TSS04] family) are complaint-driven deferrals rather than pure rate limits — Yahoo suggests waiting roughly four hours after such a deferral before retrying, but the real remedy is fewer complaints, not a timer. Escalating TS codes signal repeated warnings and get progressively harder to clear, sometimes needing direct contact with the postmaster team. The practical lesson: a rate deferral from Gmail and a complaint deferral from Yahoo look superficially alike but call for opposite fixes — slow down for one, clean the list for the other.

Catch it early in the logs

Deferrals are the earliest warning you get, well before reputation damage shows up as outright blocks or spam placement, so the senders who handle 421s best are the ones watching for them rather than reacting after a campaign underperforms. Your engine’s accounting logs record every deferral with its code and the provider that issued it; a rising rate of 421s against one provider is a signal to ease that route now, while it’s still just a throttle.

Pair the logs with the providers’ own dashboards — Gmail Postmaster Tools and Microsoft SNDS — so you can see reputation trending down before it turns into deferrals at all. The goal is to treat throttling as a leading indicator you act on, not a crisis you firefight: a small, early adjustment to rate or list quality is far cheaper than a reputation recovery after the throttle has hardened into a block.

How long it takes to clear

Recovery time tracks which kind of throttle you triggered, and setting the right expectation keeps you from panicking into the wrong action. A pure rate limit clears almost immediately — ease your rate and the next attempts go through, often within minutes. A complaint-based deferral like Yahoo’s clears on the order of hours once you stop pushing (Yahoo suggests waiting around four hours), but only if the underlying complaint rate is actually coming down. A genuine reputation block is the slow one: expect days, and in bad cases a week or more of clean, consistent sending before the throttle fully lifts.

The dangerous window is the middle of that range, where impatience does real harm. If a deferral hasn’t cleared in an hour, the temptation is to “do something” — raise the rate, rotate the IP, force the queue — and every one of those resets the clock or makes it worse. The correct action while you wait is the boring one: hold a low rate, keep complaints and bounces down, and let time and consistency do the work. Reputation recovers on the receiver’s schedule, not yours, and the only way to speed it up is to give it nothing new to worry about.

The bottom line

A 421 4.7.0 is the receiver asking you to slow down, not telling you to stop. Confirm it’s a deferral (the message is still queued), decide whether you’re facing a simple rate limit or a reputation block, and respond by easing pressure rather than adding it. Throttle per receiving provider with MX rollup, cap your concurrency, widen your retry interval, and — when a route is hard-throttled — pause it, retry small, find the cause and recover over a few clean days.

Then fix what earned the throttle: complaints and list quality for complaint-based deferrals, warm-up for cold infrastructure, and the wider reputation picture if slowing down alone doesn’t clear it. Done this way, 421s fade as your rate comes into line with your reputation. If you’d rather not hand-tune per-provider rates, our managed deliverability sets them from your real sending data, and the Auto PMTA Configurator ships sane per-provider throttling and backoff from the first send, so the common deferrals are designed out of your sending before they ever reach a receiver and start counting against you.