Why Outlook Campaigns Run Slower Than You Set Them
Microsoft caps an Outlook or Microsoft 365 mailbox at 30 messages per minute, and going over it produces no bounce at all.
Microsoft caps an Outlook or Microsoft 365 mailbox at 30 messages per minute, and going over it produces no bounce at all. Excess messages are simply throttled and carried into the following minutes, so the only symptom is delay. Any tool that judges success by the absence of an error will never notice it happening.
Key takeaways
- 30 messages per minute per mailbox is a hard service limit that cannot be increased.
- Exceeding it returns no non-delivery report. Microsoft’s own table describes the user experience as “Slight sending delay; no NDR.”
- 10,000 recipients per day per mailbox, on a 24-hour sliding window — also not raisable.
- One tenant-wide limit can block every user at once, with a clear rejection message.
- Microsoft states plainly that its mail service “isn’t designed for bulk mailing scenarios” and advises spreading sends over time.
What is the per-minute limit?
Thirty. Microsoft’s Exchange Online limits table lists a message rate limit of 30 messages per minute across every business plan, alongside a recipient rate limit of 10,000 recipients per day and a per-message recipient limit customisable between 1 and 1,000 (Microsoft).
The troubleshooting guidance is blunter still: “The recipient rate limit and message rate limit are hard limits enforced at the service level and can’t be increased” (Microsoft). There is no admin setting, no support ticket and no plan upgrade that moves it.
| Limit | Value | Can it be raised? |
|---|---|---|
| Message rate | 30 messages per minute | No |
| Recipient rate | 10,000 recipients per day (24-hour sliding window) | No |
| Recipients per message | 500 by default | Yes, 1–1,000 by an administrator |
| Tenant external recipients per day | Scales with licence count | No, it is derived |
Why is there no error message?
Because throttling is not a failure, it is a queue. Microsoft’s own summary of what happens when each limit is exceeded describes the per-user message rate limit like this: “Messages are throttled (queued and delivered over subsequent minutes),” with the user experience recorded as “Slight sending delay; no NDR,” and no admin alert “unless sustained” (Microsoft).
The service-description footnote says the same thing in different words: when volumes surpass the message rate limit, “any excess in message submission will be throttled and successively carried over to the following minutes,” and this “will typically not block the sender’s account” (Microsoft).
That is the whole trap. Nothing bounces. Nothing errors. Your campaign dashboard shows sends succeeding. The messages just arrive later than you scheduled them — sometimes minutes later, sometimes long enough that a carefully-timed 9am sequence lands over lunch. If your sending tool blasts a burst and then reports success, it has told you the truth and still misled you.
One nuance worth knowing: the same service description notes that if messages are submitted over the rate via direct SMTP client submission, they can be rejected instead, leaving the client to retry. So the same limit can present either as invisible delay or as a retryable rejection, depending on how the mail was handed over.
What is the daily recipient ceiling?
10,000 recipients per day per mailbox, measured on a rolling 24-hour window rather than resetting at midnight. Microsoft’s worked example: a user who sends to 5,000 recipients at 09:00, 2,500 at 10:00 and 2,500 at 11:00 hits the ceiling and “won’t be able to send messages again until 09:00 AM the next day” (Microsoft).
Note that this counts recipients, not messages. A campaign that sends one message each to 10,000 people costs exactly the same as one message sent to a 10,000-person distribution list. Distribution groups from the organisation’s address book count as one recipient; groups stored in a mailbox’s own Contacts folder count every member individually.
Unlike the per-minute throttle, breaching this one is loud: messages are rejected until the trailing 24-hour count drops back under the limit.
What is the tenant-wide limit that blocks everyone?
The Tenant External Recipient Rate Limit. It is the maximum number of external recipients your whole organisation can send to in a day, it scales automatically with the number of licences you hold, and trial organisations get a default of 5,000 external recipients per day (Microsoft).
Breach it and every user in the organisation stops sending externally, with this rejection:
550 5.7.233 Your message can't be sent because your tenant exceeded its daily limit for sending email to external recipients (tenant external recipient rate limit).
This is the limit that turns one team’s aggressive campaign into a company-wide outage: finance can’t invoice, support can’t reply. It also counts distribution group members individually, so a single send to a 1,000-person external group costs 1,000 against the pool.
Two related rejections are worth recognising. A mailbox restricted for suspected outbound spam gets 550 5.1.8, a bad-outbound-sender error requiring administrator action. And an organisation that has tripped a service threshold gets 550 5.7.705 Access denied, tenant has exceeded threshold (Microsoft).
What does Microsoft actually recommend?
Its own words: “Exchange Online isn’t designed for bulk mailing scenarios.” The published guidance for anyone who must send at volume through it is to configure SPF, DKIM and DMARC, maintain list hygiene by removing invalid and bouncing addresses, use a consistent recognisable From address and a visible unsubscribe link, “Spread bulk sends over time rather than sending all at once,” not exceed 30 messages per minute per mailbox, and “Use a custom subdomain for bulk email (for example, m.contoso.com)” to protect the primary domain’s reputation (Microsoft).
Translated into outreach terms: more mailboxes sending modestly beats one mailbox sending hard, and a separate sending subdomain keeps a bad campaign away from the domain your invoices go out on.
How WarmySender handles this
WarmySender’s scheduler paces sends rather than dispatching them in a burst, so a campaign is spread across its sending window instead of being handed to the provider faster than the provider will accept it. Per-domain daily allowances are divided across the day rather than being drainable in one hour, which prevents a single timezone’s morning window from consuming the whole day’s budget.
Every mailbox is also paced individually, with a minimum interval between sends, so adding mailboxes increases throughput while each individual mailbox stays well inside provider limits — the shape Microsoft’s guidance asks for. Rate-limit responses are classified as rate limits rather than as bounces, so a throttled send is retried on schedule instead of marking a good prospect as undeliverable and removing them from your list.
If an AI agent built the campaign, nothing about this changes. Claude, ChatGPT, Cursor, Codex, OpenClaw and Hermes Agent can create, launch, pause and resume campaigns in plain language, but no agent sends a message itself and no agent can raise a limit — the same scheduler paces the result. You can read more in the deliverability reference, the agent rate-limit notes and the agent overview.
Frequently asked questions
Why did my Outlook campaign take hours longer than scheduled?
Almost certainly the 30-messages-per-minute throttle. Excess submissions are queued and carried into following minutes with no error returned, so a burst of several hundred messages trickles out over the following half hour or more (Microsoft). Pacing the campaign fixes the timing; nothing else will.
Can I get the 30 messages per minute limit raised?
No. Microsoft describes both the message rate limit and the recipient rate limit as hard service-level limits that cannot be increased (Microsoft). The only way to send more per minute is to send from more mailboxes.
Does the daily limit reset at midnight?
No. The recipient rate limit uses a 24-hour sliding window, so capacity returns gradually as older sends age out — in Microsoft’s own example, a mailbox that hits the ceiling at 11:00 can send again from 09:00 the next day, when the first block of recipients falls outside the window (Microsoft).
Why did everyone in my company stop being able to email externally?
That is the tenant external recipient rate limit, returned as 550 5.7.233. It is organisation-wide, not per user, so one heavy sender exhausting the daily external-recipient pool blocks every colleague from emailing outside the company until the window clears (Microsoft).
Should I send campaigns from a separate subdomain?
Microsoft explicitly recommends it: “Use a custom subdomain for bulk email (for example, m.contoso.com)” so that campaign reputation is kept away from your primary domain (Microsoft). It is one of the few structural protections you can put in place before sending anything.