Email Rate Limiting

When you send email too fast, receiving servers push back. Not with blocks or bounces, but with something more interesting: requests to slow down. A 450 error isn't a rejection—it's a conversation. The server is saying: "I can handle your mail, just not this fast."

Understanding rate limiting as a dialogue rather than a set of arbitrary rules transforms how you approach it. You're not trying to sneak past limits. You're trying to send at a pace that works for both sides.

Why Servers Rate Limit

Every mail server has finite resources—CPU, memory, disk I/O, network bandwidth. When too many senders try to deliver too many messages simultaneously, something has to give. Rate limiting is how servers protect themselves.

But there's another reason, and it's more interesting: sending patterns reveal intent.

Legitimate senders have natural rhythms. A company's email flows with business hours. A newsletter goes out in waves as subscribers open and click. Marketing campaigns spread across time zones. This traffic looks organic because it is.

Spammers and compromised accounts behave differently. They blast as fast as possible before getting caught. They don't care about engagement—they care about volume. A sudden spike of 50,000 messages from an IP that normally sends 500 is a red flag, regardless of the content.

Rate limiting isn't just about server capacity. It's a behavioral test. Senders who respect limits demonstrate they care about deliverability. Senders who ignore them reveal they don't.

What Rate Limits Look Like

Messages per hour. The most common limit. Gmail might accept 20,000 messages per hour from a well-reputed sender, while a small corporate mail server might cap you at 100.

Concurrent connections. How many simultaneous SMTP sessions you can maintain to a single domain. Typically 5-20 for major providers, 1-2 for smaller servers.

Messages per connection. How many messages you can send before disconnecting and reconnecting. Usually 100-1,000.

Burst limits. Short-term rate caps—no more than 100 messages per minute, even if your hourly limit is higher.

These limits interact. You might be allowed 10,000 messages per hour, but only through 10 concurrent connections sending 100 messages each before reconnecting. Understanding the full picture matters more than knowing any single number.

The Major Providers

Gmail adjusts limits dynamically based on your reputation. A new IP might be limited to a few hundred messages per hour. An established sender with good engagement metrics might send tens of thousands. Google Postmaster Tools shows where you stand.

Microsoft (Outlook.com, Office 365) follows similar patterns but tends to be more aggressive with deferrals. When Microsoft starts returning 450 errors, they mean it—back off immediately or risk escalation to blocks.

Yahoo requires bulk sender registration and enforces strict limits until you've proven yourself. They're particularly sensitive to complaint rates.

Smaller providers are the wildcard. A corporate Exchange server might only accept 10-50 messages per hour from external senders. A small ISP's mail server might have limits you can only discover by hitting them. For B2B senders, these small domains often matter most—and they're the easiest to accidentally overwhelm.

Reading the Response Codes

When you hit rate limits, servers tell you through SMTP response codes:

450 4.7.1 Client host temporarily rejected: too many connections
451 4.7.1 Rate limit exceeded, try again later
452 4.2.1 Mailbox temporarily unavailable

The 4xx prefix means "temporary failure"—try again later. This is the server asking you to slow down, not blocking you.

5xx codes are different. They mean "permanent failure"—don't try again. If you see 5xx errors after a burst of 4xx errors, you've pushed too hard. The server lost patience.

The difference matters enormously. A 450 error is feedback. A 550 error is a consequence.

Implementing Rate Limiting

Per-domain rate tables define specific limits for each major provider:

gmail.com: 15,000/hour, 10 concurrent connections
outlook.com: 8,000/hour, 5 concurrent connections
yahoo.com: 8,000/hour, 5 concurrent connections
default: 500/hour, 2 concurrent connections

The default matters most. You'll encounter thousands of small domains. Treat each conservatively until you learn otherwise.

Adaptive throttling adjusts rates based on real-time feedback. When deliveries succeed, gradually increase speed. When you receive deferrals, immediately decrease. This is the dialogue in action—the server tells you what it can handle, and you listen.

Time distribution spreads sends across hours or days:

Poor:   50,000 emails in 30 minutes
Better: 50,000 emails over 5 hours
Best:   50,000 emails over 24 hours, timed to recipient time zones

Spreading sends also improves engagement. People are more likely to open email that arrives during their morning than at 3 AM.

Mail Server Configuration

Postfix:

# /etc/postfix/main.cf
smtp_destination_rate_delay = 1s
smtp_destination_concurrency_limit = 5
smtp_destination_recipient_limit = 10

Exim:

acl_check_data:
  defer
    ratelimit = 100 / 1h / per_rcpt
    message = Sender rate overlimit

Most email service providers handle this automatically. SendGrid, Mailgun, Amazon SES, and Postmark all implement adaptive throttling. If you're using an ESP, your main job is not sending so much that you hit your account limits.

Responding to Rate Limiting

When you detect rate limiting (growing queues, increasing 450 errors, lengthening delivery times):

Immediately: Cut your sending rate to that domain by 50% or more. Reduce concurrent connections. Don't try to push through—that escalates to blocks.

Short-term: Spread queued messages over a longer period. If you were trying to send 10,000 messages in an hour, stretch it to 4 hours.

Long-term: Document what rates work for each provider. Build rate tables based on actual experience, not published guidelines (which are often optimistic). Gradually test higher limits when things are stable.

Warm-Up and Rate Limiting

New IPs require especially conservative limits. Receiving servers don't know you yet, and high volume from an unknown IP looks exactly like a spam campaign.

A typical warm-up schedule:

Week 1: 500-5,000 messages per day total, 100-500 per hour to any single domain. Very conservative.

Week 2: 5,000-20,000 per day, 500-2,000 per hour per domain. Still conservative.

Week 3-4: Gradually approach normal limits while monitoring closely for deferrals.

The key is "monitoring closely." Warm-up isn't just about increasing volume—it's about watching how servers respond and adjusting accordingly.

Transactional vs. Marketing

Transactional email (password resets, receipts, notifications) needs to arrive immediately. Users are waiting for it. Rate limiting should be lighter—but not absent. Even transactional email can trigger rate limits if something goes wrong and you accidentally send thousands of password reset emails.

Marketing email can tolerate delays. Spreading a campaign over hours improves deliverability and often improves engagement (you can optimize send times per recipient). Be more aggressive with rate limiting here—there's no cost to the delay and real benefit to the patience.

What Good Looks Like

Deferral rate under 5%. If more than 5% of your sends to a domain receive 450 errors, you're pushing too hard.

Stable delivery times. If time-to-delivery is increasing, queues are building. Something is wrong.

No sudden spikes. Your sending volume should follow predictable patterns. Sudden spikes trigger suspicion even if they don't hit explicit limits.

Provider-specific awareness. You know Gmail can handle more than your average corporate Exchange server, and you treat them differently.

The Underlying Truth

Rate limiting is fundamentally about respect. You're asking to put messages in someone else's mailbox—millions of someone elses. Their mail servers have to process, filter, store, and serve every message you send. When you send too fast, you're saying your convenience matters more than their infrastructure.

The servers that enforce rate limits are doing their job: protecting their users from being overwhelmed. When you implement rate limiting on your end, you're doing your job: being a good citizen of the email ecosystem.

The senders who think of rate limits as obstacles to overcome are the ones who end up blocked. The senders who think of rate limits as a shared agreement about reasonable behavior are the ones who maintain excellent deliverability year after year.

Listen to what the servers tell you. They're not being arbitrary. They're telling you exactly what they can handle. The only question is whether you're paying attention.