An Azure communication platform for deploying applications across devices and platforms.
For Azure Communication Services, URL whitelisting is not managed by Azure. URL filtering is performed by telecom carriers, so an approved pre-registered alphanumeric sender ID does not mean URLs are whitelisted, and there is no Azure portal, API, or verification method to confirm whether a URL has been accepted by the carrier.
In this case, the failure is not resolved by adding a whitelist entry in Azure Communication Services. Carrier-side filtering can block delivery based on the URL itself, redirects, tracking parameters, unregistered domains, or message format.
For sending with an alphanumeric sender ID, Azure Communication Services supports using an alphanumeric sender ID as the from value, and sending is done through CLI, API, or SDK rather than relying on portal-only behavior. The documented sender formats for SMS include:
- E.164 phone number
- short code
- alphanumeric sender ID such as
CONTOSO
Practical next steps:
- Keep the
fromvalue as the approved sender ID:HomeHeatHub. - Enable delivery reporting, which is already configured in the flow, and review delivery details to confirm whether the carrier is rejecting the message.
- If the failing messages include URLs, test with:
- no URL
- the plain root domain only
- no redirects or tracking parameters
- If messages without links succeed but messages with links fail, that points to carrier-side URL filtering rather than an ACS configuration issue.
- If the issue persists even for simple text-only messages, open a Microsoft support request with the message ID and delivery report details, because the documented Q&A guidance for delivery failures that are not explained by URL filtering is to involve support.
The Power Automate payload shown is consistent with using an alphanumeric sender ID as the sender value.
References: