Table of Contents
ACS Services to Cease in September 2028
In an odd way to make a major announcement, Microsoft published the Retirement and Breaking Changes Guide for Azure Communication Services as a Microsoft Learn article on September 22, 2026. No Technical Community blog post accompanied the announcement, and I have not found any other formal communication to back up the news communicated in the article. The Learn article states that Microsoft will stop accepting new Azure Communication Services customers from October 23, 2026, and will retire most ACS services on September 30, 2028.
Even at a time of software engineering consolidation at Microsoft, it’s still a huge retreat from the original vision for ACS as outlined at the Ignite 2020 conference. Microsoft positioned ACS as a platform that enabled developers to add voice and video calling, chat, SMS, and telephony capabilities to their applications. Microsoft said that ACS was the first fully managed communication platform offering from a major cloud provider. In a nutshell, Microsoft pitched for developers to use the suite of ACS services to include functionality proven by use in Microsoft cloud applications in their own apps.
The services due to continue appear under the article’s “breaking changes” section (Figure 1) because customers must update existing applications and integrations to keep using them:
- Call Automation
- Voice and Video Calling SDK
- Call Recording
- Call Diagnostics
- Audio Streaming
- Closed Captions
Interestingly, these capabilities are consumed (via internal services) by Teams. The “breaking changes” will remain supported after September 2028, but only when “used with a supported Teams-aligned service.” Developers using the services listed above will have to update apps with the new SDKs and use a Teams-aligned service like Microsoft Teams Phone Extensibility.
Retirement Includes Email Communication Services
Until now, Email communication services (ECS) was the Microsoft preferred option for high-volume external email. Microsoft is quite clear that Exchange Online is not a platform to send large quantities of email to external recipients and has steadily tightened its controls to stop Microsoft 365 tenants who might be tempted to abuse the service. Although customer feedback forced the cancelation of the proposed mailbox external recipient rate limit in January 2026, it’s obvious that Microsoft has no intention of allowing Exchange Online to be used as a platform for high-volume external email distribution.
The plan was to divert this kind of activity to ECS, a service developed specifically built on top of Exchange Online for bulk email delivery. Even though it is reasonably easy to set up and send email via ECS (here’s a working example), the problem with ECS is that it is not Exchange Online. ECS requires different tools, APIs, and administrative processes, making it just as easy for many organizations to use specialized third-party platforms or even on-premises Exchange servers for marketing campaigns and other bulk communications.
Exchange Online’s own High Volume Email (HVE) service muddied the water. HVE started out with limited capability to send messages to external recipients. Microsoft withdrew that capability before HVE achieved general availability, leaving HVE as a service that was only capable of communicating within its host Microsoft 365 tenant. HVE does help by providing a service to apps and devices which need to send email via Exchange Online using basic authentication with the SMTP AUTH submission protocol.
A Possible Path Forward
On the surface, it seems like Microsoft has created a terrible mess and uncertainty around its high-volume email services. ECS will finish in September 2028 at the same time that Microsoft intends to remove HVE’s support for basic authentication for SMTP AUTH. Customers that rely on ECS will need another solution for high-volume external email. At the same time, organizations that have not upgraded applications and devices to OAuth authentication will find that HVE is not a long-term answer for internal communications.
I don’t think Microsoft wants to continually extend the deadline for basic authentication for email submission. Microsoft needs to make the process of moving apps and devices away from basic authentication to OAuth simpler than it is today. Such a step will help customers embrace HVE.
At the same time, Microsoft could introduce a separate pay-as-you-go HVE service for external email. A dedicated HVE service to handle external email might even reuse much of the infrastructure developed for ECS. The service would likely have a different pricing model than the current HVE offering and would benefit from management through familiar interfaces such as the Microsoft 365 admin center and Exchange admin center.
Perhaps a Better Plan is to Come
A replacement for ECS based on a new HVE service is pure speculation on my part. The announcement completely surprised me, and I remain bemused that Microsoft chose to communicate such significant news through a Learn article without any obvious supporting announcement.
Then again, perhaps the information published in Microsoft Learn is simply the first stage of a broader plan for ECS rather than an instruction for customers to find third-party replacements in the Microsoft marketplace.