Understanding "AV3 BADRequest is throttled" Exception when polling Microsoft Cloud Email via javax.mail

Hello SamSam,

I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

Hello,

What you are experiencing is actually expected behavior from the Microsoft cloud messaging infrastructure when the application exceeds the allowed request frequency against the mailbox service. The error message AV3 BADRequest is throttled indicates that Exchange Online has temporarily rate-limited your service account because the polling pattern is generating too many requests within a short period of time.

The “Suggested Backoff Time” value is Microsoft’s way of telling your application exactly how long it should wait before retrying. In your example, 201317 milliseconds is roughly 3.3 minutes, which aligns with your observation that the connection works again after several minutes of inactivity. This throttling mechanism exists to protect the service from excessive API consumption and to ensure fair resource allocation across tenants.

From an architectural standpoint, continuously polling the inbox with javax.mail/IMAP at aggressive intervals is not considered an optimal design pattern for Microsoft 365 cloud mailboxes. Instead of frequent polling loops, Microsoft recommends implementing exponential backoff logic and significantly reducing the polling frequency whenever the server returns throttling responses.

If possible, I would also strongly recommend moving away from legacy IMAP polling and leveraging the Microsoft Graph API with change notifications (webhooks) or delta queries. These modern approaches are far more scalable, cloud-friendly, and specifically designed for enterprise synchronization workloads. Additionally, ensure that your application properly closes idle connections, reuses sessions efficiently, and avoids opening multiple concurrent mailbox sessions under the same service account.

I hope this helps clarify the root cause and the recommended optimization path. If you find the explanation helpful, please feel free to hit “Accept Answer”.

Jason

The exception indicates that the mailbox is being throttled by the Microsoft cloud email service because the client is issuing too many requests in a short period. This is expected behavior: Exchange Online and related Microsoft 365 services enforce per‑mailbox and per‑client limits to protect service performance. When those limits are exceeded, the service temporarily blocks further requests and returns an error with a backoff time. After the throttling period expires, access resumes without changes on the client side, which matches the observed behavior when the polling is paused for several minutes.

Architecturally, this is the same class of protection described for other Exchange Online scenarios:

• When a client repeatedly sends the same commands in a very short time period, Exchange Online enables throttling protection to prevent that client from affecting service performance. In ActiveSync scenarios, this manifests as repeated commands followed by 503/blocked responses and a temporary access block.
• For SMTP AUTH or mail submission, continuous errors or misconfigurations can trigger throttling, and the mailbox resumes normal operation only after the throttling period elapses.

In the Java/IMAP scenario with javax.mail, the pattern is similar: frequent polling or inefficient access patterns cause the service to detect excessive load from that mailbox or client and respond with a throttling error and a suggested backoff interval.

To optimize the application and avoid or reduce throttling:

1. Honor the backoff interval
   Implement logic in the polling service to detect the throttling error and then stop issuing requests for at least the suggested backoff time. Do not immediately reconnect or retry in a tight loop.
2. Reduce polling frequency and duplicate commands
   • Increase the interval between mailbox polls. Very short polling intervals can look like abusive behavior.
   • Ensure the code does not repeatedly issue identical commands (for example, repeatedly fetching the same folder or messages without state tracking), which is analogous to the repeated Sync commands that trigger throttling in mobile/ActiveSync scenarios.
3. Optimize access patterns
   • Cache state (UIDs, last processed message, etc.) so that each poll only fetches new or changed items instead of re-reading the entire mailbox.
   • Avoid unnecessary folder scans or full-message downloads when only headers or specific fields are needed.
4. Scale out correctly
   If multiple instances of the CRM service are connecting to the same mailbox, coordinate them so that they do not all poll simultaneously, which would multiply the request rate and increase the chance of throttling.
5. Monitor and adjust
   Track how often throttling occurs and adjust polling intervals and access patterns until throttling events become rare or disappear.

Because throttling is enforced by the service and cannot be disabled by support, the long‑term solution is to design the client to be “well‑behaved”: lower request rates, avoid repeated identical operations, and respect backoff times when throttling is signaled.

References:

• A mobile device intermittently can't connect to Exchange Online
• Continuous error throttling for SMTP AUTH submissions in Exchange Online
• Fix NDR error code "451 4.7.500-699 (ASxxx)" in Exchange Online