Exchange Team Blog articles

Modernizing DNS Security for Exchange Online Mail Flow

The_Exchange_Team — Thu, 23 Apr 2026 21:00:39 GMT

The Domain Name System (DNS) protocol is used by clients to find mail servers over the internet. DNS is unencrypted and unauthenticated by default, making it vulnerable to spoofing, tampering, and adversary‑in‑the‑middle attacks. As threat actors increasingly target the foundational layers of email delivery, modern DNS security protocols have become essential to protecting organizations.

To address these gaps, Exchange Online has invested heavily in modern, standards‑based DNS security – including DNSSEC, SMTP DANE, and MTA‑STS – to ensure mail is delivered over validated, encrypted, and tamper‑resistant channels by default wherever possible.

In this post, we will provide updates on these efforts and discuss upcoming plans to keep raising the email security bar.

DNSSEC Enablement Wizard for Exchange Online

To simplify adoption of SMTP DANE with DNSSEC, in Q3 of calendar year 2026 we’re releasing a DNSSEC Enablement Wizard in the Exchange Admin Center. This guided workflow:

Validates DNS prerequisites
Provisions the customer-specific DNSSEC‑capable mail flow endpoint
Reduces configuration risk during MX transition
Prepares the domain for SMTP DANE adoption

For customers who wish to fully enforce SMTP DANE with DNSSEC, PowerShell will remain the option for enabling SMTP DANE once DNSSEC-enablement is complete as per Set up inbound SMTP DANE with DNSSEC.

Control Outbound SMTP DANE & MTA‑STS Validation on Connectors

With rollout started in late Feb 2026, we introduced a new capability that gives admins explicit control over SMTP DANE and MTA‑STS validation behavior for messages sent over outbound connectors.

The MtaStsMode and SmtpDaneMode parameters on New/Set/Get-OutboundConnector lets organizations choose how strictly Exchange Online enforces these security protocols on a per‑connector basis:

Opportunistic (default): Exchange Online attempts SMTP DANE and/or MTA‑STS validation but still delivers mail if the destination doesn’t support them.
None: which applies to both MTA-STS and SMTP DANE and disables the validation entirely, therefore reducing the security of emails sent over that connector by removing MTA-STS and/or SMTP DANE protections designed to prevent downgrade attacks and spoofed MX redirection.
Mandatory (SMTP DANE only): Enforces full SMTP DANE with DNSSEC validation and queues (then rejects) mail if validation fails or destination domain doesn’t support SMTP DANE with DNSSEC by end of queuing period.

This outbound connector capability makes it easier for customers to adopt stronger DNS‑based protections incrementally while maintaining compatibility with partner ecosystems.

What happened to auto-provisioning of DNSSEC-enabled mail flow records (A/AAA)?

Due to internal infrastructure projects, we had to delay this DNS provisioning change until second half of calendar year 2026. Gradually switching provisioning of all A records for new Accepted Domains into the new subdomains under mx.microsoft is still a priority for us, but making infrastructure changes is complex. Significant challenges have required us to re-order the work necessary to complete this change while maintaining service health and reliability.

Original announcement: Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow | Microsoft Community Hub.

Are there any planned updates to mail.protection.outlook.com?

Currently, there are no plans to enable DNSSEC on the mail flow domain mail.protection.outlook.com. Customers who require DNSSEC for inbound mail will continue to need to transition the DNSSEC-capable dedicated subdomains within mx.microsoft. As MX changes can be operationally sensitive, we built the DNSSEC Enablement Wizard to ease the friction of this change.

In early third quarter of 2026, mail.protection.outlook.com will receive TCP and EDNS support. This modernization improves reliability and enables future security enhancements at cloud scale.

Raising the Security Bar – Together

Across these investments, our goal is simple: make strong email security the default, without introducing additional operational complexity or overhead. DNSSEC, SMTP DANE, and MTA‑STS directly address long‑standing weaknesses in the global email ecosystem, and Exchange Online is committed to leading the industry in deploying these foundational protections at scale.

By modernizing our DNS infrastructure, providing safer tooling for domain transitions, and giving customers finer control over protocol enforcement, we’re continuing to raise the security bar for all Exchange Online customers—and making it easier than ever to adopt modern DNS security.

Microsoft 365 Messaging Team

Change Optics Report released into Public Preview to showcase messages impacted by future changes

The_Exchange_Team — Mon, 20 Apr 2026 16:03:10 GMT

Change Management is an important part of managing the improvements we make to our service that may sometimes disrupt our customers. The key is empowering customers to identify if they have messages that will be affected when we announce changes to the service. To that end, we’d like to announce the Public Preview for the Change Optics Report. It will be the central location for finding messages that could be affected by future changes to the service.

As we improve or identify issues in Exchange Online, there is now a report to point customers to when we announce changes that could affect the sending and delivery of certain messages. This report will showcase multiple scenarios of interest and importance to admins preparing for change. It displays a sample set of messages that have the characteristics that match those expected to be affected.

These example messages give admins the information necessary to launch investigations that highlight where actions are needed to avoid disruption to their organizations as changes arrive. The report can then be used to observe the progress made to reduce those messages to a point where the risk has been removed ahead of the related change.

Initial Scenarios

The report is being released with two scenarios already included.

OMC represents Onmicrosoft.com traffic being sent externally. This is aimed at customers from large organizations still seeing usage they need to address before the traffic is throttled. For more information, see Limiting Onmicrosoft Domain Usage for Sending Emails | Microsoft Community Hub.
DRS represents Direct Send traffic being received by an organization’s tenant. This is useful for customers looking to use the Reject Direct Send setting and needing to first ensure all legitimate traffic is identified and catered for. For more information, see Introducing more control over Direct Send in Exchange Online | Microsoft Community Hub.

Using the report

The report can be found in the Exchange Admin Center (https://admin.cloud.microsoft/exchange) under Reports > Mail flow > Change Optics Report

Change Optics Report: Use this report to view changes made to your Exchange Online configuration over time. You can filter by date range and change type to find specific changes.

The report is divided into a Summary page and Details page.

Summary Page

This provides a summary chart tracking the volume of messages flag by the various scenarios being tracked.

Details Page

The Details page allows you to see example messages per scenario. The main message properties are available for use in an investigation, and the table can be exported. Message Trace can be used to retrieve any additional information needed about a message.

The scenario you are interested in can be selected from the dropdown menu.

Please provide any feedback in the Comments section. We will update this blog to announce when the report reaches GA.

Microsoft 365 Messaging Team

Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program

The_Exchange_Team — Wed, 15 Apr 2026 14:35:11 GMT

While both Exchange 2016 and 2019 are out of support since October 2025, some of our customers who needed more time to finalize migrations to Exchange Subscription Edition (SE) have opted to enroll into the Extended Security Update program. That ESU program started in October 2025 and is ending in April 2026 (“Period 1”).

As end of April 2026 nears, some of our customers told us that they needed additional time to finalize their Exchange 2016/2019 migrations.

Today we are announcing that we created a “Period 2” Exchange Server ESU program. This period will last from the start of May 2026 through the end of October 2026 (6 months). There will be no further extensions of this program after that.

Conditions of Period 2 Exchange ESU program

Customers who wish to enroll into Period 2 program will have to re-purchase the Exchange ESU contract even if they were already enrolled into the Period 1 ESU program (October 2025 – April 2026). Period 2 is not an “extension” of current Period 1 Exchange ESU program (which ends in April 2026). Your organization does not automatically enroll into Period 2 – you will have to purchase the ESU again for additional 6-month coverage through October 2026 (in the same way that you purchased the original ESU).
In Period 2, we plan to provide security updates for Exchange Server 2016 CU23 and Exchange Server 2019 CU14/CU15.
Any Exchange Server ESUs purchased starting with today’s date (April 15, 2026) will automatically be considered Period 2 and will be valid from May to October 2026. Your organization will receive information on how to download updates released under Period 2 ESU (your original ESU program instructions will not work for ESU updates released after April 2026).

Starting today, customers can contact their Microsoft account team to get information about and purchase additional Period 2 Extended Security Update (ESU) for their Exchange 2016 CU23 or Exchange 2019 CU14/CU15 servers. Simply purchase the same product after today’s date. Your account teams will have information related to per server cost and additional details on how to purchase.

What does this mean?

This ESU is not an “extension of the support lifecycle” (Microsoft Lifecycle Policy | Microsoft Learn) for Exchange 2016 / 2019. Those servers are still out-of-support, and you will not be able to open support cases for them (unless directly related to an issue with an update released to ESU customers during the ESU period).
This Period 2 ESU is a way for customers who might not be able to finalize their Exchange 2016 or 2019 migrations to Exchange SE before the end of October 2026, to receive Critical and Important updates (as currently defined by Microsoft Security Response Center (MSRC) scoring) as security updates (SUs) that we might release during Period 2. If there are SUs that we need to release, we will privately provide such SUs to ESU customers only.
We are not committing to actually releasing any SUs during the Period 2 ESU. Exchange Server does not necessarily receive SU updates every month on Patch Tuesday (2^nd Tuesday of the month) as SUs are released only if there are Critical or Important security product changes. Therefore, if there are no SUs that we need to release during the time of ESU program, there will be no such updates provided. We will, however, confirm with ESU participants each Patch Tuesday whether an SU was provided or not.
This Period 2 Exchange ESU will be valid until end of October 2026.

Who is Period 2 Exchange ESU for?

This program is intended for customers with a Microsoft Enterprise Agreement (EA) who are unable to finalize their Exchange 2016 or 2019 migrations to Exchange SE before end of April 2026 and still need Critical and Important security coverage for servers still in operation.

FAQs

Why does Microsoft require additional contract for Period 2 of Exchange ESU if our organization already has the original Exchange Server ESU?
Period 2 is a separate contract that lasts until the end of October 2026. Many of our original ESU customers are finalizing their migrations by end of April 2026. Those few that need additional time have an option of getting a new ESU contract. Our preference is that our customers finalize their migrations instead (honestly – we’d be happy to not sell Period 2 Exchange ESU to anyone; please migrate instead!)

Our organization did not purchase original Period 1 Exchange ESU (ending with April 2026). Can we purchase Period 2 ESU only?
Period 2 ESU is separate from original Period 1 ESU and can be purchased independently. Purchasing the Period 2 ESU does not require purchase of Period 1. But note that purchase of Period 2 ESU will only get you update packages released after Period 2 starts. You will not get access to update packages released during Period 1 ESU. Seeing that all our updates are cumulative, fixes for issues released during Period 1 ESU will be included in Period 2 updates (when / if released).

How is Exchange Server ESU licensed and how are updates distributed?
Updates released under Period 2 Exchange ESU will follow the same process as updates released under the Period 1 ESU program: once enrolled, your organization will be provided information on how to access any updates released under Period 2. There will be no special licenses or keys in the Microsoft 365 admin center or Volume Licensing. After purchase of Period 2 SKUs, you will receive a new ESU User Guide which will contain everything you need.

Our Exchange server is getting throttled or blocked when sending email to Exchange Online. How can Microsoft not make ESU updates available to all customers, so they can address this?
If your server is currently affected by Throttling and blocking of persistently vulnerable Exchange servers that indicates that the version currently running in your organization is roughly a year out of date. To resolve the throttling or blocking immediately, please install October 2025 (last publicly available) updates for Exchange 2016 or 2019. ESU updates are not required. There will come a day when October 2025 updates too will be throttled or blocked, but that is not currently the case. But note that even if you update to October 2025 updates your server is still out of support and out of date and you should migrate to a supported version ASAP.

Our organization has Microsoft Volume Licensing. Do we get the Exchange ESU automatically? Where can we buy Exchange ESU?
Exchange ESU program is a separate contract that each organization must explicitly purchase via their Microsoft account team (requires Microsoft Enterprise Agreement). Exchange ESU is not automatically included in Volume Licensing or Software Assurance.

Help! We purchased the ESU (Period 1 or Period 2) – but we do not know how to access the updates we paid for!
If you have already purchased the ESU and need information on accessing the latest Security Updates, please contact us by sending an email to ExchangeandSfBServerESUInquiry@service.microsoft.com. You are welcome to add your account team to the email also.

Please continue migrating to Exchange SE instead of taking advantage of this Period 2 ESU program. But if you really must, contact your Microsoft account team for more details on Period 2 ESU.

A similar program extension is available for our Skype for Business 2015 / 2019 customers. Please read more here.

The Exchange Server Team

No Exchange Server Security Updates for April 2026

The_Exchange_Team — Tue, 14 Apr 2026 16:58:13 GMT

Although Exchange 2016 and 2019 are now out of support, some customers have purchased the Exchange 2016 and 2019 Extended Security Update (ESU). We have therefore decided that until the end of this Exchange 2016 and 2019 ESU period (April 2026) we will make an explicit update related announcement even if we DO NOT release anything for that particular month.

There are no security releases for any version of Exchange Server in April 2026, for customers with Exchange SE, or Exchange 2016 or 2019 ESU.

Please keep upgrading your organizations to Exchange SE.

The Exchange Team

High Volume Email reaches General Availability in Exchange Online

Nino_Bilic — Wed, 01 Apr 2026 13:25:49 GMT

As we discussed High Volume Email (HVE) several times since it was in Public Preview, I wanted to make you aware that Exchange Online HVE now reached General Availability (GA) in our multi-tenant (WW) service. The announcement was made on the Microsoft 365 Blog here:

High Volume Email Is Now Available in Exchange Online

Pricing is discussed in the announcement above.
HVE documentation can be found here.

Nino Bilic

Upcoming Breaking Changes to Modifying Sensitive Email Properties via Graph API

The_Exchange_Team — Tue, 24 Mar 2026 16:05:53 GMT

We are implementing a significant update in our service affecting applications that modify sensitive properties on non-draft email messages. These sensitive properties include the subject, body, recipients, and a number of other properties when changed using any of the message update methods on Graph API.

Immutability of Received Email Messages

There is a fundamental expectation that once an email message has been received, it should remain unchanged except for specific management-related properties such as read status, flags, and similar attributes. Critical components like the address list, subject, and body text should not be altered unless a new draft message is created. Exceptions to this rule are specialized use-cases, particularly within the security domain, such as identifying suspicious emails and other privileged operations.

Required Permissions for Modifying Sensitive Properties

To maintain the expected immutability of email messages during standard management operations, we will begin restricting applications from modifying sensitive message properties in non-draft messages unless they possess elevated permissions. Specifically, applications must have one of the following permissions: Mail-Advanced.ReadWrite, Mail-Advanced.ReadWrite.All, or Mail-Advanced.ReadWrite.Shared, depending on the scenario. All these permissions require a tenant administrator consent.

The documentation page identifies sensitive properties as those that are only updateable if isDraft = true. Once the restriction goes into effect, these properties can only be updated in non-draft messages if the application has Mail-Advanced.ReadWrite permissions. Draft messages will continue to be updateable with the current Mail.ReadWrite permissions.

Timeline and Recommendations

These required permissions are already available. Enforcement of the new restrictions in our service – blocking Graph API updates to sensitive email properties – will begin on 12/31/2026. If you develop Graph API applications that modify these properties, we strongly recommend updating your applications to request the necessary higher-level permissions as soon as possible. This proactive approach will help ensure a smooth transition and minimize potential disruptions for your customers.

The Exchange Team

Celebrating 30 Years of Microsoft Exchange

The_Exchange_Team — Mon, 23 Mar 2026 17:00:06 GMT

It’s hard to believe, but Exchange Server is now 30 years old! A lot has changed since the first release of Exchange Server 4.0 in 1996: protocols, platforms, scale, and even what “email” means in the modern workplace.

To commemorate this milestone anniversary, we want to pause and reflect on how Exchange has shaped enterprise email as we know it today.

The start: email becomes enterprise messaging

Back in the mid-1990s, messaging solutions were fragmented, proprietary, and difficult to manage at scale. Businesses looking for a messaging system basically had two choices: host-based systems that were costly and didn’t integrate well with PC-based applications or LAN-based systems that did integrate with PC-based applications but were less scalable and reliable (although there were several companies that made software that allowed different email systems to communicate).

That changed when, after nearly four years of development, Microsoft Exchange Server 4.0 – “the e-mail server with integrated groupware that makes it easy to communicate” – was released on April 2, 1996. Or, it might have been March 1996. Or maybe June 1996. No one knows for sure because the first public build that was shipped was not the build on the gold master (the signed-off RTM version).

Nonetheless, Exchange Server had ambitions! From the start, it combined email and calendaring as well as an integrated centralized directory. Admin controls and native support of Internet standards like SMTP (via Internet Mail Connector) and X.400 kept it “modern.”

In addition to user productivity through email, Exchange provided admin controls for monitoring, managing, and troubleshooting messaging across an entire organization from a single system – an idea that now seems obvious, but was far from standard in 1996.

Exchange shapes the market

As Exchange evolved through the late 1990s and early 2000s, it kept raising the bar for business email. It was during this time that several major changes occurred:

Email and user identity became inseparable. This directly influenced the development of Active Directory (Active Directory was the direct descendant of the Exchange Directory Service).
Calendaring and scheduling were first-class workflows and not bolt-on experiences.
Reliability, scale, and disaster recovery became built-in
Administrators came to expect the ability to automate admin tasks.

Exchange Server became one of Microsoft’s first truly successful enterprise server products, helping establish us as a serious enterprise platform provider beyond the desktop.

The foundation of Exchange Online

When we set out to build Exchange Online (remember Exchange Labs?), the goal was to operate enterprise email as a global service.

Exchange Online inherited many years of lessons from Exchange Server as it extended to the service. That continuity of experience is one reason our customers were able to move from Exchange Server to Exchange Online more confidently as they worked with already familiar tools. Concepts such as mailboxes, the transport pipeline, policy enforcement, and compliance remained familiar, even as the operational model changed. Exchange quite literally became the backbone of Microsoft 365’s compute, routing, and storage (also known as the Substrate).

Exchange Server still matters in 2026

Three decades later, Exchange Server still matters. Conversations around digital sovereignty, regulatory compliance, and admin control continue. Many organizations like governments, regulated industries, and critical infrastructure providers must make choices about where their data is stored and who operates the infrastructure.

For customers that need it, Exchange Server remains valuable as an architectural choice. Continued investment in Exchange Server, including release of Exchange Subscription Edition (SE) which we are committed to supporting until at least the end of 2035 reflect the reality that enterprise messaging is not one-size-fits-all.

Cloud-first (where innovation is the fastest) does not need to mean cloud-only. Whether you want to run on-prem, hybrid, or cloud, Exchange is there for you.

Through it all, community helped shape Exchange

While this is a bit intangible, we want to acknowledge that feedback from Exchange admins, MVPs, partners, and customers influenced (and keep influencing) Exchange in real ways. Feedback via our blog (since the first post, back in 2004), support cases, and feedback given through conferences or Feedback portal over the years really matter. Some design changes happened specifically because the community spoke clearly. Our teams staying involved (via, for example, this blog) has been extremely valuable to us. Please keep giving us feedback!

How things are changing

Exchange backward compatibility was both a gift and a burden. For many years, we allowed customers to have coexistence of 3 major Exchange versions within the same organization. This helped reduce migration pain. But it also slowed down architectural cleanup and modernization as every version had to play nice with choices made years earlier. We are looking forward to the future in which we support only a single major version inside an organization – Exchange Subscription Edition (SE) – a requirement we are adding starting with Exchange SE CU2!

Security came into focus over the years. It is still in focus. Early Exchange was built for connectivity and collaboration. The threat model changed, with threat actors going after organizational email. It is more important than ever to stay up to date. We realize that some upcoming security changes mean that admins need to do additional work (for example upcoming hybrid security improvements), but the result will be your organization’s improved security posture.

With all the modes of communication that have become popular in business environments over the last 3 decades, the “end of email” has been predicted many times. Yet, email is still alive. And judging by our inboxes, it’s thriving!

We want to thank the admins, MVPs, partners, and customers who keep Exchange running and who’ve provided unfiltered feedback along the way. We are excited to continue this journey with you!

Here are a few fun Exchange historical posts that you might have missed over the years:

And a few technology-specific fun posts related to Exchange history:

From crush to product documentation: The story of Squeaky Lobster
Me Too!
Why is OOF an OOF and not an OOO?
The saga of the M: drive
The BillG bit in AD
The Autodiscover Song
How the Exchange 2007 icon was made
The excitement of dogfooding Exchange at home
The secret decoder ring
The other secret decoder ring
The 2.4 GB message successfully delivered by Exchange Server 2003
The Exchange Team answering the citation call from Wikipedia
Ask Perry/Geek Out with Perry
Investigating replacing ESE with SQL

The Exchange Team

Give Us Feedback on Faster, Simpler Data Purging for Exchange Online

Nino_Bilic — Thu, 19 Mar 2026 19:32:01 GMT

Priority Cleanup (Use priority cleanup to expedite the permanent deletion of sensitive information from mailboxes | Microsoft Learn) was introduced to provide administrators with a powerful tool for permanently deleting mailbox content, even when under retention or eDiscovery hold, to address scenarios such as data spillage and urgent removals.

Purview team is working on Priority Cleanup V2 which would bring improvements to deletion speed, approval workflow as well as improvements in admin experience and control. The team is looking for feedback.

If you use Priority Cleanup today and would like to see what is coming in Priority Cleanup V2 and provide feedback - please head over to Microsoft Purview Blog:

Priority Cleanup V2: Faster, Simpler Data Purging for Exchange Online | Microsoft Community Hub

Nino Bilic

AI‑Powered Troubleshooting for Microsoft Purview Data Lifecycle Management now available

Nino_Bilic — Mon, 16 Mar 2026 19:07:00 GMT

A really interesting post is now live on the Microsoft Purview Blog, describing a open‑source release of the DLM Diagnostics Model Context Protocol (MCP) Server – an AI‑powered diagnostic server that allows AI assistants to safely investigate Microsoft Purview DLM issues using read‑only PowerShell diagnostics.

Microsoft Purview Data Lifecycle Management (DLM) policies are critical for meeting compliance and governance requirements across Microsoft 365 workloads. However, when something goes wrong – such as retention policies not applying, archive mailboxes not expanding, or inactive mailboxes not getting purged – diagnosing the issue can be challenging and time‑consuming.

That is where this tool comes in!

If this sounds interesting, check it out here:

AI‑Powered Troubleshooting for Microsoft Purview Data Lifecycle Management | Microsoft Community Hub

Nino Bilic

Announcing SMTP DANE & MTA STS Connector Modes in Exchange Online

The_Exchange_Team — Tue, 10 Mar 2026 20:19:01 GMT

We’re excited to announce the release of SMTP DANE and MTA‑STS connector modes in Exchange Online. This update gives administrators explicit control over how strictly Exchange Online enforces modern mail flow security standards when sending email over outbound connectors.

This capability builds on our offerings for SMTP DANE with DNSSEC and MTA‑STS and addresses customer feedback around balancing security posture, reliability, and partner interoperability on critical mail paths.

What’s new

Exchange Online outbound connectors now support configurable SMTP DANE and MTA‑STS modes, allowing customers to choose the validation behavior that best fits each mail flow scenario.

Admins can now configure:

Opportunistic (default): Exchange Online attempts SMTP DANE and MTA‑STS validation when available but continues delivery if the destination does not support them.
Mandatory (SMTP DANE only): Enforces full SMTP DANE with DNSSEC validation. Mail is queued if validation fails or the destination does not support SMTP DANE.
None: Disables SMTP DANE and/or MTA‑STS validation for the connector, reducing security in favor of compatibility for specific partner scenarios.

These settings apply per connector, enabling granular control without impacting the tenant’s broader outbound mail flow behavior.

Why this matters

SMTP DANE with DNSSEC and MTA‑STS significantly raise the bar for transport‑level email security by protecting against downgrade attacks and malicious MX redirection. However, customers have told us that one‑size‑fits‑all enforcement can be challenging when sending mail to partners with inconsistent or misconfigured implementations.

Connector‑level modes allow customers to:

Enforce strict security where partners are fully compliant
Maintain reliable delivery for business‑critical partners still modernizing
Gradually increase security posture over time, without operational disruption

Learn More

Documentation updates and admin guidance are available in Microsoft Learn: Set-OutboundConnector (ExchangePowerShell) | Microsoft Learn

We’re excited to see customers adopt these controls as part of their broader email security journey.

Microsoft 365 Messaging Team

No Exchange Server Security Updates for March 2026

The_Exchange_Team — Tue, 10 Mar 2026 18:12:38 GMT

There are no security releases for any version of Exchange Server in March 2026, for customers with Exchange SE, or Exchange 2016 or 2019 ESU.

Please keep upgrading your organizations to Exchange SE.

The Exchange Team

Notes From the Field: Finding and Remediating EWS App Usage Before Retirement

The_Exchange_Team — Thu, 26 Feb 2026 21:09:52 GMT

In this post, we wanted to share a practical walk-through of discovering which Azure AD app registrations are still using Exchange Web Services (EWS), plus what the Kiosk/Frontline license changes mean as you plan your move to Microsoft Graph.

Microsoft has announced that Exchange Online EWS blocking with start on October 1, 2026. If you have line-of-business apps, third-party tools, or automation that still depends on EWS, you need two things: (1) an inventory of what’s using EWS today, and (2) a migration plan to supported alternatives – typically Microsoft Graph.

What’s changing (and why you should care now)

EWS retirement in Exchange Online: Microsoft will start blocking EWS requests to Exchange Online on October 1, 2026. The guidance is to migrate integrations to Microsoft Graph.
EWS access changes for Kiosk / Frontline licenses: Starting at the end of June 2026, Microsoft will start blocking EWS access for users without license rights to EWS (for example, certain Kiosk and Frontline Worker license types). This can cause EWS-based integrations for such licensed users to fail before the broader October retirement date.

Even if you plan to complete your Graph migration well ahead of October 2026, the end-of-June 2026 licensing-related blocks mean you should validate whether any users with those licenses assigned use EWS. That’s where the Exchange-App-Usage-Reporting script is useful: it helps you find app registrations with EWS permissions and correlate them with recent sign-in activity so you can prioritize remediation.

Start here: check your Message Center first

The first thing you can do is to check your tenant Message Center (you need either Global Admin or Privacy Reader roles) and search for "Update active Exchange Web Services Applications" in Inbox or Archive. If you do not have such messages, you likely do not have EWS usage in your tenant and are not impacted by this deprecation. We started to send EWS usage messages to all tenants in late December 2025.

What the Exchange-App-Usage-Reporting script does

The script is designed to answer a practical question: Which Azure AD app registrations in my tenant have EWS permissions, and are they still being used? At a high level, it:

Discovers application registrations that have permissions associated with Exchange/EWS-related access.
Queries sign-in activity for those applications to determine active applications.
Queries audit logs for EWS activity within the tenant.
Outputs report files that you can sort and share with app owners.
Outputs a user license report to help identify kiosk or frontline workers.

How the script complements the Microsoft 365 admin center EWS usage report

For customers in our WW service, the Microsoft 365 admin center EWS usage report is a great starting point because it summarizes EWS activity across your tenant and breaks down which EWS SOAP actions are being called and their volumes over time. That helps you quantify overall EWS dependency and spot the heaviest EWS workloads.

Where teams often get stuck is turning that usage signal into an actionable remediation plan (for example, identifying the exact Entra ID app registration/service principal, determining whether it is still actively used, and finding the people and mailboxes affected). Exchange-App-Usage-Reporting script is intended to bridge that gap by adding identity and operational context around EWS usage by:

App registration and ownership context: identifies Entra ID app registrations/service principals with EWS-related permissions so you can immediately pivot from “an app is calling EWS” to “this is the app object to remediate,” then route it to the right owner/team.
Recency and “is it still used?” signals: correlates apps to sign-in activity so you can prioritize the apps that are actively authenticating today versus stale registrations that may be safe to validate/decommission.
Authentication + permission model visibility: helps you distinguish whether usage is tied to application permissions versus delegated patterns, which matters for choosing the right Microsoft Graph migration approach and designing least-privilege access.
Mailbox population risk (Kiosk/Frontline): adds a user license report so you can quickly identify whether the EWS-dependent workflow touches mailboxes that may lose EWS access earlier (end of June 2026).
Exportable, app-centric worklists: produces CSVs you can sort/share (for example, by last sign-in) to drive an engineering backlog: confirm owner, confirm scenario, map EWS operations to Graph endpoints, and track progress to zero.

In practice, use the admin center report to understand what EWS operations are happening and at what scale, then use this script to determine which app registrations are responsible, who owns them, whether they’re still active, and which mailbox/license populations are most likely to experience impact first.

Customers with tenants that are not in our WW cloud should rely heavily on the script as admin center reports are not available.

Step-by-step: run the script and generate the report

1) Download the code

The repository for this solution can be found here

Note: The following permissions are required for the application:

AuditLogsQuery.ReadAll to query the audit logs for EWS activity
Application.Read.All to locate app registrations
AuditLogs.Read.All to query sign-in activity
Directory.Read.All to query user license information

To add those permissions, please see the Create app registration readme file.

2) Get active applications

Open a PowerShell session and change to the folder where you downloaded the script. You may need to unblock the files (for example, by using Unblock-File) before execution. Run the script with the following example syntax:

.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetEwsActivity

The output provides a list of applications with EWS permissions and the last sign-in for the associated service principal. A CSV file called App-SignInActivity-yyyyMMddhhmm will be created in the specified output path.

3) Get sign-in activity report for an application

Use the output from the previous step to get the sign-in activity for an application (you need to run this step for each application). Depending on the size of your tenant, you may also need to adjust the StartDate, EndDate, and have the Interval be 1 hour.

.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d  -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetAppUsage -QueryType SignInLogs -Name TJM-EWS-SoftDelete-Script -AppId 86277a5c-d649-46fc-8bf6-48e2a684624b -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date).AddDays(-14) -Interval 8

The output provides a list of users that have signed into the application in the specified period requested. A CSV file called <AppId>-SignInEvents-yyyyMMddhhmm will be created in the specified output path.

4) Get user license information (Kiosk and Frontline identification)

For those organizations that have users with licenses that may be impacted by the upcoming enforcement in June, a report of user licenses can also be generated to help identify potential impact. The output from the previous step can be used to generate this license report. A single CSV file with the results from each application can also be merged into a single user license report.

.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d  -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetUserLicenses -AppUsageSignInCsv C:\Temp\Output\86277a5c-d649-46fc-8bf6-48e2a684624b-SignInEvents-20260203122538.csv

How to interpret the output (and prioritize fixes)

Once you have the output files, sort by “last sign-in”. Apps with recent activity are your highest priority because they’re more likely to break production workloads when EWS is blocked. Apps with no sign-in data may be dormant, misconfigured, or retired—treat these as “needs validation,” not automatically “safe to ignore.”

Identify the owner of each app registration (or the business system it belongs to).
Confirm the workload: mailbox access patterns (read, send, calendar, contacts, etc.) and whether it uses application or delegated access.
Check mailbox populations the app touches—especially if any are assigned Kiosk / Frontline licenses that may lose EWS access at the end of June 2026.
Choose the migration target: Microsoft Graph API equivalents, supported Exchange Online features, or a vendor upgrade that removes EWS dependency.

Don’t miss the Kiosk / Frontline Worker EWS blocks (end of June 2026)

Recommended validation playbook:

Use the script output to build a shortlist of actively used EWS-enabled apps.
For each app, determine which mailboxes it accesses (application access policies, RBAC, service accounts, shared mailboxes, or user populations).
Cross-check those mailboxes’ license assignments for Kiosk / Frontline SKUs that may not include EWS rights.
Run a controlled test (non-production where possible) to confirm whether the integration depends on EWS for those mailboxes and whether the vendor has a Graph-based update available.
Evaluate if adding a different type of license for specific users is needed (for example, adding an Exchange Online Plan 1 or 2, which can still use EWS until October deprecation.)

Remediation options (what to do when you find an EWS dependency)

Upgrade or reconfigure the product: Many vendors have already moved to Microsoft Graph. Engage the vendor and request their Graph migration guidance and timelines.
Refactor custom code: Map EWS operations (mail, calendar, contacts) to Microsoft Graph endpoints and re-test auth flows, throttling, and permissions. More information on mappings can be found here.
Reduce blast radius: If an app truly must remain temporarily, scope it tightly using least-privilege permissions and (where applicable) scope the mailbox it has access to using RBAC—then treat it as a short-term exception with an expiration date.

Quick checklist

Run Exchange-App-Usage-Reporting and identify apps with recent EWS sign-in activity.
Track down app owners and document which mailboxes/workloads each app touches.
Assess exposure to the end-of-June 2026 licensing-related EWS blocks (Kiosk/Frontline).
Prioritize migrations to Microsoft Graph and validate functionality end-to-end.
Re-run the report periodically to confirm EWS usage is trending to zero.

Major updates to this post:

2/26/2026: Linked to a better version of the Create app registration readme file
2/25/2026: Added details about app registration for the reporting script and information on how to search your tenant Message Center posts for EWS usage.

Jim Martin (Exchange)

Multi-Geo In-Region Routing General Availability

The_Exchange_Team — Fri, 13 Feb 2026 17:24:15 GMT

We’re excited to share that Multi-Geo In-Region Routing reached General Availability in December 2025. This new capability extends the value of Microsoft 365 Multi-Geo Capabilities add-on ("Multi-Geo") by giving admins of Multi-Geo customers with globally distributed users the ability to configure controls over where a tenant’s inbound anonymous and hybrid email enters Exchange Online.

Why In-Region Routing?

By default, all inbound anonymous and hybrid email to a Microsoft 365 tenant with Multi-Geo enters Exchange Online in the tenant’s region first and then is relayed within Microsoft’s secure internal network to the email recipient. For customers with users distributed globally, this model may not fully meet their business needs.

Multi-Geo In-Region Routing was built to help address this challenge.

What does Multi-Geo In-Region Routing offer?

With In-Region Routing, customers can control the geographic location where inbound email enters Exchange Online for:

Anonymous inbound mail
Hybrid inbound mail from on premises

Multi-Geo In-Region Routing helps ensure that anonymous inbound email and hybrid inbound email enters Exchange Online in the same geography as the recipient user – provided the tenant is properly configured.

How it works (at a high level)

In-Region Routing allows customers to:

Associate Accepted Domains with specific geo‑regions
Align those domains with users located in the same regions
Ensure inbound and hybrid email for those domains enters Exchange Online in the recipient’s region

A natural extension of Multi‑Geo

In-Region Routing is an included feature in Multi-Geo and builds on existing Multi-Geo Capabilities. When configured properly, inbound email for an In-Region Routing domain will no longer enter Exchange Online in the tenant’s Primary Provisioned Geography region first but instead enter directly in the recipient’s region. It’s another step toward giving customers meaningful, transparent controls over how Microsoft 365 operates in global environments.

Get started

If you’re already using or planning to use Multi-Geo, now is a great time to review your domain and user alignment and then consider whether In-Region Routing can help meet your regulatory or organizational requirements.

Learn more: Configure Multi-Geo In-Region Routing - Microsoft 365 Enterprise | Microsoft Learn

Microsoft 365 Messaging Team

Deprecation of the -Credential Parameter in Exchange Online PowerShell

The_Exchange_Team — Wed, 18 Mar 2026 16:39:40 GMT

As part of our continued commitment to strengthening security across Exchange Online, we want to inform our customers about an important change coming to the Exchange Online PowerShell module.

What’s changing and why

Microsoft is progressively moving all services toward more secure, modern authentication experiences. As part of this shift, multi-factor authentication (MFA) is being made a mandatory security requirement across Microsoft cloud services. Because the legacy Resource Owner Password Credentials (ROPC) authentication flow does not support MFA, it is on the path toward deprecation as Microsoft strengthens its security baselines. Additionally, the Microsoft Authentication Library (MSAL) that supports authentication across Microsoft services has deprecated ROPC starting with version 4.74.0.

The -Credential parameter in Exchange Online PowerShell relies on ROPC, and therefore cannot meet MFA or Conditional Access requirements. To align with MFA enforcement, modern authentication principles, and Microsoft’s broader security standards, support for the -Credential parameter will be removed from new Exchange Online PowerShell versions released after June 2026.

This change is applicable to both Connect-ExchangeOnline and Connect-IppsSession.

While our published timeline extends to June 2026, we strongly recommend that all customers transition away from the -Credential parameter as soon as possible and not wait until the deadline.

Alternatives for the -Credential parameter

Below is a list of supported alternatives for the -Credential parameter that you should adopt depending on their scenario:

Scenario / Use Case	Recommended Authentication Method	Description	Documentation
Admins connecting interactively	Interactive Sign‑In (Modern Auth + MFA)	Secure sign-in for human administrators; supports MFA and Conditional Access.	Connect to Exchange Online PowerShell \| Microsoft Learn
Automation running outside Azure	App‑Only Authentication	Certificate‑based app registration for non‑interactive automation.	App-only authentication in Exchange Online PowerShell and Security & Compliance PowerShell \| Microsoft Learn
Automation running in Azure services	Managed Identity Authentication	Ideal for Functions, Automation Accounts, and cloud-native tasks. Eliminates secrets entirely.	Use Azure managed identities to connect to Exchange Online PowerShell \| Microsoft Learn

Timeline

Current state: the -Credential parameter continues to function today and will continue to function in all modules released till end of June 2026.
Recommended action (effective immediately): you should begin migrating away from the -Credential parameter use while connecting to Exchange Online using the Connect-ExchangeOnline or Connect-IppsSession cmdlets
After June 2026: new versions of the Exchange Online PowerShell modules released post 2026 will no longer include support for the -Credential parameter.

If you encounter any gaps or unsupported scenarios with the alternative authentication flows, please share them in the Comments section so we can prioritize addressing them in future updates.

Major changes to this post:

3/18/2026: Removed the reference to "secret-based" registration for app-only authentication because it is not a recommended path.
2/17/2026: Added a note that this change applies to both Connect-ExchangeOnline and Connect-IppsSession.

Exchange Online Management Team

Released: February 2026 Exchange Server Security Updates

The_Exchange_Team — Fri, 13 Feb 2026 15:00:32 GMT

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

Exchange Server Subscription Edition (SE)
Exchange Server 2019
Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

Exchange SE RTM
Exchange Server 2019 CU14 and CU15 (to access, you must be enrolled into the ESU program)
Exchange Server 2016 CU23 (to access, you must be enrolled into the ESU program)

The February 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to immediately install these updates to protect your environment.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed by these SUs and do not need to take any action other than updating any Exchange servers or Exchange Management tools workstations in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on ‘Server Software’ under Product Family for Exchange SE and ‘ESU’ under Product Family for Exchange 2016 and 2019).

Exchange 2016 and 2019 updates are available only under the ESU program

Exchange Server 2016 and 2019 are out of support.

Customers who enrolled in the Extended Security Update (ESU) program are eligible to receive the February 2026 security updates for Exchange Server 2016 and 2019.

If you are not part of the ESU program, migrate to Exchange Server Subscription Edition (SE) to keep receiving the latest security updates.

If you have already purchased the ESU and need information on accessing the latest Security Updates, please contact us by sending an email to ExchangeandSfBServerESUInquiry@service.microsoft.com.

Update installation

The following update paths are available:

Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
Re-run the Health Checker after you install an update to see if any further actions are needed.
After setup is completed, please reboot the server and check that all Exchange services have started properly. If some services are in a disabled state, that indicates that something interrupted installation of the update. Please see the Workaround 1 in this article.
If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates. Also please see File version error when you try to install Exchange Server updates.

FAQs

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but this SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing an SU, you should re-run the Hybrid Configuration Wizard.

The last SU/HU we installed is a few months old. Do we need to install all SUs in order to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs or HUs in sequential order; simply install the latest SU. Please see this blog post for more information.

Do we need to install SUs on all Exchange Servers within our organization? What about ‘Management Tools only’ machines?
Our recommendation is to install SUs on all Exchange Servers and all servers and workstations running the Exchange Management Tools to ensure compatibility between management tools clients and servers. If you are trying to update the Exchange Management Tools in the environment with no running Exchange servers, please see this.

Our organization does not have the Exchange 2016 and 2019 ESU. How can we get current Exchange 2016 or 2019 updates?
Since Exchange 2016 and 2019 are now out of support, only customers who have enrolled into the ESU program (which is valid until April 2026) can obtain Exchange 2016 or 2019 updates released under the ESU. For all customers still running Exchange 2016 or 2019, we recommend that you upgrade your organization to Exchange SE as soon as possible.

Documentation may not be fully available at the time this post is published.

This post might receive future updates; they will be listed here (if available).

The Exchange Server Team

Exchange Online EWS, Your Time is Almost Up

The_Exchange_Team — Tue, 17 Mar 2026 15:04:01 GMT

Exchange Web Services (EWS) is approaching end of service in Exchange Online. We first announced this change was coming in 2018, when we announced that Exchange Web Services (EWS) will no longer receive functionality updates. In 2023, we announced that EWS will be disabled in Exchange Online in October 2026.

Today we’re announcing we will use a phased, admin controllable disablement plan that starts in October 2026 and concludes with a complete shutdown of EWS in 2027. This post explains what’s happening, when, and what administrators should be doing now.

Today’s announcement and the retirement of EWS apply only to Microsoft 365 and Exchange Online (all environments); there are no changes to EWS in Exchange Server.

Why is EWS being retired?

EWS was built nearly 20 years ago, and while it served the ecosystem well, it no longer aligns with today’s security, scale, or reliability requirements. Over the past several years:

Microsoft Graph has reached near‑complete feature parity for the vast majority of EWS scenarios.
Microsoft’s own applications have either migrated from EWS or are nearing completion.
Many third-party vendors have already transitioned or are actively doing so.

Retiring EWS lets us reduce legacy surface area, simplify platform behavior, and deliver a more consistent, modern experience for everyone.

How will EWS be disabled?

We’ll disable EWS tenant-by-tenant using the EWSEnabled property, which supports three values: True, False, and Null (the default today). A new feature arriving in early 2026 will allow admins to define an AppID Allow List. When enabled, only apps on that list can access EWS.

The EWSEnabled property in your tenant will change on (or soon after) Oct 1, 2026, as follows:

EWSEnabled value	Before Oct 2026	Starting Oct 2026
True	All EWS Allowed	Only Apps in the Allow List Allowed
False	All EWS Blocked	All EWS Blocked
Null	All EWS Allowed	All EWS Allowed (allow list ignored)

Any tenant with EWSEnabled still set to Null on October 1, 2026, will see the value changed to False as the deployment rolls out. That will block EWS for all applications in the tenant at that time.

If you want to keep EWS blocked, you can simply leave it that way.

But if you still need to use EWS, you will have two choices:

Set EWSEnabled to True and maintain an Allow List (via Baseline Security Mode or Exchange Online PowerShell).
Set EWSEnabled back to Null, which re-enables EWS without restrictions until the final deprecation occurs. This will have to be done using Exchange Online PowerShell.

Additionally, if you proactively configure an Allow List and set EWSEnabled to True by the end of August 2026, your tenant will be excluded from the October 1 automatic change to EWSEnabled=False.

To help you during this transition, we will pre-populate the Allow List for customers who have not created one before September 2026, based on each tenants own usage. If in October 2026 you realize that you still need EWS, the admin can re-enable EWS (by setting EWSEnabled to True) after we block it. But note that there will be a service interruption in this case.

Key dates

Preparation (starting now)

During this phase, EWS remains available, but admins are encouraged to prepare:

Review EWS usage reports in the Microsoft 365 admin center, and consider the published scripts if you need more information. See
Notes From the Field: Finding and Remediating EWS App Usage Before Retirement.
Optional: by end of August 2026, populate your Allow List and set EWSEnabled=True
Begin migrating applications to Microsoft Graph.

Initial blocking for tenants who still use EWS – starting October 1, 2026

EWS will be disabled by default (EWSEnabled=False) in Exchange Online tenants that have not explicitly chosen to keep it enabled with an Allow List and setting EWSEnabled to True in August 2026. At this point:

EWS calls will be blocked unless the tenant has already taken admin action.
Admins can temporarily enable EWS if critical workflows are affected (EWSEnabled=True)

Final EWS shutdown – April 1, 2027

Starting with April 1, 2027, EWS will be fully and permanently disabled:

The ability to control EWSEnabled will be removed from tenant admins.

Here is a graphical representation of timelines:

Ongoing communication and monitoring

To keep admins informed and avoid surprises we will send monthly Message Center posts to provide tenant specific EWS usage summaries and reminders.

We may perform temporary “scream tests” (shorter periods of time when we turn EWS off and then back on) which can help expose hidden dependencies before the final cutoff. We will provide more information in the coming weeks. If your organization sets EWSEnabled = True now, you will not be impacted by any "scream tests" that we might conduct.

The bottom line

Now is the right time to evaluate your environment, talk with application owners, and plan your move to Microsoft Graph. Early action avoids last‑minute surprises and gives you the smoothest possible transition path.

FAQs

We already configured EWS blocking using the EWSApplicationAccessPolicy settings – how will this new Allow List and the list we have work together?
The new AppID Allow List takes precedence. An app will have to pass both checks to gain access.

We have all kinds of apps still using EWS. We have no idea how much work it’s going to take to migrate them – help!
Start with the usage tools we’ve published (WW tenants see this and government and sovereign clouds see this). Most apps use only a handful of EWS actions, and with modern tooling (including AI-assisted migrations), many can be converted more easily than expected.

There are parity gaps in the Graph API. How can we possibly migrate to Graph from EWS?
We actively track and publish the remaining gaps. Most EWS-based workloads can migrate now. The best place to see the current status of the remaining parity gaps is here: Deprecation of Exchange Web Services in Exchange Online | Microsoft Learn. We keep this up to date and link to more information as it becomes available.

What about on-prem Exchange, and hybrid scenarios?
EWS is not being retired on-prem. Hybrid scenarios vary depending on how apps access data. On-prem mailboxes may continue using EWS; cloud mailboxes must move to Graph. Autodiscover will help apps determine mailbox location automatically. But note that only Exchange SE will support Graph for calls to Exchange Online, so hybrid customers will have to use Exchange SE to host on-premises mailboxes. Read more here.

We will not be ready by April 2027. How do we get an extension?
There will be no exceptions past April 2027.

Can we set EWSEnabled=True in August without creating our own Allow List?
Yes, but we’d rather your tenant admin creates it, to ensure it’s exactly meeting your needs. In September 2026, we will be populating Allow Lists for our customers automatically (based on each tenant’s usage). If you only set EWSEnabled=True in August and we will populate your Allow List for you, we might also include apps in there you weren’t aware of (if they show usage). We recommend that admins create their own Allow Lists to control exactly which EWS applications they want to allow after October 2026.

If we create our own Allow List before August 2026, will Microsoft change it in September 2026 during automatic Allow List processing for all tenants?
No. If you create your own Allow List, our automated process will not change your already created Allow Lists. Your Allow List will stay unchanged.

Changes to this post:

3/17/2026: Added a link to Notes From the Field: Finding and Remediating EWS App Usage Before Retirement.
2/9/2026: Added a note that setting EWSEnabled = True starting now would exclude the organization from any future "scream tests"

The Exchange Team

Streamlined Moderation Approvals, Now in All Outlook Clients

The_Exchange_Team — Tue, 24 Feb 2026 15:53:35 GMT

Introduction

Email Moderation in Exchange Online ensures messages that need human review don’t slip through. Today’s workflow, however, can be constraining and confusing: To approve or reject messages moderators must use Outlook clients that support voting buttons (not all of them do, e.g. Outlook Mobile), and they may receive multiple approval requests when a message is split or forked.

To address these concerns, we're pleased to announce we're now rolling out support for two updates: moderation approval across all Outlook clients, and approval message consolidation. With these updates moderators will experience greater moderation approval flexibility and can act faster, with less noise.

What’s new

Approve or reject from any Outlook client

For moderation approval messages, we’re moving from using Outlook's voting buttons feature to Actionable Messages adaptive cards, which put the Approve | Reject buttons directly in the message body. Unlike voting buttons, Actionable Messages adaptive cards work across all Outlook clients – Windows, Mac, web, and mobile – so moderators can now approve or reject from whichever client and device works best for them.

Fewer approval messages

When a moderated message goes to a very large Distribution List (DL) or group, to reduce latency Exchange Online may split it into multiple copies (aka bifurcation) – each copy can trigger its own approval request. The same can happen when a message is forked by transport or policy, creating duplicate approval requests for the same content. We’ve streamlined the flow so moderators will now typically see one approval request per moderated message, even when it’s forked or processed along multiple paths. If a message truly requires multiple approvals, each path still must be approved to release the message to all recipients.

How these updates help your organization

Faster, more flexible approvals: Moderators can act from their preferred device – no need to switch clients.
Consistent experience: Same UI and actions across Windows, Mac, web, and mobile.
Less noise: One approval request per message in most cases, reducing moderation notification fatigue while keeping all delivery paths correct.

When these will be available

Actionable Messages adaptive cards for moderation approvals will roll out starting early March 2026 and should finish by late April 2026 (for Worldwide and GCC environments). Actionable Messages isn't yet supported in GCC High or DoD environments so the moderation approval experience will continue to use the legacy voting buttons method in those environments for the foreseeable future.

The rollout of approval message consolidation will also occur in the same early March to late April timeframe, across all environments (Worldwide, GCC, GCC High, and DoD).

What admins should know

The Actionable Messages feature must be enabled for email in your tenant to take advantage of the new moderation approval experience across all Outlook clients. If Actionable Messages has been disabled (it's enabled by default), you can enable it via PowerShell:

Set-OrganizationConfig -SmtpActionableMessagesEnabled $true
Set-OrganizationConfig -ConnectorsActionableMessagesEnabled $true

The Actionable Messages feature is only supported in Microsoft 365 and not on-premises, so in Exchange hybrid organizations on-prem moderators will not see the approval buttons rendered inline. To ease the transition to the Actionable Messages we'll support both the legacy voting buttons and adaptive cards experiences until July 31, 2026. After that, only the new Actionable Messages adaptive cards method will be supported, and moderators will thereafter have to have their mailboxes hosted in Microsoft 365.
During the dual-mode period (end of July), moderators may see approval messages rendered in a variety of ways: with legacy voting buttons only, with adaptive card inline buttons only, or both. All of them will be supported and work until end of July. After that, approval via voting buttons will be deprecated and only the Actionable Messages adaptive card approval buttons will be supported and rendered.

Learn more

FAQs

Q: I see both the voting buttons and the new inline buttons in approval messages. Which should I use to approve the message?
A: Either one will work.

Q: What if my organization uses custom transport rules that cause message forking?
A: In forked scenarios, you may still see more than one approval request – each path must be approved to release the message to all intended recipients. This preserves correctness for all delivery paths.

Microsoft 365 Messaging Team

Microsoft Graph User Configuration API (preview) - now available

The_Exchange_Team — Thu, 29 Jan 2026 15:34:24 GMT

We wanted to post a quick note that on the Microsoft 365 Developer Blog, a new post was published discussing availability of the preview of Microsoft Graph User Configuration API.

This is important to all of our customers and partners utilizing Exchange Web Services (EWS) in Exchange Online today. As we have mentioned previously, EWS in Exchange Online is being deprecated. You can read the developer post here:

Introducing the Microsoft Graph User Configuration API (preview) - Microsoft 365 Developer Blog

The Exchange Team

Trust DigiCert Global Root G2 Certificate Authority to Avoid Exchange Online Email Disruption

The_Exchange_Team — Wed, 18 Mar 2026 15:01:57 GMT

UPDATE 3/16/2026: We worked with the partner team to republish the Microsoft 365 Root Certificate Chain Bundles for Worldwide (WWMT) and GCC High / DoD (ITAR) after identifying that the previously published bundles were missing the intermediate certificate. If your organization needed to install the certificate bundle, you must re-download the updated bundle (released on 3/16) to get the new intermediate certificate and complete the certificate trust steps again as soon as possible (by March 22, 2026). Failure to trust the updated DigiCert Global Root G2 chain and its intermediates may result in mail flow disruption once providers begin distrusting the DigiCert G1 root.

To avoid mail flow disruption between your organization and Exchange Online, organizations that send or receive email to or from Exchange Online over SMTP must ensure that their servers and clients trust the DigiCert Global Root G2 Certificate Authority and its subordinate CAs before March 22, 2026.

You can find a comprehensive list of the root and subordinate certificate authority chain in the Azure Certificate Authority Details documentation and in the DigiCert Knowledge Base.

The following information can help you identify the DigiCert Global Root G2 Certificate:

SHA1 Thumbprint:
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

Serial Number:
03:3A:F1:E6:A7:11:A9:A0:BB:28:64:B1:1D:09:FA:E5

Who needs to take action

NOTE: Windows operating system handles updating certificate trusts automatically by default. Customers running email workloads on Windows (e.g. on-premises Exchange Server) who never disabled this Windows feature do not need to take any action.

However, if your organization sends or receives email to or from Exchange Online over SMTP and meets either of the following two criteria, you may need to complete the installation steps in “What you must do”:

1. Your organization has disabled the Windows CTL Updater feature that by default downloads the Certificate Trust List (CTL), which contains trusted and untrusted root certificates. This could be the case if your organizations maintain their own set of trusted Root and Intermediate Certificates via Group Policy or via redirected Microsoft Automatic Update URL.

You can check the last sync state for the trusted and untrusted root certificates by running the following commands from Windows Command prompt (note that running these commands will trigger an on-demand synchronization of the Microsoft trusted root list, if the feature is not explicitly disabled and if Windows determines that the local AuthRoot CTL is stale or incomplete):

certutil -verifyctl AuthRoot | findstr /i "lastsynctime"
certutil -verifyctl Disallowed | findstr /i "lastsynctime"

If the time returned is recent – Windows CTL Updater feature is working. Most of our customers do not disable this.

2. You use older application runtime environments like legacy Java runtimes (e.g., legacy JDK/JRE versions), embedded systems and appliances, custom or outdated Linux images or air-gapped environments to connect or receive email from Exchange Online.

This change applies to any system performing full certificate chain validation against Exchange Online, including Exchange Server, security appliances, and third-party email gateways. If you use third-party email appliances, please contact the vendor directly for support.

Why this matters

Root Certificate Authorities (CAs) form the foundation of public certificate trust, as operating systems, browsers, and applications rely on their root certificates in trust stores. CAs use these root certificates to issue Intermediate CA certificates, which then issue TLS and other digital certificates.

If a Root CA certificate becomes invalid or untrusted, all certificates issued by its Intermediates lose trust as well. That also implies that if a Root CA is not explicitly trusted, then the certificates issued by its Intermediate CAs are not valid either.

Microsoft uses multiple intermediate certificate authorities that are issued by the DigiCert Global Root G2 root certificate authority to sign TLS certificates for its services (e.g., Exchange Online). For this trust chain to work, the DigiCert Global Root G2 root certificate must be present and trusted in the client’s trust store; otherwise, TLS connections will fail.

If the DigiCert Global Root G2 root certificate is not installed or if the client cannot obtain the intermediate CA certificate from the server during the TLS handshake or retrieve it via the Authority Information Access (AIA) extension, you may see:

The client may refuse to send email if strict certificate verification is enabled, or it may fall back to unencrypted SMTP if allowed
The client may refuse to accept incoming connections from Exchange Online, resulting in failed or delayed email retrieval

If the email client cannot trust the server, a secure communication is blocked.

What you must do

Check to see whether your machines have the DigiCert Global Root G2 certificate installed

You can use the following PowerShell command to validate if the DigiCert root certificate is trusted:

Get-ChildItem -Path Cert:\LocalMachine\Root\ | Where-Object { $_.Thumbprint -eq "DF3C24F9BFD666761B268073FE06D1CC8D4F82A4" }

If this command returns a certificate (the output shows the thumbprint and subject), you should be good and no further actions are required:

Result indicating the required certificate is already trusted on the local Windows machine.

In addition to the Root certificate, there are several related Intermediate certificates.

If no result is returned, and you do not want to re-enable the Windows CTL Updater feature you must act by doing the following:

Manually download and import the latest Microsoft 365 Root Certificate Chain bundles

Microsoft supplies a collection of root certificates that are required to be trusted, as their associated Intermediate Certificate Authorities issue certificates essential for Microsoft 365 services.

You can download the certificate bundles (.p7b / PKCS #7 file format) from here (use the latest download):

Microsoft 365 Root Certificate Chain Bundle – Worldwide
- Microsoft 365 operated by 21Vianet customers should use the Worldwide bundle
Microsoft 365 Certificate Bundle - DoD/GCC High

After downloading, open an elevated PowerShell window and execute the following command. Ensure that you update the path and file name to correspond to the actual .p7b bundle you have obtained:

$p7bPath = "C:\path\to\m365_root_certs_20260316.p7b" $certCollection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection $certCollection.Import($p7bPath) foreach ($cert in $certCollection) { $storeName = if ($cert.Subject -eq $cert.Issuer) { "Root" } else { "CA" } $store = New-Object System.Security.Cryptography.X509Certificates.X509Store($storeName, "LocalMachine") $store.Open("ReadWrite") $store.Add($cert) $store.Close() Write-Host "Imported: $($cert.Subject) to store: LocalMachine\$storeName" }

Confirm the import worked by running the command mentioned in step 1 above.

What would the error look like, if this is not addressed?

If you don't install the DigiCert Global Root G2 root certificate and your systems rely on old root certificates for validation, your mail flow could be disrupted after March 22, 2026. The specific issues you encounter will depend on your operating system and application configuration. Here are some possible examples:

If Exchange Online can't connect to your on-premises Exchange Server, you may see the following when running a message trace in the Exchange Online Admin Center:

Reason: [{LED=450 4.4.317 Cannot establish session with remote server [Message=451 5.7.3 STARTTLS is required to send mail]

How Exchange Online Message Tracking might show the error if the receiving server does not trust the certificate.

The issue could also be present if your on-premises environment tries to connect to Exchange Online. The error in your on-premises protocol log would be similar to:

451 5.7.3 STARTTLS is required, 5.7.0 Must issue a STARTTLS command first

When using OpenSSL to connect (for example, on a machine which is running a Linux operating system or an application that makes use of OpenSSL), it can’t retrieve the local issuer:

OpenSSL s_client -starttls smtp -connect <tenant>.mail.protection.outlook.com:25 -showcerts

An error that (for example) a Linux system could show if it does not trust the certificate when trying to connect to Exchange Online.

Summary

It is crucial to complete the steps outlined in this blog post before March 22, 2026. Failing to perform these updates may result in significant disruptions to your organization's mail flow with Exchange Online.

By ensuring that the necessary certificates are installed and up to date, you help maintain secure and uninterrupted communication between your systems and Microsoft 365. Please prioritize these actions to avoid any potential issues with email delivery after the deadline.

Note: our Exchange Online customers have now received a Message Center (MC) post on this, MC1224565.

Significant changes to this post:

3/18/2026: Added a script sample that will import appropriate certificate into the appropriate certificate store (Root vs. Intermediate)
3/17/2026: Removed the mention of a single older Intermediate certificate from instructions. The new Certificate bundle contains multiple Internediate certificates needed.
3/16/2026: Removed Option 2 (manually downloading the intermediate certificate) as the new intermediate certificate is now included in the certificate bundle.
3/16/2026: Latest update to timeline, now set to March 22. Mentioned that the certificate bundle was republished.
3/12/2026: Added a clarification in few places that this change applies to customers/systems that send email over SMTP.
2/23/2026: Added more detail about importing and validation of intermediate certificate.
2/10/2026: Added a note about intermediate certificates (this is very infrequent).
2/4/2026: Changed the deadline to March 15 due to speed of overall industry deprecation.

Microsoft 365 Messaging Team

Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline

The_Exchange_Team — Thu, 29 Jan 2026 21:05:48 GMT

We understand that many customers continue to face real challenges modernizing legacy email workflows and need sufficient time to adopt viable, secure alternatives. Based on customer feedback and visibility into adoption progress, we are refining the Exchange Online SMTP AUTH Basic Authentication Deprecation timeline to provide clearer milestones and additional runway.

Now to December 2026: SMTP AUTH Basic Authentication behavior remains unchanged.
End of December 2026: SMTP AUTH Basic Authentication will be disabled by default for existing tenants. Administrators will still be able to enable it if needed.
New tenants created after December 2026: SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method.
Second half of 2027: Microsoft will announce the final removal date for SMTP AUTH Basic Authentication.

These updates are intended to give customers with tenants in our service (all cloud environments) more time to plan, validate, and deploy modern authentication alternatives, while maintaining a clear path toward stronger default security.

Microsoft 365 Messaging Team