Toll-free SMS not delivering to end users despite ACS 202 acceptance

the solution was emailing the appropriate MS team and asking to get my specific regulatory documents for SMS messaging application in a state where I could update the request.
somone kicked the submission and then I could update... but now its stuck with this message:

Server not responding Unable to access regulatory documents right now. Please try again later.
why is this so flaky? I see other have this issue with the regulatory documents for SMS messaging blade.

Hi @ERIC PROSHUTO

Thank you for reaching us regarding the issue.

When Azure Communication Services (ACS) returns HTTP 202 (Accepted) for an SMS request, it indicates that the request has been accepted and queued for processing, but it does not confirm successful delivery to the end user. The final delivery outcome depends on downstream processing and must be verified separately using delivery reporting.
For toll‑free numbers, Microsoft documentation identifies toll‑free verification as the required registration and compliance step. This process is specific to toll‑free sender types, while 10DLC/TCR registration applies only to 10‑digit long code numbers (a different sender type). Therefore, no additional carrier registration steps are required beyond toll‑free verification approval for toll‑free SMS in ACS.

Microsoft also documents that ACS toll‑free numbers are domestic within the North America region and can send SMS messages only to supported destinations: the United States, Canada, and Puerto Rico. Additionally, ACS sender types are country/region scoped, meaning messages can only be delivered to regions where the sender is enabled or approved.

Regarding Event Grid, Microsoft documentation explains that ACS integrates with Event Grid to emit SMS events, including:

• Microsoft.Communication.SMSDeliveryReportReceived
• Microsoft.Communication.SMSReceived

These events allow you to track delivery status and receive delivery reports, but Event Grid is not required for SMS delivery to occur. It is used for monitoring, observability, and troubleshooting purposes only.

To diagnose why messages are not reaching end users, Microsoft recommends enabling delivery reports and subscribing to SMS delivery events. Delivery report events include fields such as:

• deliveryStatus (for example, Delivered or Failed)
• deliveryStatusDetails (error or carrier information)

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/sms/handle-sms-events
https://learn.microsoft.com/en-us/azure/communication-services/concepts/sms/sms-faq
https://learn.microsoft.com/en-us/azure/communication-services/concepts/sms/toll-free-verification-guidelines

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

Please "accept" if the information helped you. This will help us and others in the community as well.

Hello ERIC PROSHUTO,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Toll-free SMS not delivering to end users despite ACS 202 acceptance, where messages are marked as “Accepted successfully” but are not received by end users.

Even when a TFN shows an “Approved” status in Azure, carriers may still block or suppress messages if the verification has not fully propagated or if the traffic behavior deviates from the submitted campaign profile. Carrier propagation alone can take several hours to multiple business days after approval. Additionally, ACS toll-free SMS is primarily designed for delivery within the United States, Canada, and Puerto Rico. Sending messages to unsupported or high-risk international destinations can result in silent message drops, even though the API call succeeds. This geographic constraint is documented in the official SMS support matrix:
https://learn.microsoft.com/azure/communication-services/concepts/telephony-sms/plan-solution#countryregion-availability-for-sms Another critical factor is message content and compliance. and adherence to opt-in and regulatory requirements. These requirements are outlined in the official toll-free verification guidance:
https://learn.microsoft.com/azure/communication-services/quickstarts/telephony-sms/apply-for-toll-free-verification

From a diagnostics perspective, the absence of delivery visibility is a major limitation unless delivery reports are explicitly enabled. You should ensure that your SMS request includes:

{

  "enableDeliveryReport": true

}

To receive and track these delivery events, you must configure Azure Event Grid correctly. This includes subscribing to the required event types:

• Microsoft.Communication.SMSDeliveryReportReceived
• Microsoft.Communication.SMSReceived

Your Event Grid endpoint must be reachable and configured without errors. Proper setup is essential for end-to-end observability:
https://learn.microsoft.com/azure/event-grid/communication-services-events

Log validation is another area where issues commonly arise. For outbound SMS troubleshooting, you must use ACS operational and diagnostic logs—not incoming SMS logs. Azure Monitor provides the correct telemetry pipeline for this purpose:
https://learn.microsoft.com/azure/communication-services/concepts/analytics/logs/monitor-communication-services

You can further validate delivery behavior using Kusto Query Language (KQL) to correlate message IDs and delivery outcomes:

ACSOperationalLogs

| where OperationName == "SendSms"

| project TimeGenerated, MessageId, ResultType, ResultDescription

This helps determine whether the message failure occurred before or after carrier handoff.

A practical way to isolate the issue is through controlled testing. Sending simple, plain-text messages (without URLs), to single recipients across different carriers (e.g., AT&T, Verizon, T-Mobile) can help determine whether filtering is content-based or carrier-specific. This method is essential to confirm whether the issue lies in message composition, geography, or telecom enforcement.

Finally, before escalating to Microsoft support via your Azure Portal, you must collect complete diagnostic evidence, including:

• Message ID and Correlation ID
• UTC timestamp
• Recipient phone number and carrier
• Delivery report status
• Event Grid payload data
• TFN verification details
• Sample message content

Without these artifacts, carrier-level tracing cannot be performed effectively.

For additional guidance, refer to the following official resources:

• https://learn.microsoft.com/azure/communication-services/concepts/sms/sms-faq
• https://learn.microsoft.com/azure/communication-services/concepts/telephony-sms/plan-solution
• https://learn.microsoft.com/azure/event-grid/communication-services-events
• https://learn.microsoft.com/azure/communication-services/concepts/analytics/logs/monitor-communication-services

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.