On September 23, 2026, Microsoft announced that Azure Communication Services (ACS) would retire as a standalone offering. Its official retirement and breaking changes guide explicitly puts ACS Email in the retired category, with an end date of September 30, 2028. For applications sending order confirmations, invoices or security alerts to customers, this is a platform migration rather than a routine SDK upgrade.
The tempting response is to replace one SMTP endpoint with another. That misses much of what an application relies on: verified domains, sending limits, Azure delivery events, logs and bounce handling. A safe migration covers the whole message journey from the business event through the queue and sending service to final delivery status and failure handling.
Key point: ACS Email remains operational during the transition, but Microsoft recommends migrating before September 30, 2028. Microsoft 365 High Volume Email addresses internal mail; Exchange Online primarily serves mailbox correspondence. For external transactional traffic, assess a dedicated application email provider against the actual workload.
1. What Microsoft is retiring, and what it is changing
Microsoft uses two categories. Retirement means that a service or SDK will no longer be available after the announced date. A breaking change means a component remains available, but applications or usage must move to a supported configuration. Microsoft’s impact table places ACS Email, SMS, Chat, Rooms, Job Router and several other capabilities among retirements. Voice and video SDKs, Call Automation, diagnostics and recording fall into the breaking-change category and will remain in supported Teams-aligned scenarios. That distinction does not extend the life of ACS Email.
September 30, 2028 is the announced end date for retired services. During the transition, existing resources continue to operate and Microsoft provides support under the applicable plan, focusing on security, stability and break-fix work. The guide says verified email domains remain supported during this period and quota increase requests may be considered case by case. It does not promise new ACS Email features. After retirement, dependent API and SDK operations may return errors because the service is no longer available.
Microsoft updates its guide as the transition progresses, so check it before onboarding or expanding a workload. A new long-lived application should not casually acquire a dependency with a known retirement date. Existing production applications deserve a controlled migration, however; the timeline allows time for realistic testing and a rollback path.
2. Find the applications that really depend on ACS Email
Inventory the Azure Communication Services resources and linked Email Communication Service resources used by your sending domains. Mail may be submitted through REST, SDKs or SMTP. Searching code only for an SDK method misses line-of-business software configured with an SMTP host. Microsoft’s ACS Email overview and SMTP documentation describe the supported submission paths.
Tie each flow to an application and owner: order confirmation, password reset, appointment notice, invoice, monitoring alert, scheduled report or campaign. Separate internal tenant mail, one-to-one external transactions and bulk sends. Measure average and peak volume, seasonal bursts, business criticality and acceptable time to delivery. A hundred daily messages containing short-lived sign-in codes have different requirements from a hundred thousand overnight statements.
List domains and subdomains, From identities, reply addresses, templates, attachments, service credentials, secrets and rotation procedures. Record privacy and data residency requirements. An API call can be easy to replace while its surrounding dependency on Azure Key Vault, an established domain or Azure Monitor dashboards is harder to migrate.
The return path is part of the product
ACS can publish delivery events through Event Grid, including states such as Delivered, Bounced, Suppressed and Failed. Microsoft’s email logs expose message and recipient level status. If an ERP stops sending to an invalid address after a hard bounce, migrate that process along with the outbound API. A Delivered event means acceptance by the receiving mail server; it is not proof that the message reached the inbox.
Map event consumers such as webhooks, Azure Functions, Event Hubs, dashboards, alerts and suppression-list updates. Preserve a correlation identifier connecting the business event, provider request and later delivery outcome. Without this map, the replacement may accept mail while your support team loses the ability to explain failures or clean bad recipient data.
3. Microsoft alternatives have narrower purposes
The retirement guide names Microsoft 365 High Volume Email (HVE) for internal tenant recipients, such as system notifications to employees. It is worth assessing when all recipients are internal and HVE’s SMTP model and eligibility fit. It does not answer the requirement to send order confirmations to external customers. Microsoft’s HVE documentation defines that scope.
Exchange Online can handle some limited application flows closely related to a business mailbox and human correspondence. Depending on the configuration it can submit through SMTP, relay or Microsoft Graph, but licensing, abuse controls and recipient limits remain those of a collaborative mailbox service. The Exchange Online TERRL measures external recipients across the tenant. Low-volume customer correspondence may fit; moving all ACS notifications and campaigns into additional Microsoft 365 mailboxes is not a general replacement strategy.
A Microsoft 365 SMTP relay is not the same as an external email service provider: mail leaving through Exchange Online remains subject to its applicable limits. Dharmail’s discussion of Microsoft 365 and marketing email architecture explains why mailboxes are not campaign infrastructure. Moving to Exchange Online also changes the model for bounce events and delivery telemetry, not just the server name and credentials.
4. Transactional providers: what should the comparison include?
For application-to-external-recipient mail, a transactional email platform is often the right starting point. Microsoft names Marketplace partners such as Infobip and Telesign; that list is neither exhaustive nor an obligation to purchase one of them. Twilio SendGrid, Brevo, Mailgun and Amazon SES are also candidates. Their products, contracts and operational models differ. Naming a provider does not guarantee a particular region, quota, dedicated IP or feature in the offered plan.
| Option | Submission interface to assess | Delivery feedback | Architectural question |
|---|---|---|---|
| SendGrid | HTTP API and SMTP | Event Webhook | Confirm plan, domain, IP options and event retention |
| Brevo | Transactional API and SMTP | Transactional webhooks | Separate transactional and marketing use; check region and plan |
| Mailgun | HTTP API and SMTP | Events and webhooks to test | Contract for domain and processing region |
| Amazon SES | AWS API and SMTP | Event publishing via configuration sets | Manage AWS identities, quotas, roles and event destinations |
| Microsoft Marketplace partner | Provider-specific | Provider-specific | Review contract, support, data location and Azure integration |
| Exchange Online | Graph, SMTP or relay where appropriate | Message trace and NDRs | Mailbox and tenant limits; not a general application ESP |
The vendors’ own SendGrid, Brevo, Mailgun and Amazon SES documentation confirms the main interfaces. The table describes capability families, not a promise that all commercial tiers include them. Verify event access, limits and data residency in the exact offer under consideration.
API versus SMTP
An API generally gives structured errors, provider message identifiers and metadata that make correlation easier. It requires replacing the ACS client or SDK and adopting new credentials. SMTP can speed migration of older software that exposes only a server and login, but SMTP acceptance is not final delivery. In either case, asynchronous statuses must flow back into the business system.
Avoid embedding a new provider SDK separately in every application. An internal sending adapter can define a stable contract: business message ID, notification type, sending domain, recipient, template, priority and idempotency key. The provider connector is then replaceable, while retry, suppression and audit policy remain under your control.
Reputation, dedicated IP and domain authentication
A dedicated IP is not inherently better than a shared pool. It offers more control and also more responsibility for reputation, warm-up and consistent volume. A small irregular sender may fare better on a well-managed shared infrastructure. Check whether the option exists in the chosen plan, who manages ramp-up, and whether an IP change is possible. Do not infer sustainable throughput from an advertised price.
For each sending domain, prepare DKIM, an SPF record authorizing the services that actually send, and a DMARC policy with alignment checks. The visible From, DKIM d= and SPF envelope domain may differ. Test actual received messages after cutover; simply copying ACS DNS records to a new ESP is insufficient. Our SPF, DKIM and DMARC guide explains the checks.
Bounces, webhooks and observability
Compare event categories rather than the presence of a generic “webhook”: accepted, handed to the recipient server, deferred, rejected, hard bounced, complained, unsubscribed and suppressed. Decide which events trigger a retry, an incident or permanent removal from future sends. Authenticate and deduplicate callbacks, plan for replay after outages, and set a retention period for personal data carried in events.
If operations remain on Azure, feed provider events into the existing observability stack through an appropriate Function, Event Hubs route or other integration. Measure time from business event to recipient-server acceptance, not just successful API calls. A shared correlation identifier should let support reconstruct a journey without exposing unnecessary message content.
Volume and total cost
Obtain an initial quota and ramp-up process, then compare sustained peaks, queueing and recovery after an outage. Separating transactional and marketing flows by domain or subdomain can reduce reputation interference. Validate per-second, daily, domain and account limits in the offered contract; these vary with provider and tier.
Total cost includes sending, optional IPs, event storage, data transfer, support, overages, compliance tooling and integration work. A price per email alone hides the effort of rebuilding telemetry. Prices change too quickly to publish here as permanent figures. Make a dated comparison from actual offers and your measured volume curve.
5. Design a migration that tolerates failure
The target can remain on Azure without ACS Email: application → durable queue → sending worker → ESP adapter → recipient, with event webhook → status processing → monitoring on the return side. Azure Service Bus could hold the queue where the team already operates it; the precise component depends on the application. Decoupling absorbs peaks, supports rate control and protects the business transaction from a provider outage.
Use bounded retries for temporary failures, a dead-letter path for investigation and an idempotency key if the business event can be replayed. Otherwise, a crash between provider acceptance and the local status write can generate two order confirmations. Separate permanent configuration errors from temporary transport failures; endlessly retrying an invalid credential only extends the incident.
Event migration is a data integration task in its own right. ACS used Event Grid and Azure Monitor; the new ESP may push different webhook categories and identifiers. Normalize them into an internal status model, retain raw events for diagnosis according to policy, and verify webhook signatures where offered. “Sent” must not be confused with “accepted by the recipient server.”
6. A practical cutover plan
- Inventory ACS resources, domains, applications, SMTP/API paths, events and business owners. Use Azure Advisor and cost reporting as leads, then verify code and configuration.
- Classify internal mail, external transactions, critical alerts and campaigns. Consider HVE only for suitable internal mail and Exchange Online only for workflows compatible with its limits.
- Compare two or three ESPs on API or SMTP fit, webhooks, quota, region, contract and total cost. Test the capabilities in the offered plan.
- Prepare domains with a transactional subdomain where useful, DKIM/SPF/DMARC, reply addresses, suppression policy and reputation warm-up.
- Build the connector and event return path. Log business and provider identifiers without exposing secrets or unnecessary personal content.
- Test sign-in codes, confirmations, invoices, alerts, attachments and bounces. Simulate exhausted quota, API outages, delayed webhooks and duplicate events.
- Cut over gradually by application or domain. Keep ACS as a temporary rollback path while it is available. Compare delivery rates, latency and complaints over meaningful windows.
- Retire ACS dependencies after sending and telemetry have moved. Record ownership of the new service and contract renewal dates.
A dual-run needs care: sending the same real customer message through two providers creates duplicates. Prefer test recipients, mutually exclusive cohorts or non-delivering comparisons. Validate tracked links and reply addresses too, because a new ESP may rewrite them.
Conclusion
Azure Communication Services Email retirement is scheduled for September 30, 2028. The transition period gives organizations time to design well, but ACS Email is explicitly in the retirement category, unlike selected voice and video components with breaking changes. For external transactional mail, the right alternative must reproduce the needed sending, events, reputation controls and operational visibility.
Do not automatically move ACS traffic into Exchange Online. First establish recipients, volume, latency and bounce requirements. A Dharmail email architecture audit can help map domains and sending paths before a provider is selected.
Sources
- Microsoft Learn, “Retirement and breaking changes guide for Azure Communication Services”.
- Microsoft Learn, “Overview of Azure Communication Services email”.
- Microsoft Learn, “Azure Communication Services – Email events” and “Email logs”.
- Microsoft Learn, “Manage High Volume Email for Microsoft 365”.
- Provider documentation: SendGrid, Brevo, Mailgun, Amazon SES.