# Do I need to throttle my sending?

**IT DEPENDS**—mostly handled for you

> Blasting a day's volume in one burst is a classic self-inflicted wound— providers read spikes as spam behavior. But pacing is mostly your ESP's job; your job is the schedule.

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](https://doineed.email/ip-reputation) 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](https://doineed.email/domain-warmup) 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](https://doineed.email/my-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.

---

- Canonical: https://doineed.email/throttling
- Learn more: https://resend.com/docs/knowledge-base/warming-up
- All questions: https://doineed.email/llms.txt

An opinionated answer from the [Resend](https://resend.com) team.