ACS Email: beginSend returns 202 but message status never completes; emails not delivered

Question

ACS Email: beginSend returns 202 but message status never completes; emails not delivered

Darrell Quick 0

Since around 18:45 UTC on 12 November 2026, emails sent from our Azure Communication Services resource are accepted but never delivered, and their status never reaches a final state.

Setup

Communication Services resource, data location United States, linked to an Email Communication Service with a custom domain.
Domain, SPF, DKIM and DKIM2 all show Verified.
Low volume: a few emails a day (sign-in links for a small web app).

What happens

SendMail returns 202 Accepted every time.
Polling the operation status (GetMessageStatus) never returns a final status (Succeeded or Failed). The poller keeps getting a non-final response until we stop it.
The emails never arrive, including in spam, at either of two different recipient providers (Gmail and Comcast).

Evidence (APIRequests metric for the resource)

Hour (UTC), 12 Nov	SendMail 202	GetMessageStatus 200	GetMessageStatus 429
03:00 (working normally)	1	3	0
--------	--------	--------	--------
03:00 (working normally)	1	3	0
18:00	2	145	0
19:00	1	84	3

What we've ruled out

Our application. A test send at 19:34 UTC made directly with the Azure CLI (az communication email send), with no app code involved, stalled the same way and returned no result after 3 minutes.
Domain or authentication problems. All verification states are green, and the 202 means the send is authorized.
Send-rate limits. Sends are accepted, not rejected with 429. The few 429s are on status polling, after the stall began.
A posted outage. Azure Service Health shows no active incident for Communication Services in our subscription.
No changes on our side. We changed no email, domain or ACS configuration between the last good send (03:00 UTC) and the first stalled one.

Questions

Is there a known delivery delay or backend issue affecting ACS Email in the United States data location right now?
Is there anything on our side that can leave messages stuck in a non-final state after a 202? For example, a per-resource hold, a reputation or suppression review, or a sandbox limit on a new or low-volume domain.
We don't have diagnostic settings enabled on this resource yet. Is there any other way to see per-message status for these stuck messages?Since around 18:45 UTC on 12 November 2026, emails sent from our Azure Communication Services resource are accepted but never delivered, and their status never reaches a final state. Setup
- Communication Services resource, data location United States, linked to an Email Communication Service with a custom domain.
  - Domain, SPF, DKIM and DKIM2 all show Verified.
    - Low volume: a few emails a day (sign-in links for a small web app).
What happens
- SendMail returns 202 Accepted every time.
  - Polling the operation status (GetMessageStatus) never returns a final status (Succeeded or Failed). The poller keeps getting a non-final response until we stop it.
    - The emails never arrive, including in spam, at either of two different recipient providers (Gmail and Comcast).
Evidence (APIRequests metric for the resource)

Hour (UTC), 12 Nov SendMail 202 GetMessageStatus 200 GetMessageStatus 429

03:00 (working normally) 1 3 0

18:00 2 145 0

19:00 1 84 3

What we've ruled out
- Our application. A test send at 19:34 UTC made directly with the Azure CLI (az communication email send), with no app code involved, stalled the same way and returned no result after 3 minutes.
  - Domain or authentication problems. All verification states are green, and the 202 means the send is authorized.
    - Send-rate limits. Sends are accepted, not rejected with 429. The few 429s are on status polling, after the stall began.
      - A posted outage. Azure Service Health shows no active incident for Communication Services in our subscription.
        
        No changes on our side. We changed no email, domain or ACS configuration between the last good send (03:00 UTC) and the first stalled one.
Questions
1. Is there a known delivery delay or backend issue affecting ACS Email in the United States data location right now?
2. Is there anything on our side that can leave messages stuck in a non-final state after a 202? For example, a per-resource hold, a reputation or suppression review, or a sandbox limit on a new or low-volume domain.
3. We don't have diagnostic settings enabled on this resource yet. Is there any other way to see per-message status for these stuck messages?

0 comments

2 answers

Your answer

Answer 1

Hi Darrell,

It is likely your email delivery problem is due to today's major Microsoft 365 outage. ACS uses same sending infrastructure as M365/Exchange Online in my experience, and that started having issues around the same time you noticed the problem.

I just performed quick test by sending test email from ACS to one of my email servers, and no attempt was made by MS outbound server to connect to my email server. Typically, after clicking send in ACS an outbound server will connect to my server within seconds. I waited over 25 minutes and still nothing.

I believe once Microsoft 365 outage is resolved your ACS sending will function as normal. Please check Microsoft Service Health Status page for updates using link below:

https://status.cloud.microsoft/

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

Answer 2

Hi @Darrell Quick

A 202 Accepted response doesn’t mean the email was delivered or that all downstream processing has completed. It means ACS accepted the request and started an asynchronous operation. The client must poll the URL in the Operation-Location header until the operation reaches Succeeded or Failed. Even Succeeded means only that the message is out for delivery; final recipient delivery is reported separately through Event Grid or Azure Monitor logs.

Based on your evidence- multiple recipients, the same behavior through Azure CLI, no configuration change, and operations remaining non-final- this doesn’t resemble a normal recipient rejection. Suppression, bounce, filtering, and quarantine are documented recipient-level delivery outcomes, while message-level processing normally reports Queued, OutForDelivery, or Dropped.

The GetMessageStatus 429 responses are probably caused by status polling rather than email submission. ACS limits Get Email Status requests for custom domains to 60 per minute and 200 per hour. The poller should honor the service’s Retry-After response instead of repeatedly polling. This explains the 429s, but it doesn’t explain why the original operations remained pending.

For your questions:

Known service issue: Azure Service Health is the authoritative subscription-specific source. No verified official documentation confirms a current ACS Email incident in the United States data location at the reported time. I recommend opening a support request when the problem persists but isn’t shown in Service Health.
Resource hold, reputation review, or suppression: Suppression is a terminal suppressed delivery status and send-rate limiting, as rejected requests subject to Retry-After. There's no documentation showing that either condition intentionally leaves GetMessageStatus indefinitely non-final.
Per-message visibility: Enable these diagnostic categories on the Communication Services resource:
1. Email Service Send Mail logs
2. Email Service Delivery Status Update logs

Send them to a Log Analytics workspace. The status-update logs include the message ID as Correlation ID, recipient, delivery status, SMTP status codes, and enhanced SMTP status codes. Diagnostic settings must already be enabled for this telemetry to be retained, so they won’t reliably reconstruct messages sent before logging was configured.

For the already-stuck operations, continue polling at the interval specified by Retry-After, preserve each operation ID/message ID and UTC timestamp, and open an Azure support request for backend investigation. The email message ID is required for troubleshooting ACS Email.

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.