What are Exchange Online real sending limits
Microsoft publishes Exchange Online sending limits publicly. They aren't suggestions.
Your account has a 10,000 recipient per day limit. That's not 10,000 emails. It is 10,000 total recipients across all messages within a 24-hour rolling window. Send 20 emails to 500 people each and you have hit your ceiling.
Then there is the rate limit: 30 messages per minute. That is the throttle point for outbound email from a single mailbox. Go faster and Exchange starts rejecting your submissions.
Per-message limits exist too. 500 recipients per email is the hard cap. Hit 501 and Exchange refuses to send. This applies to the To, Cc, and Bcc fields combined.
10,000 recipients/day
Total recipients across all messages in a 24-hour rolling window. Counts To, Cc, and Bcc fields combined.
30 messages/minute
Exchange throttles anything faster. Sending too quickly triggers submission rejections and Outbox stalls.
500 recipients/email
The hard cap per individual message. Exceed it and Exchange refuses the submission entirely.
2.1-second delay
The minimum safe interval between sends that keeps you under the per-minute throttle window.
Different plans get different limits. Enterprise E3 and E5 accounts typically get the full 10,000 recipient daily cap. Small Business Basic and Business Standard plans often see tighter restrictions, sometimes as low as 5,000 recipients per day.
Why Microsoft throttles bulk email
Exchange Online is a multi-tenant platform where millions of organizations share the same physical infrastructure. If one user could blast 10,000 emails in 10 minutes, the entire pipeline slows down for everyone.
Microsoft built guardrails. The throttling is protection for the shared transport service, protection against spam outbreaks from compromised accounts, and protection so the infrastructure stays usable for the 400 million-plus Exchange Online users who aren't sending bulk campaigns.
There is also a spam reputation angle. Sending too fast looks exactly like a compromised account being used for phishing. Automated detection systems flag rapid-fire sending patterns and either throttle or block the account.
What happens when you exceed the limits
The most common result is an HTTP 429 Too Many Requests error if you are using the Graph API. Your campaign is dead until the throttle window resets.
If you are sending through native Outlook, the failure looks different. Your Outbox stalls. Drafts sit there. Nothing goes in and nothing goes out.
Then there is the worst case: account-level blocking. Pop too many throttles in a short period and Microsoft automated abuse systems flag your account. Sending privileges get suspended.
The real cost: The campaign that half-sent. 200 recipients got the email, 800 didn't, and you have no clean way to resume without duplicates or gaps.
How to send bulk email without hitting limits
Two paths. One works. One doesn't.
Cloud APIs (Graph). Microsoft Graph routes every email submission through a shared API gateway that handles all Microsoft 365 requests. That gateway applies global throttling at roughly 4-10 requests per second across all services, not just mail. When you are drafting 500 personalized emails through Graph, every draft creation, recipient addition, and attachment upload counts as a separate request. You burn through your allocation before the campaign even starts sending.
Native MAPI (VSTO). A VSTO add-in runs inside Outlook on your local machine. It talks directly to the Outlook Object Model, which hands off to Exchange through the same transport channel Outlook uses for normal email. No cloud API gateway. No Graph throttling. Drafting happens at local CPU speed. The only limit you respect is the Exchange transport throttle, which native MAPI handles gracefully because it controls the send rate from your side.
Send Without Hitting Limits
FlowDrafts paces your sends automatically with 2.1-second delays and Outbox backpressure.
FlowDrafts approach to staying within limits
We don't fight the limits. We respect them with enough precision that you never notice them.
Three mechanisms handle this. First, a 2.1-second delay between every email submission keeps you comfortably under the 30-per-minute throttle threshold on Exchange Online.
Second, Outbox monitoring. After every 5 messages, FlowDrafts checks the state of your local Outbox. If more than 15 items are pending, the engine pauses new submissions until the queue clears.
Third, a 15-item queue cap on the submission pipeline prevents Outlook from choking on a backlog of outgoing items.
| Feature | Cloud API (Graph) | Native MAPI (VSTO) |
|---|---|---|
| Daily limit | 10,000 recipients plus extra Graph throttling | 10,000 recipients (Exchange limit only) |
| Rate limit | 4-10 requests/second shared across M365 | 30 messages/minute (Exchange transport only) |
| Draft speed | Network-bound, each draft is an API call | Local CPU speed, thousands in seconds |
| Attachments | Chunked HTTP uploads, counts toward quota | Local file reference, instant via MAPI |
| Delay mechanism | Must build custom retry logic for 429 errors | Built-in 2.1s delay with backpressure |
| Data location | Routes through Microsoft cloud API gateway | Processes locally, uses Outlook transport |
Stay Within Outlook Sending Limits
- Track your total recipient count for the day
- Use a minimum 2-second delay between sends
- Monitor your Outbox after every batch
- Choose native MAPI over cloud APIs for bulk sending
- Split campaigns over multiple days if your list exceeds 8,000 recipients
- Verify your plan tier before planning a large campaign