AI SDR Send Limits: Rate-Limit an Outbound Agent Before It Burns a Domain
Google lets a Workspace user send 2,000 emails a day, and a cold outbound mailbox should send closer to 30. An AI SDR needs four caps of its own (per mailbox, per recipient company, per campaign and a send window), enforced inside the send tool where the model cannot talk its way past them. When the campaign cap trips, the agent should stop and page a person, because hitting it usually means something upstream broke.
A domain takes weeks to warm.
It takes one bad afternoon to burn. A human SDR physically cannot send 600 cold emails before lunch, so nobody ever had to write that rule down. An agent can, and if a list gets imported twice or a filter quietly returns everyone, it will do exactly that with no sense that anything is off, because every one of those sends looked like a correct next step from inside the loop. The usual advice on this (warm up the mailbox, keep volume reasonable) assumes a person with a sense of reasonable. Our deliverability guide covers the warmup side. This page covers the numbers an agent needs written into code.
Send limits compared
Most of the limits people quote are ceilings set by providers to protect the provider. They are generous on purpose. They were sized for a busy salesperson answering customers all day, and one mailbox writing to strangers needs a far smaller number.
| Limit | Set by | Number | What it protects | When you hit it |
|---|---|---|---|---|
| Google Workspace daily sending limit | 2,000 messages per user per day (500 on a trial account) | Google’s own infrastructure from abuse | The mailbox stops sending for up to 24 hours | |
| Microsoft 365 (Exchange Online) limits | Microsoft | 10,000 recipients per day, 30 messages per minute | Microsoft’s infrastructure | Sends come back as non-delivery reports until the window passes |
| Gmail API per-user quota | 250 quota units per second; one send costs 100 | The API | A rate-limit error, which an agent will happily retry | |
| Gmail bulk sender threshold | 5,000 messages a day to personal Gmail accounts; spam rate kept under 0.3% | Gmail users | Stricter authentication rules, permanently, and junked or rejected mail | |
| Sequencing tool mailbox limit | You, inside Instantly, Smartlead or similar | Whatever you type in; 30 to 50 is common | One mailbox’s reputation | Extra sends wait for tomorrow |
| Caps in your own send tool | You | Our starting point: 30 per mailbox, 2 first touches per company, a fixed campaign ceiling | Your domain, and the prospect’s patience | The tool refuses, logs the refusal, and pages a person |
Read the bottom two rows as the ones that matter. Everything above them will let you wreck your reputation long before it stops you.
The bulk sender row deserves one more sentence. Google's rules say that once a domain sends 5,000 messages to personal Gmail accounts in a single day, it is treated as a bulk sender from then on, with no way back, so a single runaway afternoon can change how Gmail judges that domain for good.
The four caps we put in the send tool
Per mailbox, per day
10 a day for a new mailbox, rising to about 30 over three weeksMailbox and domain reputation build slowly and fall fast. Thirty cold emails from a real person’s mailbox is a believable day. Three hundred is not.
Per recipient company, per day
2 first touchesSix people at one company getting the same opener on the same morning will compare notes in Slack before lunch, and one of them forwards it to IT.
Per campaign, per day
The number the plan says, plus a little slackIf the plan was 90 sends and the agent tries 400, something upstream broke, usually a list imported twice or a filter that stopped filtering. This cap exists to notice that.
Send window
Business hours in the recipient’s time zoneAn agent that runs all night will send all night unless told otherwise, and a cold email stamped 3:12 a.m. looks like what it is.
The per-company cap is the one teams skip. It is also the one a prospect notices first, since nobody inside a target account sees your mailbox volume but they all see each other.
Count at the intent, refuse in the tool
Put the counters in the same place as the duplicate guard from our duplicate emails guide: the send tool, backed by one table. The tool increments the count when it writes the pending row, before the provider call. Counting only confirmed sends sounds more accurate and is worse, because a burst of timeouts then looks like zero volume while the mail is in fact leaving.
A line in the system prompt saying "send no more than 30 emails a day" is a wish. The model does not know how many it sent yesterday, or this morning before its context got summarized, and it cannot count sends made by a second run that started while the first was still going.
Now the opinion we would defend: when the campaign ceiling trips, stop the agent. Do not queue the overflow for tomorrow. A queue is the friendly default in every sequencing tool, and for a person who added too many contacts it is the right one. For an agent, an attempt to send four times the plan is evidence of a bug, and a queue keeps that bug alive overnight and sends its output in the morning. We wire the ceiling straight into the kill switch, so a tripped cap pauses new sends while replies keep flowing, and the refusal lands in the audit log with the contact it refused.
The mailbox cap is different. Hitting it on a busy day is normal, and those sends can wait.
Where each cap fits (and where it does not)
If your agent only enrolls contacts and Instantly or Smartlead does the sending, use their mailbox limits and warmup. They have tuned ramp schedules across a lot more mailboxes than you will ever own, and rebuilding that yourself is a waste of a sprint. What they cannot see is the agent. They will not notice that it enrolled 1,400 people when you asked for 200, so keep the campaign ceiling and the per-company cap on the enroll tool.
If the agent sends through the Gmail API or Microsoft Graph directly, you own all four caps. Build them before the first live send.
If you run a handful of mailboxes on a domain you also use for invoices and customer email, stop and move outbound to a separate domain first. No cap protects a domain you cannot afford to lose.
If you would rather watch an agent run at sane volume before writing any of this yourself, that is what a pilot is for. Ours is free: we run your first campaign, you see who was contacted, from which mailbox and when, and the free pilot costs nothing if it does not work. After that, pricing is per qualified meeting, agreed with you.
Trip it on purpose
Run a shadow mode campaign with the ceiling set at 20 and a list of 200. You want to see the twenty-first attempt refused, the refusal logged with the contact attached, a page go out to a real phone, and replies still being handled after the pause. Then drop ten contacts from one company into the list and confirm only two get a first touch that day. If the refusal happens and no phone buzzes, you have a cap that works and that you will never hear from, which on a live campaign is close to having none.
What a cap cannot fix
A bad list sent slowly is still a bad list.
Why we care
After the free pilot we get paid per qualified meeting, and a qualified meeting is one where the prospect shows up. Prospects do not show up from the spam folder. Mira runs 24/7 on OpenClaw from a Mac mini in San Francisco, which means the send window is the only thing standing between a prospect in Boston and an email at 6 a.m. their time. The exclusion list guide covers who the agent should never email at all, and how Mira works walks through the rest, from first email to booked call.
Jascha Kaykas-Wolff founded Mira Outbound and runs Mira, the outbound agent described across this site, on OpenClaw. These guides come from the guardrails that agent actually uses. kaykas.com