Security Related Updates in Exchange Online

It’s been a while since we gave an update on the work we’ve been doing in Exchange Online. Since our last post we’ve been busy on a number of fronts, and we strongly recommend you read about our Secure Future Initiative to get a better sense of what we’re doing to continue to earn and maintain your trust in our cloud.

This post has some important updates about recent changes and upcoming deprecations in Exchange Online; we recommend reading it carefully to ensure that you understand the changes that have been and are being made.

RBAC App Impersonation Blocking

As we recently repeated, we will begin blocking App Impersonation in Feb 2025. It’s very important that you make sure you don’t have any applications using this form of access, or they will stop working in February 2025. There are no exceptions.

Stay tuned to this blog for more details and check the Message Center for more information. We sent a message (MC724116) to all tenants that we believe are affected by this change. If you got that message, you must take steps to mitigate this change and avoid any interruptions of service. We also sent a different message to all other customers (MC718754 – except 21Vianet customers who received MC718746 in its place) so they are aware of this change.

Exchange Web Services Removal

We are still on track to remove Exchange Web Services (EWS) from Exchange Online starting October 2026. This will be a breaking change for all applications using EWS.

We are building reports to provide admins with visibility into their EWS usage, which we expect to ship early next year. These reports, which will show up in the Usage Reports section of the Microsoft 365 admin center, will allow you to see the volume and details of applications accessing your data via EWS.  We’ll have more news on this soon, as we know this is something many of you need.

In our original blog post, we said this change would affect only third-party (non-Microsoft) applications. We have expanded our effort and are now also removing EWS dependencies from our own apps and services, and we’re going to complete that work well before October 2026. We intend to do this as quickly as possible without affecting quality of service or product features. We take the removal of EWS seriously, and we need all developers/partners using EWS to do so, too.

In a previous blog, we called out a few known gaps, and now we can share updates on those:

• Access to Archive Mailboxes - We have not yet released this functionality in Graph, but we are working on providing support for this scenario and will provide an update when we have one.
• Folder Associated Information / User Configuration – We are working to soon release Application Settings for Exchange Client Applications in Microsoft Graph as defined in the folder associated information (FAI) section of the Exchange Server Protocol documentation.
• Exchange Online Management - After much investigation, we have concluded we are unable to provide Graph API access to several admin features that are available to developers via EWS. Once EWS is removed, to perform tasks such as setting folder permissions or managing delegates for a user, you will need to call PowerShell in code or use alternative ways to deliver this functionality.
• Access to Public Folders - After evaluating the usage of Public Folders, we have decided to restrict programmatic access to Public Folders to supported Outlook clients only, and for bulk Import/Export purposes. We will not provide APIs for programmatically creating, reading, updating and deleting Public Folders after Oct 2026.
• Import/Export APIs – We’ll have a separate update for this soon, so keep an eye out for that.

Application RBAC

As many of you know, app-only access has been evolved to support fine grained access, scoped to a set of users by our Application RBAC feature. We urge you to follow the principle of least privilege and consider migrating apps currently leveraging tenant-wide access to Application RBAC to ensure they can access only the data they need to operate.

This access can be configured using Exchange Online PowerShell and Microsoft Graph PowerShell. Management will also be available in Entra ID admin experience in the future.

Outlook Add-ins, Exchange Online Legacy Tokens, and Nested App Authentication

Outlook add-ins calling EWS or Exchange REST APIs are also affected by the EWS deprecation, so we strongly recommend moving your solutions to use Nested App Authentication (NAA) and Graph as soon as possible.

For additional context, Microsoft is transitioning Legacy Tokens into Entra ID tokens and NAA as part of Microsoft’s Secure Future Initiative with the goal of modernizing our application identity security and mitigate risks in the current threat landscape. NAA allows add-in developers to seamlessly authenticate and ease calling the Microsoft Graph, thereby enabling a consistent user experience.  Important dates:

• February 2025: Legacy Tokens will be turned off for all tenants with a temporary option for administrators to reenable them via PowerShell.
• June 2025: Legacy Tokens will be permanently shut down without the possibility of re-enablement.
• October 2025: Legacy Tokens turned off for all tenants. Marks the end of exception period.

We believe this phased approach strikes a balance between providing migration time for the add-in ecosystem to NAA plus Graph and moving the environment forward towards a more secure posture. 

For more information, including a detailed release timeline for NAA as well as tools to assist, please see https://aka.ms/NAAFAQ. Please also see the following blog post to help you search for impacted add-ins: Update on nested app authentication and deprecation of Exchange Online legacy tokens.

SMTP DANE with DNSSEC

Back in April 2020, Microsoft committed to add support for two email security standards: Domain Name System Security Extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE) for SMTP.

DNSSEC works by digitally signing records for DNS lookup using public key cryptography. This ensures that the DNS records being received have not been tampered with and are authentic.

DANE for SMTP provides a more secure method for email transport. DANE uses the presence of DNS TLSA resource records to securely signal TLS support to ensure sending servers can successfully authenticate legitimate receiving email servers. This makes the secure connection resistant to downgrade and adversary-in-the-middle attacks.

In February 2022, we released outbound SMTP DANE with DNSSEC. We also added TLS-RPT (RFC 8460) support for diagnostic reporting of TLS connectivity issues to help destination domain admins get fast insight into any errors their senders may encounter, allowing them to fix them before they hear about those errors from Exchange Online customers.

Last month, we completed our implementation of SMTP DANE with DNSSEC when we announced the general availability of inbound SMTP DANE with DNSSEC, and that it would automatically be included in enterprise and consumer email offerings at no charge, as part of our efforts to improve email security. Microsoft is looking forward to the impact that SMTP DANE with DNSSEC will have on the email security landscape and is deeply committed to delivering an email offering with industry-leading security such as SMTP DANE with DNSSEC.

You can learn more about the provisioning changes needed to adopt SMTP DANE with DNSSEC for your domains at Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow.

But we’re not done yet.  In May 2025, we expect to release Mandatory Outbound SMTP DANE, which an admin can set per-tenant and per-remote domain.

High Volume Email support for OAuth

High Volume Email (HVE) for Microsoft 365 is a feature, currently in Public Preview, that allows customers to send large volumes of email, primarily to internal recipients, without any recipient rate limits at GA (the public preview has a limit of 100,000 recipients per day per tenant).

HVE is designed primarily for line of business applications and other high-volume SMTP submissions. Customers using on-premises servers in an Exchange hybrid configuration to send a large volume of internal messages can use this service instead and decommission their on-premises servers.

HVE is a companion feature to Azure Communication Services (ACS) for email, which offers high-volume transactional, bulk, and marketing emails to external recipients.

As part of our efforts to improve email security, we recently added OAuth support to the public preview. The benefits of using OAuth include enhanced security and seamless integration with Microsoft 365. You can use application or delegated permission. Instructions for enabling OAuth for HVE are at OAuth authentication for high volume emails for Microsoft 365.

Summary of upcoming changes

To help you prioritize, here is a table overview of what is still coming and when you should start looking into it:

As we hope you’ll see from this collection of updates, we take security seriously, and in some cases, we’ve had to make some hard decisions to improve the security of the service. There’s a lot of work still to do, and we intend to provide more frequent updates as we have them.

Exchange Online team