Communication Services: Handling HTTP 429 Errors During Email Sending — Rate Limiting Issue

Question

Communication Services: Handling HTTP 429 Errors During Email Sending — Rate Limiting Issue

Azure Admin 0

Problem description

I am experiencing HTTP 429 Too Many Requests errors when attempting to send emails via Azure Communication Services Email using the az communication email send command. This issue impacts the delivery of OTP emails for my application.

Environment

Azure Communication Services Email in India region, tested from a Linux command-line session using a connection string, with a custom sender address and test recipient.

What I've already tried

I reproduced the problem with a direct CLI test send, confirming the 429 response occurs at the email send request. I reviewed documentation related to throttling and rate-limiting, and no additional troubleshooting or configuration changes have been documented beyond the initial report.

Current status

The latest status is that email send attempts continue to return 429 errors, indicating throttling. I am seeking guidance on how to handle this rate-limiting issue, including best practices for retrying and adjusting send volume to prevent further throttling.

Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-09-24T09:48:03.2+00:00

Hi @Azure Admin

Thank you for reaching us regarding the issue.

The behavior you are experiencing is expected due to how Azure Communication Services (ACS) Email handles rate limiting (throttling).

ACS Email enforces per‑minute and per‑hour sending limits, and when these limits are exceeded, the service returns HTTP 429 (Too Many Requests).

Once throttling is triggered:

There is no fixed “cool‑down period”. Instead, ACS uses rolling time windows for enforcing limits.

Any additional requests (including retries) continue to count toward the quota, which can keep the service in a throttled state.

Microsoft recommends avoiding immediate or frequent retries, as they prolong throttling by consuming the remaining quota.

By design, the SDK may automatically retry after a delay, which can also contribute to continued 429 responses if not controlled.

Recommended actions:

Respect the Retry-After header returned in the response before sending new requests.

Implement retry/backoff logic (for example, exponential backoff).

Temporarily stop sending requests completely for some time to allow the rolling counters to fall below the limit.

Ensure there are no other ACS Email resources in the same subscription contributing to the usage.

Reference: https://learn.microsoft.com/en-us/azure/communication-services/concepts/service-limits#email

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-09-27T08:53:56.21+00:00

Hi @Azure Admin

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?

2 answers

Your answer

Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-09-24T09:48:03.2+00:00

Hi @Azure Admin

Thank you for reaching us regarding the issue.

The behavior you are experiencing is expected due to how Azure Communication Services (ACS) Email handles rate limiting (throttling).

ACS Email enforces per‑minute and per‑hour sending limits, and when these limits are exceeded, the service returns HTTP 429 (Too Many Requests).

Once throttling is triggered:

There is no fixed “cool‑down period”. Instead, ACS uses rolling time windows for enforcing limits.

Any additional requests (including retries) continue to count toward the quota, which can keep the service in a throttled state.

Microsoft recommends avoiding immediate or frequent retries, as they prolong throttling by consuming the remaining quota.

By design, the SDK may automatically retry after a delay, which can also contribute to continued 429 responses if not controlled.

Recommended actions:

Respect the Retry-After header returned in the response before sending new requests.

Implement retry/backoff logic (for example, exponential backoff).

Temporarily stop sending requests completely for some time to allow the rolling counters to fall below the limit.

Ensure there are no other ACS Email resources in the same subscription contributing to the usage.

Reference: https://learn.microsoft.com/en-us/azure/communication-services/concepts/service-limits#email

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-09-27T08:53:56.21+00:00

Hi @Azure Admin

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?

Answer 1

Hi,

First, Azure Communication Services Email (ACS Email) is being RETIRED on September 30, 2028. If possible, please consider deploying different email solution instead of ACS Email. This will avoid headache of having to migrate a live production app to a new solution before the deadline.

Retirement and breaking changes guide for Azure Communication Services - ACS Email

https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide#acs-email

Second, if you want to proceed with ACS Email for now, please submit free Service and subscription limits (quotas) support request to increase your sending limits. You should try for a high limit to avoid 429 errors entirely.

Please refer to article below for steps to increase sending limit:

Quota increase for email domains

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-quota-increase

Issue type: Service and subscription limits

Quota type: Azure Communication Services: Email Sending Limits

Enum: 250 (1,000/minute, 3,000/hour)

NOTE: Creating free support request in the Azure portal can be surprisingly confusing/difficult. If you have issue creating the request in the portal, please reply in comment below and I will help you. They recently changed the portal flow so my existing instructions/screenshots are inaccurate.

Third, since your use case is for time-sensitive OTP messages, I recommend you treat 429 errors as hard failures and provide some sort of alternate way for the user to sign-in if they occur. The idea would be to have your email sending limit be high enough (much higher than if it was non-time sensitive use case) to avoid throttling.

Thanks.

-TP

Answer 2

Azure Admin 0

@Golla Venkata Pavani Thanks for the response.

We are planning to go live with email OTP-based login for one of the prod apps. The platform currently has around 900 users, and OTP emails will be triggered during user login.

To ensure smooth login access and avoid delivery throttling during peak usage, we need below

Hourly limit: 1,500 emails This quota will help us support production login traffic, retry attempts, and any login spikes during shift changes or operational peaks.

0 comments