Mailbox providers don’t just count how much you send—they watch how it arrives. A steady stream reads as a business emailing its customers; the same volume as a five-minute burst reads as an incident. Providers respond with greylisting, deferrals (4xx “try again later”), and stricter scoring, all before a human notices anything.
Why you mostly don’t need to build this
Pacing outbound mail—per-provider connection limits, retry-on-deferral, backoff—is core ESP infrastructure. A good platform smooths delivery and honors receiver throttling automatically; that’s part of what the shared-pool deal buys you. If you’re hand-rolling rate limiters in application code to protect your inbox placement on a managed ESP, you’re probably re-solving a solved problem.
When throttling becomes your problem
- Warmup. A new domain or changed setup has explicit hourly ceilings—on the order of dozens-to-hundreds per hour in week one, not thousands—and honoring them is your scheduling decision, not your ESP’s.
- Volume cliffs. A product launch that 10×es your daily send is a spike no matter who paces the SMTP connections. Spread the send across hours (or days), starting with your most engaged segment—their opens buy goodwill for the rest of the batch.
- One-provider concentration. A list that’s 80% one mailbox provider hits that provider’s limits sooner. If a big send keeps deferring at a single provider, that’s the signal to stretch the schedule.
- Your own infrastructure. Running your own mail server means every per-provider pacing rule is now yours to discover empirically. Enjoy.
The verdict logic
The lean says no because the mechanical half—connection pacing, deferral handling—arrives built into any serious sending platform. The residual yes is scheduling judgment: ramp new things gradually, spread big sends, and treat a wall of deferrals as the provider telling you to slow down. Consistency is the actual asset; throttling is just one way to buy it.