agent email rate limiting: a throttle strategy that actually scales

Your agent sent 47 emails on Monday with zero issues. On Tuesday it sent 300. By Wednesday morning, Gmail was returning 421-4.7.28 and every message to a Google address was sitting in a deferral queue.

This is what reactive throttling looks like. The ISP detected a volume spike and started queuing your messages. Your agent didn't get a helpful error page. It got a temporary SMTP rejection code buried in a server response that most agent frameworks don't even surface to the orchestration layer.

The fix isn't to wait it out. The fix is a proactive throttle strategy that prevents your agent from triggering those limits in the first place.

Agent email throttle strategy: quick summary#

1. Warm-up phase (week 1–2): Send ≤50 emails per day per inbox
2. Ramp phase (week 2–4): Scale to 50–500/day with bounce monitoring
3. Steady-state: Maintain 500–2,000/day with multi-signal gating
4. Alert threshold: Pause if bounce rate exceeds 5% or complaints exceed 0.1%
5. Backoff protocol: On 421/450 errors, exponential backoff starting at 60s
6. Scale horizontally: Add warmed domains rather than overloading one
7. Monitor continuously: Combine bounce, complaint, and open-rate signals

Each step is explained below with specific numbers and implementation details.

Why agents get throttled faster than humans#

A human sending cold emails through Gmail might send 30 messages in a morning, take a lunch break, send 20 more in the afternoon. The pattern looks organic to ISP filters. An agent, left to its defaults, fires 200 messages in 90 seconds. That pattern looks like a spam bot.

ISPs like Google and Microsoft measure behavior, not intent. Volume, velocity, bounce rate, recipient engagement. When an agent sends too many messages too quickly from a new or low-reputation domain, every signal points toward spam.

Google responds with 421 or 450 temporary rejection codes. Microsoft returns 452 4.7.500. Yahoo defers with a generic 421 Message from (x.x.x.x) temporarily deferred. Your messages aren't permanently rejected yet, but they're sitting in a queue that might take hours to drain. And if the pattern continues, temporary becomes permanent.

We covered the broader deliverability picture in our guide on email deliverability for ai agents: how to avoid the spam folder. This article focuses on the rate control and throttle strategy side of things.

Proactive vs. reactive throttling#

There are two kinds of throttling, and most agent builders only think about one.

Reactive throttling is what the ISP does to you. Your sending volume or pattern triggered a filter, and now your messages are being deferred or dropped. You don't control when it starts, and recovery takes days.

Proactive throttling is what your agent does to itself. You set daily send caps, ramp-up schedules, and automatic pause triggers before any ISP gets involved. The goal is to never trigger reactive throttling at all.

The difference between throttling and spam blocking matters here too. Throttling (4xx codes) is temporary. The ISP is saying "slow down." Spam blocking (5xx codes, blocklist entries) is permanent until you fix the underlying problem. Proactive throttling prevents both, but recovering from a block is far harder than recovering from a throttle.

Most agent builders skip proactive throttling entirely and scramble to recover after Gmail starts deferring everything. Prevention takes a config file. Recovery takes a week.

The warm-up phase#

Every new domain and every new inbox needs a warm-up period. ISPs have no sending history for your address, so they treat you as untrusted by default.

Safe starting volumes depend on your infrastructure type:

These numbers come from observed ISP behavior, not official documentation. Google and Microsoft don't publish exact thresholds. But the principle is consistent across providers: start small, increase gradually, watch your metrics at every step.

During warm-up, your agent should send to engaged recipients first (people who opted in or are expecting the message), avoid heavy HTML and large attachments, space messages throughout the day instead of sending in bursts, and track bounces per batch.

If your bounce rate exceeds 5% during warm-up, stop. Something is wrong with your list, your DNS authentication (SPF, DKIM, DMARC), or both.

Multi-signal gating: beyond simple rate limits#

Simple rate limiting says "send no more than X per hour." That's a start, but it's blind to the signals that actually determine whether ISPs trust you. An agent can stay under its hourly cap and still get throttled if recipients are marking messages as spam.

A proper agent throttle strategy combines three signals into a real-time decision tree:

Bounce rate (hard bounces ÷ total sends, rolling 24h window). Below 2% is normal. Between 2% and 5%, reduce your send rate by 50% and investigate recipient addresses. Above 5%, pause all sending and clean your list.

Complaint rate (spam reports ÷ delivered messages). Below 0.05% is healthy. Between 0.05% and 0.1%, slow down and review your content and targeting. Above 0.1%, pause immediately. Google's published spam threshold sits right at that 0.1% mark.

Engagement signals (opens, replies, clicks over a rolling 7-day window). If engagement is stable or rising, you have room to maintain or increase volume. If it's dropping, reduce volume before ISPs adjust your sender score downward.

Your agent should check these signals before every send batch. This isn't a weekly review. It's a continuous feedback loop where the agent decides in real time whether to send, slow, or stop.

When signals conflict, defer to the most restrictive one. If your bounce rate is clean but your complaint rate spikes, the complaint rate wins. Always.

Handling throttle events in real time#

When your agent receives a 421 or 450 SMTP response, the correct move is exponential backoff. Not an immediate retry. And definitely not retrying every 5 seconds, which I've seen agents do by default, making the problem actively worse.

The pattern: first retry after 60 seconds, second after 120, third after 240. Double the interval each time, up to a ceiling of 30 minutes. After 6 consecutive failures, mark the message as deferred and escalate to your orchestration layer or alerting system.

SMTP codes your agent must distinguish between:

• 421: Temporary rejection, too many connections or rate exceeded
• 450: Mailbox temporarily unavailable, try later
• 452: Too many recipients or messages in this session
• 550: Permanent rejection (this is NOT throttling, this is a block)

The 4xx vs. 5xx distinction is the most important thing your agent's email handling logic needs to get right. A 421 means "back off and retry." A 550 means "stop trying, something is fundamentally wrong." Treating a 550 like a throttle event wastes retries and can worsen your reputation.

If your agent hits throttle events across multiple recipient domains at the same time, that's a strong signal to pause all sending. Your sender reputation is degrading globally, not just with one provider.

Scaling from 100 to 2,000 emails per day#

You've finished warm-up. Your metrics are clean. Now you want more volume.

The right strategy is horizontal, not vertical. Pushing one domain from 200/day to 2,000/day will almost certainly trigger throttling. Instead, spread volume across multiple warmed domains and inboxes.

A practical setup for 2,000 emails per day:

• 4 sending domains, each warmed over 4 weeks
• 2–3 inboxes per domain
• 200–250 messages per inbox per day
• Messages distributed evenly across business hours

This is where agent-first email infrastructure starts to matter. If your agent needs to manage multiple inboxes across domains, doing it through manual Gmail or Workspace accounts gets tedious fast. LobsterMail lets agents provision inboxes programmatically, and the built-in send limits on each tier act as a safety net against accidental over-sending. The Free tier caps at 1,000 emails per month. The Builder tier at $9/month gives you higher volume with up to 10 inboxes and 500 sends per day.

Those limits aren't restrictions. They're proactive throttling baked into the infrastructure. The same kind of guardrail you'd build yourself on raw SMTP, but already configured.

The cost of getting throttle strategy wrong#

There are two failure modes, and the second one gets less attention.

Over-sending is the obvious one. Your agent blasts too many messages, ISPs throttle you, deliverability tanks. Everything above addresses this.

Over-throttling is subtler. If your agent sends 50 emails a day when it could safely send 500, time-sensitive messages (verification codes, support replies, order confirmations) sit in a queue behind artificial delays. The cost doesn't show up in your bounce rate. It shows up in missed SLAs, slow customer responses, and lost opportunities.

The right throttle strategy sends at the fastest rate your reputation can sustain. Your metrics tell you where that line is. If bounce rate is below 2%, complaint rate is below 0.05%, and engagement is holding steady, you have room to increase. If any signal degrades, pull back immediately.

Start with the warm-up schedule above, implement three-signal gating from day one, and let your agent adjust its own send rate based on what the data tells it. A static cap set once and forgotten is better than nothing, but it's not a strategy.