Azure Communication Services Email Is Retiring: Which Replacement Fits Your App?

Azure Communication Services Email is scheduled to retire on September 30, 2028. The practical question is not just what is changing, but what kind of email your workload actually sends. [Microsoft’s retirement guidance](https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide) also makes an important distinction: retirement of ACS Email is not the same as the separate Teams-aligned breaking changes, and the October 23, 2026 restrictions first apply to phone-number acquisition for certain PSTN and SMS scenarios, not as a blanket Email signup cutoff. Existing verified email domains remain supported through the retirement period, but Microsoft also says new Email onboarding may change, so new long-term dependencies are risky.

The decision starts with recipient scope, not brand names

For most migrations, the right replacement depends on whether your app sends only inside your tenant, to both internal and external recipients, or from a device or application that needs a mail path with different authentication and network constraints. That is why there is no single universal replacement for ACS Email. A good fit for one workload can be a poor fit for another, even if both are called application email.

Four practical replacement paths

  • Microsoft 365 High Volume Email fits tenant-only automation that sends to internal recipients. It supports Microsoft 365 Worldwide standard multi-tenant environments, sends only within the tenant, and has message and recipient caps such as 50 recipients per message and a 10 MB maximum. It uses dedicated accounts with billing policy assigned to an Azure subscription, so it is not free and it is not a general external-email channel. The HVE account has no mailbox and does not require an individual Microsoft 365 license, but it does require a PAYG billing policy to be assigned before sending. [Microsoft High Volume Email guidance](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/high-volume-mails-m365)
  • Mailbox-based SMTP submission or Microsoft Graph fits workloads centered on a licensed mailbox and may support internal and external recipients when tenant policy and app capabilities allow it. OAuth is preferred where possible. This route is best when the workload already maps naturally to a mailbox identity and mailbox sending limits are acceptable. [Microsoft SMTP submission guidance](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365) [Microsoft replacement comparison](https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide)
  • Microsoft 365 SMTP relay fits a narrower class of supported scenarios, especially on-premises devices or applications that need relay through Microsoft 365. Microsoft recommends connector-based relay with TLS certificate or a suitable unshared static public IP and port 25. Microsoft explicitly excludes third-party-hosted apps, including Azure, from this SMTP relay scenario, so do not treat it as a default cloud-app option. [Microsoft SMTP relay guidance](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)
  • A specialist transactional SMTP or API provider is often the most realistic path for external application or customer email when you need a service designed for that job. Microsoft’s own documentation points legitimate bulk commercial email use toward specialist third-party services rather than Exchange Online as a bulk-mail substitute. Verify features and limits with each provider directly; do not assume any specific vendor fit from the category alone. [Exchange Online sending limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits)

Three hypothetical workload examples

Example 1: an internal operations app sends shift-change alerts to employees in the same Microsoft 365 tenant. In that case, HVE may be a candidate because the traffic stays inside the tenant. It still needs message sizing, recipient counts, and routing rules checked against HVE limits, and it is not suitable if the same app later starts emailing customers externally.

Example 2: an Azure-hosted order system sends purchase receipts to customers outside the organization. That workload is usually not a good match for HVE because HVE is tenant-only. Mailbox submission or Graph may work only if your tenant policy, mailbox design, and limits line up with the volume and the app can authenticate correctly. If the application needs stronger separation from mailbox operations or more transaction-oriented behavior, a specialist external email provider may be the cleaner route.

Example 3: an office scanner emails staff and outside suppliers. Compare the supported relay path with mailbox submission against the device’s authentication and network capabilities. Test attachments and failed-send recovery before choosing.

A simple inline decision worksheet

  • Who owns the sender: app, device, shared mailbox, or service account?
  • Where does it run: on-premises, Azure, or another hosted platform?
  • Who receives the mail: only internal users, or external customers too?
  • How many recipients per message and per day, and what is the peak burst rate?
  • What message size, retry pattern, and attachment behavior are required?
  • Does the workflow need OAuth, SMTP auth, relay, or API-based sending?
  • How will you handle bounces, suppression, duplicates, and audit logs?
  • Can the domain’s SPF, DKIM, and DMARC be aligned with the chosen route?
  • What is the rollback plan if deliverability, policy, or rate limits do not match expectations?

Migration checklist

  • Inventory every sender, template, trigger, and recipient class before changing platforms.
  • Separate internal-only traffic from external customer mail, because the right replacement may differ for each.
  • Check current mailbox and tenant limits if you are considering Microsoft 365 submission or Graph.
  • Validate whether the workload is allowed to use SMTP relay or whether it is disqualified by hosting location.
  • Map retries, idempotency, and duplicate-prevention logic so cutover does not resend messages.
  • Confirm domain authentication and sender identity settings for the destination platform.
  • Run controlled test batches, then compare accepted sends with actual delivery signals and bounce handling.
  • Stage the migration by workload, not all at once, and keep a rollback path open.
  • Monitor Microsoft retirement updates, especially where onboarding rules or quota guidance may change before 2028.

Brief FAQ

Is October 23, 2026 the Email cutoff? No. The cited October 23 restrictions are about certain phone-number acquisition scenarios, not a blanket cutoff for ACS Email. Email retirement is scheduled for September 30, 2028.

Can I keep using ACS Email domains that are already verified? Microsoft says existing verified email domains are supported through the retirement period, but new-workload onboarding may change, and quota increases are considered case by case.

Is Microsoft 365 HVE a replacement for external customer email? No. HVE is for sending only within the tenant, so it does not replace a customer-facing transactional mail service.

Should I assume Graph avoids Exchange limits? No. Graph is not a loophole around mailbox and tenant limits. If your workload is external-facing or high-volume, check the applicable limits and the workload fit first.

Check your tenant’s actual external-recipient allowance in Exchange admin center, under Reports > Mail flow > Tenant Outbound External Recipients; shared tenant usage and peak sending rates matter as well as your app’s daily total. [Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits)

Choose a route per workload, then validate it with controlled tests. A mixed migration may be more suitable than forcing every sender onto the same service.

Sources

  • Microsoft ACS retirement and breaking changes guide, checked October 17, 2026: https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide
  • Microsoft High Volume Email guidance: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/high-volume-mails-m365
  • Microsoft send email from multifunction device or application guidance: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
  • Exchange Online limits and mail flow guidance: https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits

Conceptual editorial illustration for Azure Communication Services Email Is Retiring: Which Replacement Fits Your App?
Conceptual editorial illustration for Azure Communication Services Email Is Retiring: Which Replacement Fits Your App?