What are “per-domain throttling” best practices?

You're blasting out a campaign and suddenly 421 errors start stacking up from one domain. Your sending queue backs up. Emails sit. That's per-domain throttling in action, and it's the mailbox provider politely telling you to slow down before they start rejecting your mail entirely.

Per-domain throttling means limiting how fast you send to each receiving domain individually, rather than treating every destination the same. Gmail, Outlook, and Yahoo Mail all have different rate limits, different queue depths, and different patience thresholds. What works fine for one provider can trigger deferral loops at another.

What the signals actually look like

A 421 response code means "try again later." It's a soft signal, not a rejection. The provider is saying the rate is too high right now. A 452 code means the mailbox is temporarily full or the server is overloaded. Both of these are throttling signals worth listening to. If you keep hammering the same server after receiving 421s, you're making a reputation problem out of a temporary capacity issue.

Concrete numbers to work from

These are rough working estimates that many senders use as starting points. They're not published helps ensure from the providers themselves.

• Gmail: Start around 200-500 messages per hour per IP if you're warming. Established senders can go higher, but watch for 421s and back off quickly.
• Outlook / Microsoft 365: More sensitive to burst spikes than Gmail. Many senders cap at 1,000 per hour per IP and ramp only if they see clean 250 responses.
• Yahoo Mail: Has publicly stated it enforces rate limits by IP and reputation together. Treat it similarly to Outlook in terms of patience for bursts.
• Smaller corporate domains: Often the strictest of all. A small company's mail server may only accept 20-50 messages per hour before deferring.

How to actually implement this

If you're on an ESP like Twilio SendGrid, Postmark, or Mailgun, per-domain throttling is largely handled automatically. Their MTAs read SMTP responses and slow down per destination domain without you touching a setting. That said, you can usually configure retry intervals and max connections per domain if you want more control.

If you're running your own mail infrastructure, you'll need to configure this at the MTA level. Set a max-connections-per-domain value and a max-messages-per-connection limit. Most MTAs (Postfix, PowerMTA (now Bird), Halon) support this natively. The pattern looks like: cap simultaneous connections to Gmail at 5, allow up to 500 messages per connection session, and back off for 15 minutes on any 421.

The rule everyone ignores

But when a provider sends a 421, your system should retry on an exponential backoff schedule, not hammer the queue every 30 seconds. Retry at 5 minutes, then 15, then 30, then 60. Keep the message alive for at least 72 hours before bouncing it back as undeliverable. Most well-configured MTAs do this by default, but it's worth checking your retry settings if you're seeing sustained queue backlogs.

One more thing worth knowing: ignoring throttle signals doesn't just slow your current send. It can escalate from a temporary deferral to a full block if the provider decides you're not cooperating. You go from "please slow down" to "we're done talking." That's a much harder hole to climb out of.

If you're seeing persistent 421 errors from a specific provider and backoff isn't resolving it, it's worth checking whether a reputation issue is underneath the throttling. The blocklist checker is a free place to start.