Email Throttling: What It Is and How to Handle It
Email throttling is when a receiving mail server deliberately slows your delivery, accepting a limited number of messages per connection or per hour instead of your full send. It is a temporary rate limit rather than a rejection. Providers throttle senders they do not fully trust yet, so the fix is pacing plus reputation repair.
What throttling looks like from your side
Throttling almost never announces itself. You hit send on 40,000 messages, the dashboard says the campaign is running, and four hours later it is still running. Meanwhile a second campaign to a different domain finished in eleven minutes. That gap is the tell.
The three symptoms that show up together:
- A long delivery tail. Most of the list is delivered quickly, then a stubborn remainder trickles out over hours or drains into a deferral queue.
- Domain-shaped skew. Gmail is at 96% delivered while Microsoft-hosted domains sit at 60% and climbing slowly, or vice versa.
- 4xx responses in the logs, not 5xx. A 4xx is "not now." A 5xx is "not ever." Throttling is always the former.
If your platform hides raw SMTP responses, you are flying blind on this. Any sender doing real volume needs access to per-message response codes, either in the UI or over an events webhook.
Why mailbox providers throttle
Receiving servers do not have a "spam" switch and a "clean" switch. They have a dial, and throttling is how they buy time to make up their minds about you. The dial moves based on:
- Sending history. A brand-new IP or domain has no track record, so providers accept a small slice and watch what recipients do with it.
- Volume shape. Going from 2,000 to 200,000 in a day looks like a compromised account, regardless of your intentions.
- Engagement signals. Low opens, low replies, fast deletes, and complaints push the dial down within hours.
- Infrastructure hygiene. Missing or misaligned SPF, DKIM, and DMARC, no reverse DNS on the sending IP, or a mismatch between envelope and header domains.
- Neighborhood. On shared IP pools, another sender's bad week becomes your slow afternoon.
None of these are punishments. They are risk controls, and they relax as your record improves. Our fuller walkthrough of what drives email deliverability covers the reputation side in depth.
Reading the response codes
Deferral text varies by provider, but the shapes repeat. Here is what you will actually see in a log and what each one is asking you to change.
| Response | What it usually means | Your move |
|---|---|---|
| 421 4.7.0 Try again later | Connection or rate limit hit for this IP | Cut concurrent connections, retry with backoff |
| 450 4.2.1 Recipient is receiving mail at too fast a rate | Per-recipient or per-domain pacing limit | Slow the per-domain rate, spread the send |
| 421 4.7.28 Unusual rate of unsolicited mail | Reputation-driven throttle, not just volume | Pause, prune inactives, fix content and consent |
| 452 4.5.3 Too many recipients | Too many RCPT TO commands in one envelope | Lower recipients per message envelope |
| 441 4.4.1 / timeout | Connection dropped or refused mid-transaction | Retry later, check IP reputation and rDNS |
| 550 5.7.1 blocked | Not throttling at all, this is a block | Stop sending to that domain, request delisting |
The last row matters most. Teams routinely treat a hard block as throttling and keep retrying, which deepens the reputation hole. Sort your bounce log by first digit before you do anything else.
Diagnose before you change anything
Work through this in order. Skipping to step four is how people "fix" a content problem with a slower send rate and wonder why nothing improves.
- Split responses by class. Count 4xx versus 5xx for the campaign. If 5xx dominates, you have a block or a list-quality problem, not throttling.
- Group deferrals by receiving domain. One provider means a provider-specific issue. Every provider at once means the problem is you: authentication, IP, or content.
- Check the timing. Deferrals that begin after the first few thousand messages point at rate limits. Deferrals from message one point at reputation or authentication.
- Verify authentication on a live message. Send to a seed address and read the headers. You want SPF pass, DKIM pass, and DMARC alignment on the visible From domain.
- Compare against a known-good segment. Mail your most engaged 500 subscribers. If those deliver cleanly and the broader list defers, the list is the variable.
Fixing throttling: pacing that actually works
The single most effective change is to stop sending everything at once. A campaign released over four hours with per-domain caps will out-deliver the same campaign fired in six minutes, every time.
Concrete adjustments, roughly in order of impact:
- Cap per-domain concurrency. A handful of simultaneous connections per receiving domain is plenty. Dozens is what triggers 421s.
- Reuse connections. Send multiple messages per SMTP session instead of opening and tearing down a connection for each one.
- Honor exponential backoff. Retry a 4xx after minutes, then tens of minutes, then hours. Hammering a deferral every 30 seconds reads as abuse.
- Send your best segment first. Opening a campaign with your most engaged subscribers generates positive signals while the provider is still deciding.
- Separate streams. Keep password resets and receipts off the same IP and subdomain as your promotional blasts, so a bad newsletter never delays a login code. That separation is one of the main reasons to run a proper SMTP relay for transactional mail.
A sane ramp schedule for new IPs and domains
If throttling started because you moved to new infrastructure, you are not throttled so much as un-warmed. Ramp deliberately. The volumes below are an illustrative starting shape, not a rule; scale them to your list size and always send to your most engaged contacts first.
| Stage | Daily volume | Audience | Watch for |
|---|---|---|---|
| Days 1-3 | Up to ~500 | Opened in last 30 days | Any 4xx at all |
| Days 4-7 | ~1,000-3,000 | Opened in last 60 days | Deferral rate by domain |
| Days 8-14 | ~5,000-15,000 | Opened in last 90 days | Complaint rate creeping up |
| Days 15-21 | ~25,000-50,000 | Active 6 months | Delivery time lengthening |
| Day 22+ | Full volume | Full engaged list | Hold steady, avoid spikes |
Two rules override the table. Never double volume two days in a row, and if deferrals rise, hold at the current level rather than pushing through. Warming is a conversation, not a countdown.
What throttling is not
Three things get mislabeled as throttling and need different responses. A block is a 5xx with policy language, often naming a blocklist; retrying makes it worse. A spam-folder placement problem shows perfect delivery numbers with collapsed opens, because the message was accepted and then filed away. And a slow queue on your own side is your platform's outbound rate limit, not the receiver's, which you diagnose by checking whether messages are even leaving your queue.
Delivery rate and deliverability are not the same measurement, and conflating them is the most common reason teams chase the wrong fix for weeks.
Preventing the next round
Throttling is mostly a lagging indicator of habits. Send on a consistent cadence rather than in quarterly bursts. Suppress anyone who has not engaged in six months instead of hoping they wake up. Keep authentication correct automatically instead of hand-editing DNS once a year. Watch complaint rate as your primary early warning, since it moves before delivery time does. And keep your promotional and transactional streams on separate subdomains so their reputations never contaminate each other.
Do those five things and throttling becomes an occasional, self-resolving nuisance rather than a monthly fire drill.
Frequently asked questions
How long does email throttling last?
Most volume-based throttling clears within a few hours once your retries succeed and the receiving server sees normal behavior. Reputation-driven throttling can persist for days or weeks until engagement improves and complaints fall.
Does throttling hurt my sender reputation?
Being throttled does not itself damage reputation, but ignoring it does. Aggressive retries against deferrals, and continuing to push volume through, both signal abuse and can escalate a temporary slowdown into a block.
Is throttling the same as being blacklisted?
No. Throttling returns a temporary 4xx response and resolves on its own with proper retries. A blocklist listing produces a permanent 5xx rejection and requires you to fix the underlying problem and request delisting.
Can I avoid throttling by using more IP addresses?
Spreading volume across many new IPs usually makes things worse, because each one starts with no reputation and the pattern itself looks evasive. Concentrated, consistent volume on a well-warmed IP performs better.
Should I use a dedicated IP to reduce throttling?
A dedicated IP helps only if you send consistent volume, roughly tens of thousands of messages per month or more. Below that, a well-managed shared pool with steady traffic will typically be throttled less than an underused dedicated IP.
Ready to stop guessing about deferrals? IGSendMail handles pacing, retries, and automatic SPF, DKIM, and DMARC setup for you, with 99% inbox deliverability and unlimited contacts on paid plans from $19/mo. Launch your first campaign with IGSendMail.