How Much Email Should an AI Agent Send? Pacing, Limits and Building Reputation
Daily caps, recipient windows and reputation all limit how fast an agent can send. How to pace agent email, why rotating inboxes is the wrong fix, and how to grow volume safely.
By Toan Nhu
An agent can write a hundred emails in the time it takes you to read one. That speed is the point, and it is also the problem. Every mailbox provider limits how much a single account may send, every receiving server judges senders partly on volume, and a model has no built-in sense of when enough is enough. This guide covers the limits you will actually hit, how to pace an agent so it stays under them, and how to grow volume without burning your domain.
Three kinds of limits
It helps to separate the limits an agent runs into, because each one has a different fix.
- Account limits are hard caps set by your email provider. Google, for example, publishes daily sending limits for Gmail and Google Workspace accounts, and exceeding them can suspend sending for a day. That alone is a good reason not to wire an agent into a personal or company Gmail account.
- Platform quotas are the limits of the service your agent sends through: messages per day, per month, recipients per request, and API request rates.
- Reputation limits are invisible. No one publishes them, but receiving servers throttle, defer or filter mail from senders whose volume jumps faster than their history justifies.
The first two are easy to read in documentation. The third is the one that decides whether your agent's mail reaches the inbox.
What Mermail's limits look like
Mermail plan limits apply per workspace, and they are designed around agent inboxes rather than bulk campaigns. At the time of writing, both the Free and Developer plans allow 100 emails per day per inbox, with monthly totals of 1,000 on Free and 10,000 on Developer; Enterprise is custom. On the Free plan, sends through the API or MCP also have an external recipient limiter: up to 10 recipients per request, and rolling windows of 10 per minute, 50 per hour and 200 per day, counting every address in To, Cc and Bcc. Always check the plans page for current numbers.
Two behaviors are worth knowing. Mermail notifies you as you approach your monthly limit. And if a scheduled send runs while the rolling recipient quota is exhausted, Mermail puts it back into the scheduled state and defers it instead of pretending it went out. Your agent should read the returned status, not assume success.
Pace in code, not in the prompt
Telling a model to send no more than 20 emails an hour does not work reliably. It cannot count across sessions, and a retry loop can ignore the instruction entirely. Put pacing in the layer that executes tools:
- Queue every outbound message instead of sending inline. The agent proposes; a worker sends.
- Set a per-mailbox budget below the platform cap, leaving room for replies to people who write in.
- Spread sends with a steady interval and a little jitter rather than bursts.
- When a send is deferred or rate limited, back off and try later. Never retry immediately in a tight loop.
- Stop the queue automatically if bounces or complaints spike, and alert a human.
Scheduled sending is a useful building block here. Instead of holding a worker open, the agent can schedule a message for a specific time and let the platform deliver it.
Why inbox rotation is the wrong fix
When one mailbox hits its limit, the tempting answer is to create ten more and rotate between them. For outbound volume to people who did not ask for mail, that is a way to spread the damage, not avoid it. Receiving providers correlate by domain, IP, content and links, so rotating addresses on the same domain does not hide the pattern. Many providers' terms also prohibit creating accounts to get around limits.
Multiple mailboxes do make sense when each one has a real job. A support agent, a billing agent and a signup inbox that receives verification codes are different identities with different recipients and different reputations. One mailbox per agent or per role keeps threads, permissions and audit trails clean, and it means one misbehaving workflow does not poison the others.
Growing volume: skip the warmup tricks
Automated warmup services that trade fake opens and replies between networks of inboxes are designed to manufacture engagement. Mailbox providers work hard to detect this, and it does nothing for how real recipients respond to your mail. The durable way to build reputation is slower and simpler: start small with messages people expect, such as replies, confirmations and requested follow-ups, then increase volume while bounces and complaints stay low.
Mermail's custom domain guidance says the same: start with a small number of relevant messages to recipients who expect them, increase only while delivery stays healthy, and pause to investigate problems instead of following a fixed daily growth schedule.
A quick sizing exercise
Before launch, write down how many messages each agent should send on a normal day and on a busy day, who receives them, and why they expect them. If the busy-day number is close to your per-inbox cap, you have a design question, not a capacity problem. Either the workflow should be split across agents with distinct roles, or it is really a bulk campaign that belongs in a dedicated marketing tool with consent management.
See current Mermail plan limits
Give each of your agents its own inbox with clear limits and honest delivery statuses. Create a free Mermail inbox.
