Why am I getting 429 MailboxConcurrency errors when sending emails through Mcrosoft?

If you are receiving 429 errors with the message "Application is over its MailboxConcurrency limit" from the Microsoft Graph API even when sending relatively few emails per mailbox, this article explains why this happens and how to resolve it.

Understanding Microsoft's Mailbox Concurrency Limit

Microsoft Graph API enforces a strict per-application, per-mailbox concurrency limit of exactly 4 concurrent requests. This means your Azure application can have a maximum of 4 simultaneous API operations active against any single mailbox at any given moment.

This limit applies to:

• All Microsoft Graph API operations (sends, draft creation, folder listing, read/writes).

• All requests made under your specific Azure app registration credentials.

• Each individual mailbox separately.

When your application triggers parallel operations that cross this boundary, Microsoft immediately rejects subsequent requests, returning a 429 Too Many Requests error containing the RateLimit-Exceeded: MailboxConcurrency header and an accompanying Retry-After parameter.

Why You Hit the Limit at Low Send Volumes

The key insight: A single Nylas send request translates into multiple downstream Microsoft Graph API calls executed sequentially or in rapid burst sequences.

When you call the Nylas /v3/grants/{id}/messages/send endpoint, Nylas orchestrates several real-time Graph API operations on your behalf to execute a clean send:

1. Draft Creation: Creates the raw message template in the user's Microsoft mailbox.

2. Draft Updates / Uploads: Modifies metadata or chunk-uploads files if attachments are involved.

3. Send Operation: Signals Microsoft to dispatch the finalised message.

4. Post-send Read-back / Verification: Fetches the sent item to confirm delivery and ensure correct synchronisation.

Because of this workflow:

• 1 single Nylas send can instantly occupy or transiently queue multiple sub-connections.

• Running just 2 or 3 parallel sends via Nylas to the same mailbox will immediately saturate and overflow Microsoft's maximum pool of 4 concurrent connections.

This explains why you see 429 errors even when you have only sent a few messages within a 60-second window. The issue is purely simultaneous concurrency, not total message count or hourly volume.

Does Nylas Background Activity Contribute?

No. Nylas v3 uses a real-time architecture. It queries providers directly on demand and does not run background sync engines that drain your mailbox concurrency budget. The 429s are generated entirely by the burst calls from your application’s outbound send payloads.

How to Resolve MailboxConcurrency Errors

1. Process Sends Sequentially (Recommended)

Since a single Nylas send triggers multiple Graph operations under the hood, enforce an application-level rule of 1 concurrent send request per mailbox.

2. Space Out Multi-Attachment Outbound Requests

Uploading attachments requires multiple sequential API calls to chunk files. Add an intentional delay of 2 to 5 seconds between back-to-back send requests on the same mailbox if the messages contain files.

3. Parse and Honor the Retry-After Header

When you hit a 429, pause all outbound requests to that specific grant_id for the exact number of seconds specified in the Retry-After header.

Note: To prevent duplicate emails or dropped payloads, rely on upstream concurrency control (Step 1) rather than aggressive retry logic. See our guide on How to Handle Rate Limit Errors for handling strategy details.

4. Differentiate Provider Limits from Nylas Platform Limits

MailboxConcurrency is an upstream restriction enforced directly by Microsoft. Even if your application is safely within your high-volume Nylas platform tier limit, you will still trigger this 429 if you exceed Microsoft's limit of 4 parallel requests on a single mailbox. Check our documentation on Nylas Platform Rate Limits to understand how platform quotas are tracked separately.

Updated June 26, 2026 11:02