How Email Throttling and Rate Limits Affect Cold Outreach

Most people discover rate limits the hard way: a campaign that ran fine for a week suddenly shows 40 emails stuck in "sending," a handful of 421 errors in the logs, and a reply rate that quietly halves. Nothing in the copy changed. What changed is that you crossed a ceiling — either one your provider enforces, or one the receiving server enforces, or one your own tool should have enforced and didn't.

Throttling is one of the least glamorous parts of outbound infrastructure and one of the most consequential. Getting it wrong doesn't produce a dramatic failure. It produces deferrals, retries, reputation drag, and a slow slide into the spam folder. Here's what the limits actually are and how to pace around them.

{"h2":"Rate limits and throttling are not the same thing"}

A rate limit is a hard ceiling imposed on you. Google Workspace will not let a single user send more than roughly 2,000 messages in a rolling 24 hours. Microsoft 365 will not accept more than about 30 messages per minute from a single mailbox over SMTP client submission. Cross those and you get an error, full stop.

Throttling is pacing you choose: the gap between sends, the daily cap you set per mailbox, the sending window, the concurrency across your pool. Throttling exists to keep you well under every rate limit and, more importantly, to keep your traffic pattern from looking like a machine.

The distinction matters because people conflate them. "Google allows 2,000 a day" is true and completely irrelevant to cold outreach. The limit that governs you is the one receiving mail servers apply to unfamiliar senders, and nobody publishes that number.

{"h2":"What the major providers actually allow"}

{"table":{"headers":["Provider","Daily ceiling (per mailbox)","Short-burst limit","Practical cold-email cap"],"rows":[["Google Workspace (paid)","~2,000 messages / ~3,000 external recipients per 24h","Gmail API and SMTP both rate-limit bursts; exact numbers unpublished","20–40/day"],["Google Workspace (trial)","~500/day","Same","Don't send cold mail from trial accounts"],["Free Gmail","~500/day","Same","Not suitable for outbound"],["Microsoft 365","~10,000 recipients/day","~30 messages per minute via SMTP AUTH","20–40/day"],["Self-hosted SMTP / IMAP host","Varies wildly — often 200–500/day per account","Often a per-hour or per-connection cap","Check your host's TOS"]]}}

Two things stand out. First, the published ceilings are 50–100× higher than what's safe for cold email. Second, the short-burst limits are the ones you'll actually hit — a sequence that fires 60 follow-ups at 9:00:00 sharp from one Microsoft mailbox will trip the per-minute limit before it ever gets near the daily one.

If you want the reasoning behind the 20–40/day figure rather than the provider ceiling, we covered it in how many cold emails you can send per mailbox per day.

{"h2":"The receiving side throttles you too — and that's the one that hurts"}

Your provider accepting a message means nothing. The receiving server gets a vote, and it expresses that vote through 4xx temporary failures. These are not bounces. They're the recipient's infrastructure telling you to slow down.

{"ul":["421 4.7.0 \"Try again later, closing connection\" — Gmail's generic throttle. Usually volume or reputation related.","421 4.7.28 \"unusual rate of unsolicited mail originating from your IP\" — Gmail has decided your sending IP looks like a spam source. This escalates to outright blocking if you keep pushing.","421 4.3.2 \"Service not available\" / \"too many connections\" — Microsoft connection throttling. Often fixed by reducing concurrency rather than volume.","450 4.2.0 greylisting — a deliberate temporary reject on first contact. The server expects a legitimate sender to retry in 5–15 minutes. Spam cannons often don't.","421 4.7.0 [TSS04] deferred due to user complaints — Yahoo telling you the complaint rate from your IP or domain is too high."]}

Greylisting is worth understanding because it's a trap for impatient tools. A correct response is: wait 10–15 minutes, retry once, and if it goes through, note the recipient domain as a greylister. An incorrect response is: retry every 30 seconds until it succeeds, which is exactly the fingerprint the greylist was designed to catch.

Corporate gateways add another layer entirely. Mimecast, Barracuda, and Proofpoint all apply per-sender connection rate limits that are far stricter than what Gmail or Outlook.com apply to consumer mail. We go deeper on that in detecting and handling email security gateways.

{"h2":"The limit that actually bites: your follow-up stack"}

Here's the most common throttling failure in cold email, and it has nothing to do with provider caps.

You set a campaign to 30 new emails per day per mailbox and feel responsible about it. Your sequence has four steps at day 0, 3, 7, and 12. By day 13, each mailbox is sending 30 new emails plus follow-ups generated by the previous 12 days of sending — minus replies and unsubscribes, that's often 90–110 messages a day from a mailbox you configured for 30.

Three fixes, in order of how much I'd recommend them:

{"ul":["Set the cap at the mailbox level, not the campaign level. The number that matters is total messages leaving that address today, across every campaign and every step.","Give follow-ups priority in the queue. If you hit the cap, defer new first-touch sends, not replies to an in-flight thread. Breaking a sequence's timing is worse than delaying a cold open.","Model it before you launch. Steady-state daily volume ≈ (new contacts per day) × (number of steps), roughly, once the sequence fills its pipeline. Four steps at 30/day is a 100/day mailbox."]}

{"h2":"Setting intervals that don't look automated"}

At cold-email volumes, interval length is less important than people think. Thirty messages spread across an eight-hour window is one every 16 minutes — comfortably below any burst limit without doing anything clever.

What matters more is variance and shape:

{"ul":["Randomize the gap. A fixed 300-second interval produces a timestamp pattern no human generates. A jittered 4–25 minute range costs you nothing and looks like a person working through a list.","Use a realistic window. Sending between 7am and 6pm in the mailbox's own timezone is normal. Sending evenly across 24 hours from a single human's address is not.","Skip weekends on most B2B lists, or at least throttle hard. A mailbox that sends 30 on Saturday and 30 on Tuesday looks less human than one that sends zero on Saturday.","Don't ramp the whole pool at once. If you add ten mailboxes, stagger their ramp by a few days each so your domain-level volume curve stays smooth."]}

{"h2":"Per-recipient-domain throttling: the knob most tools don't have"}

If you're selling to enterprises, this is the limit that silently kills campaigns. Suppose you've got 400 contacts at one Fortune 500 company spread across your lead list. Your sender pool is 20 mailboxes, all sending into the same Mimecast tenant on the same morning.

From that gateway's perspective, 20 unfamiliar domains just hit it with a coordinated burst of near-identical messages. That's a pattern-match for a spam campaign, and the response is usually a tenant-level block on all 20 of your domains at once.

A reasonable guardrail is a per-recipient-domain cap: no more than 10–20 messages to any single recipient domain per day across your entire sender pool, and ideally from a smaller number of your sending domains rather than all of them. It slows down big-account campaigns. It also keeps them alive.

{"h2":"How a platform should handle a deferral"}

When a 4xx comes back, the sending tool's behavior determines whether you recover or escalate. What good looks like:

{"ul":["Exponential backoff with a cap — retry at 15 min, 1 hour, 4 hours, then give up and mark the send as failed rather than hammering indefinitely.","Pause the affected mailbox, not the campaign — if one address is getting 421s and the other nineteen aren't, the problem is that address.","Escalate on patterns — three or more throttle responses from the same recipient domain in an hour should automatically slow sends to that domain, not just retry.","Distinguish 4xx from 5xx — a soft deferral is a pacing signal; a hard rejection is a list-quality signal. Treating them the same corrupts your bounce metrics."]}

{"h2":"A default configuration that works"}

If you want numbers to start from on a warmed, authenticated mailbox:

{"ul":["25–35 total messages per mailbox per day, counting follow-ups","Jittered interval of 5–20 minutes between sends","Sending window of 8am–5pm local to the mailbox","Max 15 messages per recipient domain per day across the whole pool","Max 2–3 concurrent SMTP connections per mailbox","Automatic pause on any mailbox with 3+ throttle responses in a rolling hour"]}

Then watch inbox placement, not volume. If placement holds for two weeks, raise the daily cap by about 20% and watch again. If it drops, the previous number was the ceiling, not the new one.

{"h2":"Where Sendvanta fits"}

Sendvanta enforces throttling at the mailbox level rather than the campaign level, so follow-up volume counts against the same cap as first touches and the stack problem above doesn't creep up on you. Sends are jittered inside a configurable window, deferrals get exponential backoff instead of tight retries, and the deliverability health score watches mailbox, domain, DKIM, and IP signals together — slowing or pausing a sender automatically when throttle responses and placement signals start trending the wrong way. You connect your own Gmail, Microsoft 365, or SMTP mailboxes, so the provider limits you're pacing against are genuinely yours, not shared with other customers on a pooled IP. The free plan covers 1,000 active leads, 3,000 emails a month, and up to 10 of your own SMTP mailboxes; paid plans start at $29/mo. More detail on features.

{"faq":[{"q":"Does throttling slow down my campaign enough to matter?","a":"Not in a way that costs you pipeline. Throttling changes how fast a fixed list gets contacted, not how many people you can reach — to send more, add mailboxes rather than raising per-mailbox volume. Twenty mailboxes at 30/day beats five at 120/day on both placement and reply rate."},{"q":"What's the difference between a 4xx deferral and a bounce?","a":"A 4xx is temporary: the receiving server is telling you to retry later, usually because of rate limiting, greylisting, or reputation. A 5xx is permanent — bad address, blocked sender, policy rejection. Only 5xx responses should count toward your bounce rate."},{"q":"Should I use different intervals during warm-up?","a":"Yes. During warm-up, both volume and interval should be conservative — a handful of messages spread widely across the day. Once a mailbox is established, interval matters less than total volume and recipient-domain spread."},{"q":"Can I avoid rate limits by using an SMTP relay service?","a":"You'll avoid your provider's per-mailbox cap, but you inherit the relay's shared IP reputation, which for cold outreach is usually a worse trade. Receiving-side throttling doesn't care which relay you used."}]}