Exchange Team Blog articles

Reminder: Exchange 2016 and 2019 ESU Program Ends in October 2026

The_Exchange_Team — Mon, 20 Jul 2026 18:10:45 GMT

Over the last several weeks we have received several questions about possible extension of the Exchange Server 2016/2019 ESU program past October 2026. After all, in our original Exchange 2016/2019 ESU announcement we said that there would be no extensions, but then we ended up creating a Period 2 Exchange ESU program that is scheduled to end with October 2026. We are just about at the mid-point of Period 2 Exchange ESU now.

There will be no further extension of Exchange 2016/2019 ESU program timeline. Once October 2026 ends, there will be no further updates for Exchange 2016/2019, even if you currently have a Period 2 ESU.

If your organization still uses Exchange 2016 or 2019 in production:

See Upgrading your organization from current versions to Exchange Server SE | Microsoft Community Hub – which lays out the path for how to migrate to Exchange SE if you plan to keep Exchange on-premises.
Why “in-place upgrade” from Exchange 2019 to Exchange SE is low risk | Microsoft Community Hub – which explains why in-place upgrade from Exchange 2019 CU14/CU15 to Exchange SE RTM is not a significant technological change and is low risk.

Please review Microsoft Exchange Online and Exchange Server Licensing FAQs especially "What is Exchange Server Subscription Edition (SE) and how is it licensed?” section. Exchange 2019 and Exchange SE licensing requirements are the same.

The Exchange Server Team

Released: July 2026 Exchange Server Security Updates

The_Exchange_Team — Fri, 24 Jul 2026 18:41:35 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, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The July 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

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).

Check for presence of legacy Exchange security groups

While not directly related to our July 2026 SU release, we wanted to call out that Exchange Health Checker script will now also check for the presence of very old, deprecated Exchange Server security groups, namely Exchange Domain Servers and Exchange Enterprise Servers. Those groups have been deprecated since Exchange 2007, should not be in use, and should be deleted as they might provide more permissions than modern Exchange security groups. Please see related documentation here.

Customers who have removed last on-premises Exchange Server from their organizations should also check for the presence of those groups and delete them to help prevent their possible abuse. Note that if you no longer have any Exchange servers on premises, you might want to perform a more comprehensive Active Directory cleanup as per this article.

Remove CVE-2026-42897 mitigations after installation

Installing the July 2026 update does not automatically remove already applied CVE-2026-42897 mitigations. Therefore, once you install July SU, you should:

If mitigation was applied using Exchange Emergency Mitigation (EM) Service:

Remove the mitigation M2.1.0 IIS rules.

If mitigation was applied using the downloadable EOMT script https://aka.ms/UnifiedEOMT:

Roll back the mitigation.

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

Exchange Server 2016 and 2019 are out of support. Only customers who enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive Exchange Server 2016 and 2019 security updates released between May and October 2026.

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

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

Known issues with this release

Wrapper messages appear in shared mailbox inbox in hybrid environments | Microsoft Support

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

When CVE-2026-42897 mitigation was released, there were several reported known issues. Are those addressed in this update?
Yes, when July 2026 SU is installed and mitigation is removed, mitigation known issues should be resolved too.

If we update some of our servers but cannot update others, can servers that will not receive update stay with CVE-2026-42897 mitigations? Is it OK to have some servers updated and some still using mitigations?
You can continue using mitigations on any servers that you cannot update to July 2026 SU (or newer). But note that known issues from mitigations will continue to apply to those servers. Additionally, after applying this update, Office Online Server (OOS) integration with Exchange Server might not function as expected until all Exchange servers in the organization have been updated.

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 Period 2 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 Period 2 ESU program (which is valid between May and October 2026) can obtain Exchange 2016 or 2019 updates released after May 2026. For all other 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

Cross-Tenant Message Recall in Exchange Online

The_Exchange_Team — Fri, 10 Jul 2026 15:38:58 GMT

Since we released cloud-based Message Recall in April 2023 (see Cloud-based Message Recall in Exchange Online), we’ve continued to expand where and how recall works – including support for Outlook on the web and mobile, recipient recall notifications, a maximum recallable message age, and support for external round-trip routing (see Exchange Online Message Recall Updates).

Until now, all these capabilities shared one boundary: Message Recall only worked within a single tenant. Today, we’re pleased to announce one of our most requested cross-organization enhancements:

Cross-Tenant Message Recall, controlled by a tenant admin allow list

The intra-tenant boundary

By design due to privacy concerns, Message Recall operates within the Exchange Online service boundary, and until now it has been limited to intra-tenant messages – those where the sender and the recipients belong to the same Microsoft 365 tenant. When a sender tried to recall a message they had sent to recipients in a different tenant, the recall would fail, even between organizations that work closely together and trust one another.

Customers told us this was a gap. Partners, subsidiaries, and affiliated organizations that collaborate daily across tenant boundaries wanted the same recall experience they already had inside their own tenant.

Introducing cross-tenant Message Recall

With Cross-Tenant Message Recall, a tenant admin can add other Microsoft 365 tenants to an allow list. Once a tenant is on the list, senders from those allow-listed tenants can recall messages they’ve sent to recipients in the receiving tenant – just as they would for an intra-tenant recall.

Control sits with the receiving tenant – the organization whose users received the messages. A cross-tenant recall is only honored when the receiving tenant’s admin has explicitly allow-listed the sender’s tenant. This keeps the receiving organization in full control of which external tenants are permitted to recall messages from its users’ mailboxes. The feature is disabled by default; no cross-tenant recall occurs until an admin adds at least one tenant to the allow list.

How it works

Consider two organizations that work together, Contoso and Fabrikam, both of whom are hosted in Microsoft 365:

A Contoso admin adds Fabrikam’s tenant to Contoso’s cross-tenant recall allow list.
A sender at Fabrikam recalls a message they previously sent to a recipient at Contoso.
Because Contoso has allow-listed Fabrikam, the recall is honored and processed like a standard recall against the Contoso recipient’s mailbox.

If Fabrikam is not on Contoso’s allow list, the recall fails and the Fabrikam sender will see in the recall status report that the message can’t be recalled across organizations. Allow-listing governs inbound recalls into the receiving tenant, so each organization decides independently which external tenants it trusts to recall messages from its mailboxes.

Configuring with Exchange Online PowerShell

Admins can configure these settings using Exchange Online PowerShell.

Enable or disable cross-tenant message recall for the tenant. Setting this parameter to $True turns on the capability; $False (default) turns it off:

Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled [$true | $false]

Specify external tenants to add or remove from the allowed list. Add the tenant IDs of the organizations you trust to perform recalls:

Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId 1>","<tenantId 2>"}; {Remove="<tenantId 1>","<tenantId 2>"}

What senders and recipients see

When a sender in an allow-listed tenant recalls a message, recipients in the receiving tenant experience the recall exactly as they would an intra-tenant recall. If the receiving tenant has enabled recipient recall notifications, those notifications apply to cross-tenant recalls as well. If the sender’s tenant is not on the receiving tenant’s allow list, the sender receives a notification that the message can’t be recalled across organizations.

Availability

Cross-Tenant Message Recall will start to deploy to worldwide, GCC, GCC High, DoD and Microsoft 365 operated by 21Vianet starting mid-August, completing by mid-September. We hope you’ll find this enhancement useful, and we look forward to your feedback.

Microsoft 365 Messaging Team

Upcoming retirement of OWA Light in Exchange Server

The_Exchange_Team — Wed, 08 Jul 2026 13:08:33 GMT

We are announcing our plan to retire and disable the OWA Light experience in Exchange Server in a future update. OWA Light was created for a much earlier era of the web, when browser support, bandwidth, and accessibility technologies were very different from today. Going forward, we want to invest in modern Outlook on the web experience that provides the cross-browser, accessible, and security-focused experience.

Organizations that still rely on OWA Light must move users to the standard Outlook on the web experience and review any internal guidance, bookmarks, training material, helpdesk scripts, or accessibility workflows that reference OWA Light.

This is how OWA Light looks like:

What is changing

In an upcoming Exchange Server update (estimated in August 2026), we plan to disable and remove the OWA Light experience. After that change is introduced, users will no longer be able to choose or be redirected to OWA Light and should use the modern Outlook on the web experience instead.

This announcement applies to Exchange Server (on-premises). We announced deprecation of OWA Light in August 2024.

Why we are making this change

OWA Light served customers well for many years. It was designed for older browsers, slower connections, and scenarios where a simplified web interface helped users access mail in environments that could not support the full Outlook Web App experience.

The web has changed significantly since OWA Light was introduced. Modern browsers are more capable and more consistent, network conditions have improved for many customers, and security landscape has changed significantly. Maintaining a separate legacy OWA Light experience increases complexity. Each additional content rendering path, control surface, and compatibility layer must be evaluated as we strengthen defenses against modern web threats.

We recommend that Exchange Server administrators use this time to identify and prepare any users, processes, or documentation that still depend on OWA Light.

To block OWA Light right away, you can create or update an existing OWA mailbox policy:

Set-OwaMailboxPolicy -OwaLightEnabled $false

Make sure that the OwaMailboxPolicy is assigned to all mailboxes. You can assign a OwaMailboxPolicy by using the Set-CasMailbox -OwaMailboxPolicy <Name> cmdlet.

Additionally, disable the OWA Light selection menu on the OWA logon page. You can do that by running:

Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $false

More information can be found in the Set-OwaMailboxPolicy and Set-OwaVirtualDirectory documentation.

Summary

OWA Light was an important compatibility experience when the web needed it. Today, the full Outlook on the web experience is the right place for us to focus. Retiring OWA Light will help reduce legacy surface area, simplify ongoing engineering work, and allow us to continue improving the experience customers use every day.

The Exchange Server team

Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement

The_Exchange_Team — Mon, 29 Jun 2026 14:57:47 GMT

Exchange Web Services (EWS) retirement in Exchange Online is entering its final phase. Over the last several years, Microsoft has worked with product teams, independent software vendors (ISVs), and customers across the ecosystem to migrate workloads to Microsoft Graph and other modern APIs. Many of those migrations are complete, and many others are well underway.

As phased EWS disablement in Exchange Online approaches in October 2026, we are introducing a new capability to help administrators prepare in a controlled and predictable way: EWSAllowedAppIDs. This is the Allow List functionality that we mentioned in Exchange Online EWS, Your Time is Almost Up | Microsoft Community Hub.

EWSAllowedAppIDs gives administrators a practical way to identify remaining dependencies, limit EWS access to approved applications, and reduce the risk of disruption as retirement enforcement begins.

This feature is starting to roll out now. All tenants should be able to view the parameter when running Get-OrganizationConfig, but they won’t be able to set the list until the roll out reaches the tenant.

What is EWSAllowedAppIDs?

EWSAllowedAppIDs is a tenant-level allow list that lets Exchange Online administrators explicitly define which applications are still permitted to access EWS, based on their App ID.

When configured, only applications whose App IDs appear in the allow list can continue using EWS in the tenant when EWSEnabled at the tenant level is set to True.

This feature is designed to support the final transition away from broad, unrestricted EWS access and toward tightly scoped, intentional usage during the retirement window.

Note: The EWSAllowList feature Exchange has had for many years is based on User Agent, not App ID (and it applies to REST/Graph not just EWS by the way). Both can work together, but they operate on different aspects of the calling application.

Administrators can use the feature to:

Identify which applications still require EWS
Restrict EWS access to only approved applications
Prepare for the final retirement of EWS in Exchange Online

How EWSAllowedAppIDs fits into the EWS endgame

We previously announced that phased EWS disablement in Exchange Online will begin in October 2026.

To understand why EWSAllowedAppIDs matters, it helps to look at how Exchange Online behavior changes before and after that date. The retirement model uses the existing EWSEnabled organization-level setting together with the new EWSAllowedAppIDs allow list. (Refresh yourself on how the EWSEnabled switch works and how to set it here)

Before October 2026, the behavior is intentionally permissive to give customers time to inventory dependencies, deploy an allow list, and validate which applications still require EWS.

Before October 2026

EWSEnabled Value	Allow List State	Behavior
Null (default)	Ignored	All EWS traffic allowed
True	Empty	All EWS traffic allowed
True	Populated	Only listed applications allowed
False	Any	All EWS traffic blocked

This pre-October phase gives administrators room to deploy and test an allow list without immediately breaking existing applications.

What changes in October 2026

Beginning in October 2026, Exchange Online starts transitioning tenants into retirement enforcement behavior.

At that point, enabling EWS without configuring an allow list will no longer act as an unrestricted “allow everything” mode.

Starting October 2026

EWSEnabled Value	Allow List State	Behavior
Null	Ignored	All EWS allowed (but tenant will have EWSEnabled set to False at some point as part of phased rollout by Microsoft)
True	Empty	All EWS traffic blocked
True	Populated	Only listed applications allowed
False	Any	All EWS traffic blocked

This is the most important behavioral change administrators need to understand: after enforcement begins, setting EWSEnabled=True without an allow list effectively becomes a block-all configuration.

This change is intentional. The goal is not to keep EWS available indefinitely, but to require explicit acknowledgement that EWS is still needed and to scope that usage down to known, approved applications.

The goal of the retirement process is not simply to keep EWS “on” indefinitely, but to:

Force explicit acknowledgement that EWS is still required
Scope usage down to known, approved applications
Accelerate migration to Microsoft Graph and modern APIs

What happens if a tenant admin does nothing?

Today, many tenants still have EWSEnabled unset (Null), which behaves as unrestricted access.

As the phased retirement rollout starts in October 2026, those tenants will have EWS disabled (EWSEnabled set to False) as part of the staged shutdown process.

Administrators who still require EWS at that point will need to take explicit action.

The recommended path is:

Configure or validate the EWSAllowedAppIDs allow list (remember, we said we would populate this for tenants who have not done so in September – read more here – but the admin owns ensuring it’s correct).
Set EWSEnabled=True

Customers who complete this work proactively will be significantly less likely to experience disruption during the broader retirement rollout.

Why we strongly recommend enabling this feature now

Customers should not think of EWSAllowedAppIDs as a feature intended only for October 2026. Its greatest value is in the preparation period before enforcement begins.

Deploying and validating the allow list now gives administrators time to find unknown dependencies, remove obsolete applications, engage vendors that still rely on EWS, and begin migrations to Microsoft Graph.

Discover unknown EWS dependencies
Remove obsolete applications
Contact vendors still requiring EWS
Begin migrations to Graph APIs
Validate which applications truly still require exceptions
Reduce future support escalations and outages

Administrators who wait until they are already impacted by phased disablement will have a much smaller remediation window and a significantly higher likelihood of disruption.

Recommended next steps for administrators

We strongly recommend that Exchange Online administrators begin this work now:

Inventory EWS usage

Identify all applications and services currently using EWS in your organization. Use EWS usage reports where available in your tenant, and review Message Center posts that summarize tenant usage. Please see Notes From the Field: Finding and Remediating EWS App Usage Before Retirement | Microsoft Community Hub.

Build an allow list

Create an EWSAllowedAppIDs allow list containing only applications that are known to still require EWS. This includes Microsoft first-party client apps such as Office, Power Query for Excel etc. If the app shows up in your usage report, and you want to keep using it, you need to add it to the list.

If an administrator already knows which applications they want to permit, they can create a new allow list directly by specifying one or more App IDs.

For example:

Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

This replaces the current value with the specified set of allowed applications.

After setting the value, administrators can confirm the configured list using:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The use of “RetrieveEwsOperationAccessPolicy” is required for performance reasons – we only want to retrieve this list if the admin explicitly asks for it.

Administrators should be aware that setting the property writes the full list value. If the property already contains App IDs, they will be replaced unless included in the new command. See more below on this.

Test thoroughly

Validate that all applications on your allow list continue to work as expected, and check for any missed dependencies. If you need to add or remove an App ID, you must read the current list, compute the updated list, and then write the full value back. Today, this cmdlet does not support incremental add or remove operations.

Here are two examples that show how to update the list:

Example: add a new App ID

The common pattern is to read the current list, append the new App ID, and then write the full combined list back.

# Read the current allow list $current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs) # Define the new App ID to add $newAppId = "99999999-8888-7777-6666-555555555555" # Combine existing and new values $updated = @($current, $newAppId) # Write the updated allow list back Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Example: remove an App ID

Because there is no single-item removal operation today, removal also requires recomputing the full list.

# Read the current allow list $current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs) # Define the App ID to remove $removeAppId = "99999999-8888-7777-6666-555555555555" # Split the comma-separated list into individual App IDs $appIds = $current -split "," # Remove the specified App ID $updated = $appIds | Where-Object { $_ -ne $removeAppId } # Write the updated allow list back Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

The bigger picture

EWS served the Exchange ecosystem for nearly two decades.

However, modern requirements for security, reliability, compliance, and scale call for a more modern API platform. Microsoft Graph is the long-term strategic platform for most Exchange Online integration scenarios.

EWSAllowedAppIDs is designed to make the final transition manageable and predictable while still encouraging rapid migration off EWS.

Organizations that prepare early will navigate this transition most smoothly. Administrators who inventory dependencies now and validate their allow lists well before October 2026 will be far better positioned to avoid disruption as phased retirement begins.

The time to prepare is now.

For the latest on the overall plan, status on parity gaps and links to resources, please check the Deprecation of Exchange Web Services in Exchange Online page.

The Exchange Team

Released: June 2026 Exchange Server Security Updates

The_Exchange_Team — Tue, 14 Jul 2026 17:23:34 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, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The June 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes as well as CVE-2026-42897 that we announced: Addressing Exchange Server May 2026 vulnerability CVE-2026-42897 | Microsoft Community Hub.

Update to ensure continued function of Exchange Emergency Mitigation (EM) and Feature Flighting services

Due to service-side change, the Exchange Emergency Mitigation (EM) and Exchange Flighting services will be unable to use configuration files released in July 2026 or later, unless Exchange is updated to June 2026 update (or newer). Any mitigations already downloaded and applied will keep working, but servers will not be able to use any new mitigations starting in July 2026 unless updates are installed. Please see Exchange mitigation and flighting services fail due to "Unknown Issuer" error for more details.

CVE-2026-42897 mitigations after installation

As part of our ongoing efforts to strengthen security and improve defenses across environments, we continue to enhance protections for cross-site scripting attacks. We recommend that customers keep CVE-2026-42897 mitigation in place. The mitigation provides an additional layer of defense and helps ensure continuous protection as further improvements are released. Additional updates will be shared as they become available - now available, please see Released: July 2026 Exchange Server Security Updates | Microsoft Community Hub.

Installing the June 2026 update does not automatically remove already applied CVE-2026-42897 mitigations. Therefore, if you choose to remove mitigations after installation, you should:

If mitigation was applied using Exchange Emergency Mitigation (EM) Service:

Block the mitigation M2.1.0 from re-applying. Because of our recommendation to keep the CVE-2026-42897 mitigation in place, we are not yet updating the mitigation to not apply to servers that are updated to June 2026 SU. Therefore, at this time, you must block the mitigation from re-applying first.
Remove the mitigation M2 IIS rules.

If mitigation was applied using the downloadable EOMT script https://aka.ms/UnifiedEOMT:

Roll back the mitigation.

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

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

Known issues with this release

Wrapper messages appear in shared mailbox inbox in hybrid environments | Microsoft Support

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

When CVE-2026-42897 mitigations were released, there were several reported known issues. Are those solved in the CVE-2026-42897 fix (June 2026 SU)?
Yes, when June 2026 SU is installed and mitigation is removed, known issues should be resolved too. But note that mitigations do not get removed automatically after installation of the SU (and we recommend that you keep then enabled for a little while longer).

If we update some of our servers but cannot update others, can servers that will not receive update stay with CVE-2026-42897 mitigations? Is it OK to have some servers updated and some still using mitigations?
You can continue using mitigations on any servers that you cannot update to June 2026 SU (or newer). But note that known issues from mitigations will continue to apply to those servers. Additionally, after applying this update, Office Online Server (OOS) integration with Exchange Server might not function as expected until all Exchange servers in the organization have been updated.

We updated our servers to June 2026 (or newer) update, but we still have trouble with known issues caused by mitigations. Why is this?
Installing the June 2026 (or newer) update does not automatically remove mitigations. Please see the post above. Currently, we recommend that mitigations stay in place but they can be removed as per the above.

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

Significant updates to this post:

7/14/2026: Added a link to Released: July 2026 Exchange Server Security Updates | Microsoft Community Hub. When installed, remove the CVE-2026-42897 mitigation to address known issues
7/13/2026: Added a Known issues section
6/15/2026: Clarification of mitigation blocking
6/11/2026: Removed the banner with documentation publishing issues (now resolved)

The Exchange Server Team

How to determine which Resource Mailboxes are being actively used

The_Exchange_Team — Fri, 26 Jun 2026 13:57:46 GMT

Today we wanted to take a few minutes to discuss a topic that has come up several times. Consider the scenario where your organization has created Resource mailboxes, and you want to know which ones are actually being used. Seems like a fair request.

This would include Room and Equipment mailboxes as well as Workspaces. Unfortunately, there are no native reports (at the time of this writing) that include details on Resource mailbox utilization. We are going to provide a few options you can use to find this information out, and you can choose which one works for you.

Option 1: Use Get-CalendarViewDiagnostics

Get the ID of a meeting - Exchange | Microsoft Learn

This will check the calendar of the specified mailbox and will provide the output of all meetings on the calendar during the specified time window.

The following example will provide a list of meetings on the calendar going back 6 months in the past and 6 months in the future:

Get-CalendarViewDiagnostics resource@contoso.com -WindowStartUtc (Get-Date).AddMonths(-6) -WindowEndUtc (Get-Date).AddMonths(6)

This returns data quickly and only targets the calendar. The possible downside of this approach is that the meeting subject is not a property that is exposed. But if you are only looking to see which rooms have meetings scheduled, or get an overall count, this should work great for you.

The upside to this approach is that Exchange Online PowerShell has rich filtering capabilities, so for example you could easily target your command to all Room mailboxes or all Equipment mailboxes.

Example:

$roommailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails RoomMailbox $roommailboxes | ForEach { Write-Host “Processing Mailbox $($_.Displayname)” ; Get-CalendarViewDiagnostics $_ -WindowStartUtc (Get-Date).AddMonths(-6) -WindowEndUtc (Get-Date).AddMonths(6) }

Option 2: Use Graph to get the details of calendar events.

List calendarView - Microsoft Graph v1.0 | Microsoft Learn

On the bottom of the article, see example requests. To use this with PowerShell, you need the Microsoft.Graph.Calendar module and you need an Entra ID App registration which has the appropriate Graph permissions added.

You can either use Delegated permissions or Application permissions.

Delegated permissions mean Graph API is being accessed using a user account and will prompt for sign-in information.
Application permissions would be used for non-interactive applications/scripts where a sign-in prompt cannot be used.

Example using Application permissions:

Create Entra ID App registration
Add Graph Application Calendars.Read API permission. This allows the application to read calendar data from all mailboxes.
Create either a client secret or upload a certificate to be used for authentication. If you use a certificate, note that it can be a self-signed certificate.
Launch PowerShell and import the Graph moduleImport-Module Microsoft.Graph
Connect to Graph using PowerShell with a certificateConnect-MgGraph -ClientId <app id=""> -TenantId <your tenant="" id=""> -CertificateThumbprint <cert thumbprint=""></cert></your></app>
or

Connect to Graph using a client secret
Connect-MgGraph -ClientSecretCredential -TenantId <your tenant="" id=""></your>
Display a list of calendar items for a given time period and specify a few properties to show, such as the Organizer, Subject and Start/End time. We will use the same example as with Get-CalendarViewDiagnostics, going back 6 months in the past and 6 months in the future.Get-MgUserCalendarView -UserId resource@contoso.com -StartDateTime (Get-Date).AddMonths(-6) -EndDateTime (Get-Date).AddMonths(6) | select @{n='Organizer';e={$_.Organizer.EmailAddress.Name}}, subject, @{n='StartTime';e={$_.Start.DateTime}},@{n='EndTime';e={$_.End.DateTime}}

Graph does have filtering capabilities, though for me it isn’t quite as easy as filtering in Exchange Online PowerShell. If you can connect to both Exchange Online PowerShell and Graph PowerShell in the same session, you could combine the two and run your command against the list of mailboxes in your variable.

Example:

Get the list of mailboxes from Exchange Online PowerShell:

$roommailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails RoomMailbox

Then use Graph PowerShell to get the Calendar events:

$roommailboxes | foreach {Write-Host "Processing Mailbox $($_.DisplayName)"; Get-MgUserCalendarView -UserId $_.PrimarySmtpAddress -StartDateTime (Get-Date).AddMonths(-6) -EndDateTime (Get-Date).AddMonths(6) | select @{n='Organizer';e={$_.Organizer.EmailAddress.Name}}, subject, @{n='StartTime';e={$_.Start.DateTime}},@{n='EndTime';e={$_.End.DateTime}}}

Note that there are additional properties available in addition to what was provided in the example above. You would need to determine which ones you want to show. Some of them (like Organizer and Start/End) are Type properties, so you must build an expression to handle them like we did above. Graph is also exposed to many other languages as well (HTTP, C#, Java, etc.)

Using the Graph solution, it is also possible to restrict access to only certain mailboxes (such as only Resource mailboxes).

Role Based Access Control for Applications in Exchange Online | Microsoft Learn

This would allow you to control which mailboxes the Entra ID app could pull calendar details from.

It involves configuring a management scope that defines the list of mailboxes (via a recipient filter). Once that is done, the Graph permissions in Entra ID needs to be removed, and they can then be granted in Exchange Online via RBAC (New-ManagementRoleAssignment).

Option 3: Use Get-MailboxFolderStatistics

For a very simplistic approach to checking resource mailbox usage, Get-MailboxFolderStatistics might provide what you need. Using the IncludeOldestAndNewestItems along with the FolderScope allows you to target the Calendar folder.

Example:

Get-MailboxFolderStatistics resource@contoso.com -IncludeOldestAndNewestItems -FolderScope Calendar

Similar to Get-CalendarViewDiagnostics, you have the ability to run in bulk against multiple recipients.

Example:

$roommailboxes | Foreach { Get-MailboxFolderStatistics $_ -IncludeOldestAndNewestItems -FolderScope Calendar}

Do not use Get-CalendarDiagnosticObjects for this purpose!

One last method that we’ve seen customers try use is using Calendar Diagnostic Logs with the Get-CalendarDiagnosticObjects cmdlet. Please DON’T use this method.

Get Calendar diagnostic logs for Exchange Online mailboxes - Exchange | Microsoft Learn

While it technically will work to pull meeting details, it really was not designed for bulk gathering of calendar events. Instead, it was designed to help troubleshoot problems with individual meetings. Calendar Diagnostic Log data includes not only data from the Calendar, but also all other folders where calendar-related information can be stored, including the Inbox, Sent Items, Deleted Items and Recoverable Items folders such as Calendar Logging. Querying even for a single meeting can sometimes produce in excess of 1000 logs. As such, running this in bulk for lots of meetings against a mailbox may fail, might timeout or produce errors. If you are using this method and reach out to Support because you have issues (which is very likely), we will direct you to one of the other options.

In summary, although there are no native reports available to check on which Resource Mailboxes are being used, there are several options available. If you are already connected to Exchange Online PowerShell, using Get-CalendarViewDiagnostics may be the simplest option for you. If you need more properties than what is exposed with Get-CalendarViewDiagnostics or want to be able to use a custom application that uses a different language, we recommend the Graph approach.

Ben Winzenz

Replacing IIS SMTP virtual server with Exchange Edge Transport

The_Exchange_Team — Tue, 19 May 2026 14:14:31 GMT

Years go by and we continue to see customers still relying on the IIS 6.0 SMTP virtual server feature, which has been out of support for a looong time. To give you an idea just how old this component is, the built-in IIS SMTP virtual server stack was tied to Windows Server 2003. This blog post aims to present practical options to help you retire IIS SMTP and replace it with supported Microsoft solutions (because IIS SMTP virtual server is long unsupported).

Historically, we have encouraged customers to retain their last Exchange on‑premises server in certain scenarios. One of the most common scenarios is on‑premises applications still depend on Exchange for email relay, even after all mailboxes have been migrated to Exchange Online.

Then there are also cloud‑only Exchange Online customers who have already decommissioned their last on‑premises Exchange server (or never had one at all) and, for various reasons, are unable to configure their applications, Fax and printers to relay email directly through Exchange Online. When this scenario applies, the most straightforward and supported way to eliminate the use of IIS SMTP is to replace it with a standalone Exchange Edge Transport Server. This also helps with centralized administration of one or few Edge servers instead of several applications and devices individually.

You might not know this, but running a standalone Exchange Edge Transport server can be done with minimal overhead.

It’s important to clarify what “standalone” means in this context. A standalone Edge Transport server is not subscribed to an Active Directory site. Whether or not the server is domain‑joined is irrelevant here; what truly matters is that the Edge Transport server is not Edge‑subscribed to Active Directory. In this configuration, Active Directory is effectively unaware of this Exchange server’s existence.

Why does this matter? Because subscribing an Edge Transport server to an AD site introduces additional complexity such as EdgeSync, dedicated certificates for Direct Trust, and extra operational considerations. The goal of this blog post is to provide a simple, low‑effort, and supported solution that allows you to finally retire use of legacy IIS 6.0 SMTP server without introducing unnecessary complexity into your environment.

Let’s see the following flowchart to understand the big picture of options you have:

¹ It is important to consider if the application and devices send email to only Exchange online mailbox or also send to external domains. Based on the requirement, you will need to evaluate your options mentioned in this article. If you want to send emails to external domains which essentially is relaying through Exchange online, you can:

Configure a TLS certificate-based connector for SMTP relay - this is a secure way to relay email. You need a certificate where the Subject or Subject Alternate Name (SAN) fields contain an accepted domain in Microsoft 365.

Or you can

Configure an IP address-based connector for SMTP relay - this is a less secure way to relay and is not recommended. With this method, the sender domain mentioned in the MAIL FROM must match one of the accepted domains of the tenant.

Whether you use Certificate based or IP Based connector, make sure you meet the requirements mentioned in this article.

Is it feasible to redirect all on-premises applications to Exchange Online?

There may be multiple blockers, such as:

Applications that are not allowed to perform outbound external connectivity
Legacy applications with unknown ownership or configuration
Limited ability to update or reconfigure existing applications

There are several challenges to send or relay email directly from Application and devices. Applications and devices may not support TLS/STARTTLS, and managing certificates across multiple endpoints – such as printers in branch offices – can introduce significant operational complexity and potential security risks.

A more suitable solution in this case is to deploy a standalone Edge Transport server. This allows you to centralize SMTP relay functionality and securely send messages to Exchange Online or external domains without requiring individual devices or applications to meet strict TLS and certificate requirements.

What type of authentication is used by these applications?

For example, Basic Authentication or NTLM. If either is in use:

SMTP Basic Authentication is being deprecated in Exchange Online
NTLM is not supported with Exchange Online for SMTP scenarios

As a result, reliance on these authentication methods may prevent Exchange Online use.

IIS 6.0 SMTP Assessment

Once you decide to replace your IIS SMTP server, one of the first and most critical steps is to perform a thorough assessment of its current usage.

If logging is not already enabled, ensure it is configured by navigating to:
IIS → SMTP Virtual Server → Properties → Enable Logging → Properties → Advanced

From there, select all relevant extended logging fields that will help you identify which applications and systems are relying on the IIS SMTP server.

It is recommended to allow logging to run for a sufficient period to capture a representative volume of data. This ensures that intermittent or less frequently used applications are also identified.

Additional aspects that should be assessed include:

Access tab → Authentication
Verify which authentication methods are enabled, such as:

Anonymous access
Basic Authentication
Integrated Windows Authentication

Access tab → Relay Restrictions

Confirm whether relay access is restricted to a defined list of IP addresses and review the scope of those restrictions.

Delivery tab → Advanced

Determine how outbound email is being routed:

Whether the server uses a smart host or performs direct DNS lookups

If a smart host is configured:

Go back to Access tab → Outbound Security
Verify whether authentication is required and which method is being used to connect to the smart host

To map these configurations to Exchange Edge Transport, keep the following in mind:

Settings configured under the “Access” tab in IIS SMTP will typically correspond to the Receive Connector on the Edge Transport server.
Settings configured under the “Delivery” tab will map to the Send Connector on the Edge Transport server.

Once IIS SMTP logging has been enabled and sufficient data has been collected, the next step is to analyze the logs to identify key usage patterns, such as:

Source IP addresses of applications relying via the IIS SMTP server
Sender SMTP addresses
Recipient SMTP addresses
Email volume per application and per day

IIS SMTP logs are not particularly user-friendly for analysis, especially at scale. As a result, you have few options to process and extract meaningful insights from this data:

Develop your own SQL query using Log Parser and Log Parser Studio or
Share your IIS SMTP logs with Copilot and ask it to parse according to your needs

Another important aspect to assess is how applications are configured to connect to the IIS SMTP server:

Do applications reference the IIS SMTP server via a hard-coded IP address, or via a DNS alias? The alias could be either a CNAME or a host (A) record.

If applications are using a DNS alias, the transition to Exchange Edge Transport is typically straightforward. In this case, you can redirect mail flow by simply updating the IP address associated with the alias in DNS. However, if applications are configured with a hard-coded IP address, the transition becomes more complex. In this scenario, you have two main options:

Update each application individually: Replace the IIS SMTP server IP with the Exchange Edge Transport IP. This is the cleanest approach; however, it is often the most time-consuming and operationally challenging.
Reuse the existing IIS SMTP IP address: Assign the same IP address to the Exchange Edge Transport server as a secondary IP. While Microsoft generally discourages IP reuse in Exchange environments, this guidance primarily applies to AD-integrated Exchange roles. In this case, since the Edge Transport server is standalone and does not store objects on Active Directory, IP reuse can be acceptable if carefully planned and executed.

Once all relevant IIS SMTP data has been collected and analyzed, you can proceed with the Exchange Edge Transport deployment.

If additional details are required for the assessment phase, refer to the FAQ section, where common caveats and IIS SMTP-specific considerations are covered.

Exchange Edge Transport considerations

Assuming you have decided to decommission IIS SMTP and use the Exchange Edge Transport role for email relay, the next key decision is whether the Edge Transport server should be deployed on a domain-joined machine.

Microsoft generally recommends deploying the Edge Transport role on a non-domain-joined server. However, this guidance applies primarily to traditional Exchange environments where Edge Transport is installed in the perimeter network and is subscribed to an Active Directory site that includes Mailbox servers.

In a scenario where no Exchange Mailbox role is present, the decision should be driven by your authentication, security, and management requirements. To help guide this choice, consider the following questions:

Do you need to enforce Basic Authentication or Integrated Windows Authentication using domain service accounts? If yes, deploying the Edge Transport on a domain-joined server is needed.
Can you rely on local accounts for authentication (e.g., Basic Authentication without domain dependencies)? If yes, a non-domain-joined server is sufficient.
Do you need to apply Group Policy Objects (GPOs) or centralized security baselines? If yes, consider a domain-joined deployment to enable centralized management and compliance enforcement.

Note that whether you install Edge on a domain joined machine or not, because you are not creating a subscription to Active Directory, installation of Edge will not require extending the schema and preparing AD for Exchange Server.

Requirements

Once the decision has been made, proceed with the installation of the Exchange Edge Transport role on an up-to-date server. Follow the official prerequisites documentation to prepare the environment. Note that only a limited set of components is required:

.NET Framework
Visual C++ 2012 Redistributable
Active Directory Lightweight Directory Services (AD LDS)

No additional Exchange roles or dependencies are needed.

Network and security:

TCP port 25 must be permitted between the Edge server and applications or devices that will use Exchange Edge Transport for email relay. Typically, it should not be exposed to internet assuming that these applications or devices are placed within the internal network.
Outbound TCP port 25 must be permitted between the Edge server and external networks to enable SMTP mail flow.
Ensure the server is properly hardened, following standard security best practices.
Refer to this article for Antivirus running on Exchange Server. The “Servers” column can be used to distinguish the necessary exclusions related to Edge Transport.

If high availability is required, consider deploying two standalone Edge Transport servers behind a load balancer, or DNS round-robin. This approach helps minimize service disruption during maintenance activities such as Windows or Exchange patching.

Accepted domain

Since the installation of the Exchange Edge Transport role is relatively straightforward, it will not be covered in this article. At this stage, we assume that the Edge Transport server has already been successfully deployed and is fully operational.

The first step is to configure the Accepted Domains on the Edge Transport server. You can refer to the relevant documentation for the exact command syntax and parameters required.

It is important to note that a standalone Edge Transport role does not have Resolve engines (e.g., no recipient or sender validation against Active Directory or ADAM). Because of this behavior, the distinction between Authoritative and Internal Relay domains does not have a functional impact on the Edge Transport server in this scenario.

Receive connector

Once the Edge Transport is installed, it will automatically create a Receive Connector as described in this article.

To customize the Receive connector to satisfy your needs, you will need to understand how the IIS SMTP was used by your application for email relay. Assuming that your only Accepted Domain is contoso.com:

If your applications are sending unauthenticated to contoso.com recipients (app1@contoso.com sends to john@contoso.com): Use the default connector, no need to create a new one.
If your applications are sending authenticated emails through Basic Auth or Integrated Windows using contoso.com as sender SMTP address to any recipient (app1@contoso.com sends to john@contoso.com and adele@fabrikam.com):

Create a new Receive Connector with ExchangeUsers Permission Group, assign the Authentication mechanism as BasicAuth and/or Integrated and add the IP or range of your applications to RemoteIPRanges:

New-ReceiveConnector -Name "BasicAuth" -AuthMechanism BasicAuth -RemoteIPRanges "192.168.0.1" -PermissionGroups ExchangeUsers -Custom -Bindings 0.0.0.0:25

And add the permission ms-Exch-SMTP-Accept-Authoritative-Domain-Sender to the connector. As mentioned before, since Edge Transport doesn’t have Resolve engine, it cannot validate the primary SMTP address of the authenticated user, otherwise you will get the “550 5.7.60 SMTP; Client does not have permissions to send as this sender” error.

Get-ReceiveConnector BasicAuth | Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"

If your applications require an open relay, although not recommended, you can follow the steps described in this article.

Send connector

In a fresh Exchange Edge Transport installation, no Send connector is created by default. Therefore, you will need to configure it from scratch.

As highlighted earlier, it is essential to first understand how your existing IIS SMTP server handles outbound relay. This includes determining whether it uses:

Direct DNS resolution, or a smarthost (and any associated Basic authentication)
Whether you want to have different routes per domain

This information will directly influence the configuration of your Send connector on the Edge Transport server. You can refer to the relevant documentation for detailed guidance on the required commands and parameters to properly create and configure the Send Connector.

Switch the mail flow

At this stage, the IIS SMTP assessment should already be complete, and you should understand how applications connect to it – a DNS record or a hard-coded IP address.

If a DNS alias is used (e.g., CNAME or A record):
The transition is typically straightforward. You can redirect mail flow by updating the DNS record to point to the Exchange Edge Transport server.
If applications use a hard-coded IP address:
Consider reusing the existing IIS SMTP IP address. The process is relatively simple:
- Disable the network interface (NIC) on the IIS SMTP server
- Assign the IIS SMTP server IP address as a secondary IP on the Exchange Edge Transport server
- Update the existing DNS A record associated with the IIS SMTP server to point to the Exchange Edge Transport server

As a best practice, always validate mail flow with a subset of applications before performing the full cutover. This helps identify potential issues early and ensures a smooth transition.

(Optional) Setting Exchange Online as a smarthost

If you have Exchange Online tenant, you can use your standalone Edge Transport to relay emails through Exchange Online by configuring your tenant MX as a smarthost in the Edge’s Send connector. Although not required, we encourage you to bind a certificate with the same domain name that you have in your Exchange Online as Accepted Domain. This would ensure a proper message attribution process and your emails coming from Edge Transport will be marked as Originating.

First, you need to figure out what is the MX record of your tenant, please follow this appendix to get this information.
Add the value to your Send connector as a smarthost
Import the certificate to the Personal computer container and assign the SMTP service to it
Bind the certificate to the Send connector

$Cert = Get-ExchangeCertificate -Thumbprint "<new certificate thumbprint>"

$TLSCertificateName = "<i>$($Cert.Issuer)<s>$($Cert.Subject)"

Set-SendConnector -Identity "Send Connector Identity" -TlsCertificateName $TLSCertificateName

Set the following properties on the connector:

Set-SendConnector -Identity "Send Connector Identity" -RequireTLS $True -TlsAuthLevel DomainValidation -TlsDomain mail.protection.outlook.com

Now we need to create the Inbound connector in Exchange Online to attribute these messages coming from the Exchange Edge Transport:

New-InboundConnector -Name "FromEdgeTransport" -ConnectorType OnPremises -SenderDomains * -RequireTls $True -TlsSenderCertificateName "Your Certificate CN"

Lastly, ensure to add the EOP and your Edge Transport public IP to the SPF record in the public DNS as described here. This is an important step to avoid either external recipients marking your emails as spoofing or the EOP itself marking emails from your Edge as spoofing. If you want to increase your security posture, you can also enable DKIM and create your DMARC policy for your domains.

FAQ

How to figure out domain or local accounts being used on IIS SMTP to send using Basic Authentication?
Unfortunately, the IIS SMTP logs will not show what account has been used to perform basic authentication when sending emails. The following XML query can be used to filter Security event viewer logs:

<QueryList>
 <Query Id="0" Path="Security">
  <Select Path="Security">
    *[System[(EventID=4624)]]
    and
    *[EventData[Data[@Name='LogonType']='3']]
    and
    *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\inetsrv\inetinfo.exe']]
   </Select>
  </Query>
</QueryList>

What’s the benefit of getting rid of IIS 6.0 SMTP and moving to an Exchange Edge Transport?
IIS 6.0 is no longer supported, and therefore you should not expect any security updates or assistance from Microsoft Support. From a technical perspective, the Exchange Edge Transport role provides significantly more capabilities and control over mail flow, including:

Enhanced logs such as message tracking logs and pipeline tracing
Improved security and control mechanisms
The ability to implement transport rules (although more limited compared to a full Exchange Mailbox role)

Overall, Exchange Edge Transport represents a more modern, secure, and manageable solution compared to legacy IIS SMTP.

Can we use Address Rewrite feature in a standalone Edge Transport?
Yes, but there are important caveats to consider.

Inbound Address Rewrite is supported and works as expected on a standalone Edge Transport. You can safely follow the standard procedure described in the documentation to implement it.

The Outbound Address Rewrite has some limitations that you should be aware of. This feature depends on the Address Rewriting Outbound Agent, which is only triggered when the MAIL FROM is treated as authenticated. Specifically, the agent relies on the presence of the header: X-MS-Exchange-Organization-AuthAs: Internal.

At first glance, you might assume that using Basic Authentication or Integrated Windows Authentication would satisfy this requirement. However, this is not the case for a standalone Edge Transport deployment. Regardless of the authentication method used when submitting messages to a standalone Edge Transport, the header X-MS-Exchange-Organization-AuthAs is always stamped as Anonymous.

As a result, the Outbound Address Rewrite agent is never triggered under normal conditions.

The only supported workaround to force the standalone Edge Transport to treat messages as internal – and therefore enable outbound address rewriting – is to configure the receive connector with the ExternalAuthoritative authentication mechanism. This effectively promotes the AuthAs value to Internal.

Enabling ExternalAuthoritative effectively turns the receive connector into an open relay. You must therefore implement appropriate restrictions (such as IP scoping and strict access controls) to secure the connector and prevent abuse. Refer to this article for further information.

How does Microsoft 365 IP throttling deal with messages coming from a standalone Edge Transport?
In the same way as it handles in Hybrid mail flow if you followed our recommendation stated on “Setting Exchange Online as smarthost” section. If you had a Hybrid Exchange on-premises and are moving to a standalone Edge Transport, our advice is to keep the same public IP used by your previous Exchange Server on the new Edge Transport since this IP will have a sending history and clean reputation.

Can we deploy a standalone Edge Transport as an Azure VM?
You can but consider that outbound SMTP on Azure VMs is only supported if you have Enterprise Agreement or Microsoft Customer Agreement for enterprise (MCA-E) subscriptions. For more information see this article. Additionally, you may need to establish proper network connectivity from your applications to the Azure VM. This typically requires configuring network routing – such as Azure ExpressRoute – to enable your on-premises traffic to reach the Edge Transport VM securely and reliably.

Edge Transport is configured to use Exchange Online as smarthost but emails are being received as “AuthAs:Anonymous”. Can we change this behavior marking messages as Internal?
The Edge Transport role does not perform header promotion regardless if Edge is subscribed to a Mailbox Exchange Server or standalone. It is up to the Mailbox role to promote Organization headers to CrossPremises and then the Edge just honors the promotion. Refer to this article to find more information about header promotion. The only way to enforce “AuthAs:Internal” on messages coming from an Edge Transport is enabling TreatMessagesAsInternal attribute on Exchange Online Inbound connector. This option works only if sender domain matches an accepted domain in Exchange Online.

Thanks to Arindam Thokder for his support and review of this article.

Denis Vilaça Signorelli
Cloud Solution Architect

Writeback for Cloud-Managed Remote Mailboxes: Now in Public Preview

The_Exchange_Team — Fri, 15 May 2026 17:37:57 GMT

In our previous posts, we announced the Public Preview and the General Availability of Cloud-Managed Remote Mailboxes – a key step toward retiring the 'last Exchange Server' in your organization. The response from the community has been incredible, and your feedback continues to shape the roadmap.

Today, we're excited to share two new milestones in this journey:

Writeback for Cloud-Managed Remote Mailboxes is now in Public Preview.
For customers with no remaining dependency on their last Exchange Server, a guide for decommissioning your last Exchange Server is now published on Microsoft Learn.

Writeback for Cloud-Managed Remote Mailboxes: Public Preview

When you set IsExchangeCloudManaged to True on a directory-synchronized mailbox, the Exchange-attribute Source of Authority (SOA) transfers to Exchange Online. The SOA for identity attributes (name, department, and so on) stays on-premises in Active Directory, but the Exchange-related attributes (proxy addresses, hide-from-address-book, custom attributes, and similar) become editable in the cloud.

Until now, after transferring Exchange-attribute SOA to cloud those Exchange attributes were edited cloud-side only – they didn't flow back to on-premises AD. That gap was a problem for organizations whose on-premises line-of-business applications still read attributes like proxyAddresses, custom attributes, and similar directly from AD. Once SOA flipped to the cloud, the on-premises AD copy of these attributes would start drifting out of sync with the cloud.

Writeback closes that gap. With writeback enabled, changes made in Exchange Online to designated Exchange attributes are automatically pushed back to on-premises Active Directory through Microsoft Entra Cloud Sync. Your on-premises AD stays current, and your line-of-business applications keep working – even after the Exchange-attribute SOA has moved to the cloud.

How it works

Writeback uses Microsoft Entra Cloud Sync as the transport from Exchange Online back to on-premises AD. If you already use Microsoft Entra Connect Sync, you do not need to uninstall or replace it. Cloud Sync runs alongside Connect Sync – Connect Sync continues to handle your directory synchronization exactly as before, and Cloud Sync only handles the Exchange attribute writeback. There is no impact on your existing mailboxes, users, or sync configuration.

Steps to install the Cloud Sync provisioning agent, configure the writeback synchronization job, and verify the round-trip flow are all in the documentation: Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments.

Public Preview limits and GA timeline

During Public Preview, writeback supports tenants with fewer than 200,000 cloud-managed mailboxes. We will raise this limit at General Availability, currently targeted for the end of June 2026.

The complete list of attributes supported for writeback – which attributes flow back to AD and which don't – is available in Identity, Exchange Attributes and Writeback.

New Documentation: Decommission the Last Exchange Server

Once your mailboxes are cloud-managed (and writeback is in place if your applications need it), the next question is the one this whole effort has been about: how do you actually retire the last Exchange Server?

We've published a new end-to-end guide that walks through exactly that: Decommission the last Exchange Server after transferring SOA to cloud.

The guide covers:

Prerequisites – confirming all mailboxes and public folders have moved to Exchange Online, all directory-synchronized mailboxes are cloud-managed, DNS and mail routing point at Exchange Online, and you've migrated any SMTP relay dependencies.
Pre-removal verification – re-verifying each prerequisite immediately before starting, since the environment may have drifted.
Hybrid cleanup (while Exchange is still running) – removing the Hybrid Configuration object, HCW-created intra-organization connector, hybrid connectors, organization relationship, federation trust and certificate, OAuth service principal credentials, and the Hybrid Agent (modern hybrid only).
Uninstall the last Exchange Server – final pre-uninstall checks and running Setup /m:Uninstall.
Hybrid cleanup in Exchange Online (post-uninstall) – removing orphaned hybrid objects from the cloud side that the on-prem uninstall doesn't clean up.

If you've been holding off on removing your last Exchange Server because the procedure wasn't clearly documented end-to-end, this is the article you've been waiting for.

Get started

If you've been waiting for Writeback Public Preview to start your decommissioning journey, now is the time:

Review the updated documentation for the writeback setup walkthrough and the full attribute list.
Read the new decommissioning guide for the end-to-end uninstall procedure.
In case the limit of 200k for Writeback feature blocks your adoption, please reach out to us through this form. As communicated, we will increasing the limit by GA timeframe, but it would be good to know what scale would unblock you.
Share your experiences and suggestions in the comments below – your feedback shaped the previous releases, and we want it for this one too.

The era of maintaining an Exchange server "just because we sync our AD" is coming to an end.

Exchange Online Management and Exchange Hybrid teams

Addressing Exchange Server May 2026 vulnerability CVE-2026-42897

The_Exchange_Team — Tue, 14 Jul 2026 17:29:12 GMT

UPDATE July 14, 2026: Please see our release blog post for July 2026 Security Update, which, once installed, removes our recommendation to keep CVE-2026-42897 mitigation in place: Released: July 2026 Exchange Server Security Updates | Microsoft Community Hub

On May 14, 2026, Microsoft disclosed CVE-2026-42897, a reported vulnerability affecting Exchange Outlook Web Access (OWA). An attacker could exploit this issue by sending a specially crafted email to a user. If the user opens the email in Outlook Web Access and certain interaction conditions are met, arbitrary JavaScript can be executed in the browser context.

The following on-premises Exchange Server versions are impacted:

Exchange Server 2016 (any update level)
Exchange Server 2019 (any update level)
Exchange Server Subscription Edition (SE) (any update level)

Exchange Online is not impacted by this vulnerability.

Mitigations

Option 1 (recommended): Exchange Emergency Mitigation (EM) Service

For customers who have the Exchange EM Service enabled, Microsoft released the automatic mitigation for Exchange Server 2016, 2019 and SE. The mitigation is already published and is enabled automatically.

As a reminder – EM Service was released in September 2021 and is enabled by default. More information on this service can be found in Exchange Emergency Mitigation Service (Exchange EM Service) | Microsoft Learn.

Customers with EM Service enabled can verify that their servers have applied the mitigation for CVE-2026-42897 (the ID of mitigation is M2.1.x) by doing the following:

Follow the steps outlined in the documentation: Viewing Applied Mitigations.
To quickly check the status of EM Service and applied mitigations in your organization, you can run Exchange Health Checker script: https://aka.ms/ExchangeHealthChecker. The HTML report will include a section on EEMS check results.

Using EM Service is the best way for your organization to mitigate this vulnerability right away. If you have EM Service currently disabled, we recommend you enable it right away.

Please note that EM Service will not be able to check for new mitigations if your server is running Exchange Server version older than March 2023 as per this article. To check the exact version of Exchange currently in use, utilize Option 1 or Option 2 mentioned on this page: Exchange Server build numbers and release dates | Microsoft Learn.

Option 2: Scripted application of mitigation

For customers who are unable to use the EM Service (for example, disconnected or air-gapped environments), we are providing the following process to enable this mitigation:

Download the latest version of the Exchange on-premises Mitigation Tool (EOMT) from:

https://aka.ms/UnifiedEOMT

Apply the mitigation on a per server base or on all servers at once by running the script via an elevated Exchange Management Shell (EMS):

Single server:

.\EOMT.ps1 -CVE "CVE-2026-42897"

All servers:

Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Please note that mitigations do not work if the client that is used to access OWA is Internet Explorer or Microsoft Edge using Internet Explorer Mode. Internet Explorer does not support Content Security Policy (CSP).

Known issues when mitigation is applied

We are aware of following known issues once CVE-2026-42897 mitigation is applied (using either option above):

OWA Print Calendar functionality might not work. As a workaround copy the data or screenshot the calendar you want to print or use Outlook Desktop client.
Inline images might not display correctly in the recipients OWA reading pane. As a workaround, send images as email attachments or use Outlook Desktop client.
OWA light (OWA URL ending in /?layout=light) does not work properly. Please note that this feature has been deprecated several years ago and is not intended for regular production use. OWA light is going to be permanently disabled in next several months. Please see Upcoming retirement of OWA Light in Exchange Server | Microsoft Community Hub.
OWACalendar.Proxy healthset might start showing unhealthy once the mitigation is in effect. This can cause alerts if you use various monitoring solutions for your Exchange Server. If you see this problem, we recommend ignoring those alerts within your monitoring platform until the fix is out and mitigation is removed.
Published calendars might not work with error 500.
We are aware of the mitigation showing the "Mitigation invalid for this exchange version." in mitigation details. This issue is cosmetic and the mitigation DOES apply successfully if the status is shown as "Applied". We are investigating on how to address this.

Addressing the vulnerability permanently

Microsoft is working on and will release and announce a security update for impacted versions of Exchange Server in the future. Please read more about the update released: Released: June 2026 Exchange Server Security Updates | Microsoft Community Hub.

Please note that Exchange SE update will be released as a publicly available security update. Exchange 2016 and 2019 updates will be released only to customers who are enrolled in the Period 2 Exchange Server ESU program as per Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program. Period 1 only ESU customers will not receive this update as that ESU program ended in April 2026.

Updates to this blog post:

7/8/2026: Added a note about upcoming permanent disablement of OWA light Upcoming retirement of OWA Light in Exchange Server | Microsoft Community Hub
6/9/2026: Update to reflect Released: June 2026 Exchange Server Security Updates | Microsoft Community Hub
5/20/2026: Added a published calendars known issue.
5/18/2026: Added a note that mitigations do not protect Internet Explorer or Microsoft Edge with Internet Explorer mode clients.
5/17/2026: Added a known issue with OWACalendar.Proxy healthset showing unhelathy (impact if using Exchange Server monitoring).
5/14/2026: Added a known issue with OWA Light.
5/14/2026: Added the mitigation ID (M2.1.x).
5/14/2026: Added a known issue with mitigation details displaying incorrect Description.

The Exchange Server Team

No Exchange Server Security Updates for May 2026

The_Exchange_Team — Thu, 14 May 2026 17:07:44 GMT

We wanted to let the Exchange Server community know that there are no security releases for any version of Exchange Server in May 2026, for customers with Exchange SE, or Exchange 2016 or 2019 ESU.

Please keep upgrading your organizations to Exchange SE.

Update 5/14/2026: While there is no security release (Security Update) in May 2026, please see our later blog post mentioning a mitigation for an Exchange Server CVE disclosed on May 14: Addressing Exchange Server May 2026 vulnerability CVE-2026-42897 | Microsoft Community Hub

The Exchange Team

Retirement of Direct Exchange ActiveSync Certificate-Based Authentication by End of 2026

The_Exchange_Team — Fri, 08 May 2026 17:40:11 GMT

We are announcing the deprecation of Exchange ActiveSync (EAS) certificate-based authentication (CBA) directly to Exchange Online. By the end of 2026, Microsoft will no longer support direct CBA connections from EAS mobile email clients to Exchange Online. After that date, any EAS clients using CBA will need to authenticate via Microsoft Entra ID rather than sending client certificates directly to Exchange Online.

With immediate effect, we will roll out blocks so no new tenants can use the legacy flow, ensuring they can take advantage of the benefits of using the Entra ID flow from the very start.

Important: This change does not affect other Exchange Online authentication scenarios such as Outlook Mobile or Exchange Server/on-premises. It is specific to Exchange ActiveSync (EAS) clients (such as native built-in mobile email apps) using CBA against Exchange Online. This retirement is part of our ongoing efforts to strengthen security by eliminating legacy auth patterns in Exchange Online.

Why Are We Retiring Direct EAS CBA?

Certificate-based authentication for EAS was introduced as a way for organizations to allow mobile device access without passwords, using client certificates for a highly secure, passwordless sign-in experience. With CBA, each user has a certificate verified by the tenant's root certificate authority, and the user can authenticate via a TLS handshake using the public key of that certificate – meaning no private key or password is ever sent over the network, providing a more secure alternative to basic authentication. The previously published guidance for this config is here.

However, the current direct-to-Exchange implementation of EAS CBA is considered a legacy authentication method. In the present flow, user certificates are pushed to mobile devices during configuration. When users connect to EAS to sync email, Exchange receives the certificate and does all the onward processing and validation itself.

This design presents a significant concern as the client itself never obtains a standard OAuth access token – a departure from modern authentication practices – and Exchange relies on this internal, high-privilege mechanism to access data. Furthermore, Azure AD classifies direct certificate-based authentication between the client and Exchange Online as a form of "legacy authentication," meaning it will be blocked by any Azure AD conditional access policies that block legacy authentication. This creates an all-or-nothing challenge for administrators trying to enforce modern security controls while still allowing CBA.

The new model requires EAS clients to perform certificate-based authentication directly via Microsoft Entra ID, just as other client apps do. The proposed secure flow works as follows: the client sends its certificate to Entra ID (Azure AD) for validation; Entra ID validates the certificate and returns an OAuth access token to the client; the client then presents this OAuth token to Exchange Online for authentication. By moving certificate authentication fully into Microsoft Entra ID, admins can uniformly enforce modern security controls and policies for all client access, with no exceptions for certain protocols.

This change also continues our ongoing effort to modernize Exchange Online authentication stack. Over the past few years, we have phased out older authentication methods like Basic Auth, and we recently introduced dedicated ActiveSync CBA endpoints – such as outlook-cba.office365.com for worldwide multi-tenant, outlook-dod-cba.office365.us for DoD, and outlook-cba.office365.us for GCC-High – to support TLS 1.3 and strengthen security and reliability. Requiring Entra-based CBA is the next logical step in this journey, closing one of the last remaining gaps in legacy auth removal.

How do I know if I am Impacted?

If you aren’t sure if you use Exchange ActiveSync CBA or Entra-Based CBA, there’s a couple of ways you can figure that out.

Firstly, ask the person who manages your Mobile Device Management (MDM) configuration. If the auth type used is set as Certificate, rather than OAuth, that could indicate you use this configuration.

The other method is to check Entra’s sign-in event logs. Requests using Exchange CBA show up with the client app of ‘Exchange ActiveSync’, and Authentication Details will show a certificate is being used. Here’s how that flow looks in Entra’s sign-in logs reports:

"Certificate” would be shown as Authentication method:

We will send Message Center posts to tenants using Exchange CBA in the next week calling attention to this change. We’ll update this post once those posts have been sent.

Please note that CBA authentication is something that you must configure deliberately and if your organization never configured it, this deprecation does not impact you.

How to Migrate to Entra-Based CBA

We understand that some organizations have been relying on CBA with Exchange ActiveSync to enhance mobile device security. To ensure a smooth transition, we recommend administrators start planning now to move those devices to the new Entra ID-based CBA method well before the end-of-2026 deadline. The PKI and CA setup for Entra CBA and EAS CBA are fundamentally the same, which should simplify the transition. Below are key steps and considerations for a successful migration:

Enable Microsoft Entra CBA for your Tenant: Ensure your certificate authorities (CA) are configured in Microsoft Entra ID. At least one CA and any intermediate CAs must be configured, each user needs access to a certificate issued from a trusted PKI, and each CA should have a certificate revocation list (CRL) referenceable from an internet-facing URL. Microsoft provides detailed guidance on setting up Entra CBA in documentation.
Prepare User Certificates: Verify that each user's client certificate contains the correct identity information. For Exchange ActiveSync clients specifically, the certificate must include the user's routable email address in Exchange Online, in either the Principal Name or the RFC822 Name value of the Subject Alternative Name (SAN) field. Microsoft Entra ID maps the RFC822 value to the Proxy Address attribute in the directory. More info here. If your current certificates were used for direct EAS CBA, they likely already meet this requirement – just verify the presence of the user's email in the certificate's SAN.
Update Device Configuration: Plan how your mobile devices will perform certificate authentication against Entra ID. In many cases, this may involve updating the device's email profile or MDM/Intune device configuration profiles. The new flow might require collaboration with third-party client vendors to support the change. Consult your mobile device or mail app vendor for specific instructions on enabling Entra (Azure AD) authentication with client certificates. When the feature is configured, users will see a certificate selection prompt during sign-in rather than entering a password.
Test and Monitor: We recommend testing the new Entra CBA login flow with a pilot group of devices and users before broad rollout. Monitor your Entra ID sign-in logs and Exchange ActiveSync device reports to identify any remaining devices using the legacy CBA method. Proactively reach out to users still on the old method and assist them in moving to the updated configuration.
Deprecation Timeline: Keep the end-of-2026 deadline in mind for planning. We suggest completing the transition well in advance of this date to avoid any service disruption. In the interim, we will share more details through the Message Center to directly impacted tenants, and update documentation as needed to support your migration.

Conclusion

We strongly encourage any customer still using direct Exchange ActiveSync CBA to begin planning the move to Entra-based CBA now. The Microsoft Entra method offers equal or better security – it's certificate-based, phishing-resistant, and passwordless, but with far better integration into our modern authentication ecosystem and security controls. This change will help protect your organization's data by ensuring all Exchange Online connections follow the most up-to-date security standards, and it eliminates the reliance on internal high-privilege tokens that carry unnecessary elevated rights.

We understand that making changes to your authentication infrastructure can be challenging, which is why we've set a long runway until the end of 2026 for this transition. We'll continue to provide guidance and support throughout this period. Thank you for your cooperation in adopting these security improvements – together, we can ensure a safer, more secure Exchange Online experience for all our customers. If you have any questions or need assistance with setting up Entra CBA, please reach out to Microsoft Support (Entra / Identity) or your account team. We're here to help make this transition as smooth as possible.

The Exchange Online Team

General Availability of Mailbox Import and Export Microsoft Graph APIs

Nino_Bilic — Fri, 08 May 2026 14:21:17 GMT

As a part of our continuing march to Exchange Web Service (EWS) deprecation in Exchange Online (see Exchange Online EWS, Your Time is Almost Up | Microsoft Community Hub) - the Microsoft Graph Team announced another milestone in enabling developers to efficiently manage, migrate, and integrate mailbox data in Exchange Online through Microsoft Graph:

Announcing general availability of the mailbox import and export Microsoft Graph APIs - Microsoft 365 Developer Blog

If you develop applications that access mailbox data, you might be very interested in that. Please see the post for more details on current scope and production expectations.

Nino Bilic

Update Your Exchange SE Hybrid On-premises Rich Coexistence to Graph

The_Exchange_Team — Fri, 08 May 2026 14:36:18 GMT

About a year ago, we announced Exchange Server Security Changes for Hybrid Deployments. This change impacted Exchange hybrid customers who host some of their mailboxes on-premises and their on-premises users need access to “rich coexistence” features (Free/Busy lookups, MailTips and profile picture sharing with Exchange Online users).

This change was planned in two stages:

Stage 1: transitioning to dedicated Exchange hybrid application. Completed in October 2025. Exchange hybrid customers who host mailboxes on-premises now must create the dedicated Exchange hybrid application to maintain rich coexistence features for their on-premises users.
Stage 2: deprecation of EWS calls and switch to REST-based Microsoft Graph API calls for Exchange hybrid. This is the stage that we are in now. Please note that not all rich coexistence scenarios are fully supported yet and not every cloud environment might support Graph API hybrid calls yet (please see documentation).

Deprecation of Exchange Web Services (EWS) in Exchange Online is nearing final stages – see Exchange Online EWS, Your Time is Almost Up. Because of this, all customers who require rich coexistence (even those who already finalized Stage 1) will need to install an Exchange Subscription Edition (SE) update on premises and switch the dedicated Exchange hybrid app permissions to a more granular Graph API permission model. This must be done before October 2026 (as we will turn off EWS by default then) with the latest date of April 2027 (when we will permanently turn off EWS in Exchange Online).

The following illustration shows the timeline of hybrid security improvements, Stage 2:

Exchange Hybrid customers who want to start using Graph API in hybrid workflow should:

Step 1 – install the May 2026 Hotfix Update for Exchange SE (or newer) on your on-premises Exchange SE servers:

Released: May 2026 Exchange Server Hotfix Update

Step 2 – once all your on-premises Exchange SE servers have the update installed, follow the steps as outlined in the documentation to enable the Graph API hybrid workflow for supported scenarios. Note that if you ran the script in the past, you need to re-run it again after installing the new update to activate new functionality.

Note: Exchange 2016 and 2019 are out of support. We are not releasing an update for those versions to use Graph API hybrid calls (even updates released under Exchange 2016 or 2019 ESU will not contain this functionality). Customers who are still using Exchange 2016 or 2019 servers to host mailboxes on premises will have to keep allowing EWS use in their tenant past October 2026 and must upgrade all servers to Exchange SE by April 2027 (when EWS is disabled in Exchange Online). Rich coexistence features on those unsupported versions will permanently stop working in April 2027. Please upgrade your on-premises environments from unsupported versions ASAP. By running unsupported versions, you might be putting your environment at risk!

The FAQ related to creation and use of dedicated hybrid app can be found in feature documentation.

Updates to this post:

5/8/2026: Clarified that the script needs to be re-run to enable new functionality (Step 2 above) even if it was ran in the past already.

The Exchange Team

Released: May 2026 Exchange Server Hotfix Update

The_Exchange_Team — Fri, 08 May 2026 20:31:09 GMT

Microsoft has released Hotfix Update (HU) for:

Exchange Server Subscription Edition (SE)

HU is available for the following specific version of Exchange Server:

Exchange SE RTM

The May 2026 HU does not contain any new Exchange Server security updates but contains new functionality. Please see the release KB article for more information.

Updating your Exchange rich hybrid coexistence to Graph API calls

May 2026 hotfix update contains functionality that will allow you to start switching your Exchange Server hybrid rich coexistence from using Exchange Web Services (EWS) to REST-based Microsoft Graph API calls. This is a continuation of work we announced in Exchange Server Security Changes for Hybrid Deployments.

More information can be found in Update Your Exchange SE Hybrid On-premises Rich Coexistence to Graph and Deploy dedicated Exchange hybrid app.

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 Fix failed Exchange Server updates. Also please see File version error when you try to install Exchange Server updates.

Hotfix Update FAQs

Why did Microsoft decide to release this HU at the start of the month? Is this urgent?
Hotfix releases are not tied to the “patch Tuesday” release schedule as they do not contain security updates. Exchange Hotfix Updates are optional.

We installed the last Security Update. Should we install the later Hotfix Update?
Exchange Server HUs are optional updates, but they might introduce features or fixes that your organization can benefit from. Please see the release KB article for more details.

We did not yet install the earlier Security Update. Do we have to install the last available SU first before installing the later HU?
All of Exchange updates (HUs or SUs) are cumulative. Therefore, a newer SU or HU will contain all the changes that a previous, older SU or HU has. If you have not installed the older updates yet, you can install the newer one directly and skip the older one.

Our Exchange servers update automatically through Windows / Microsoft Update. Will our servers automatically install the HU update?
This HU is an optional update for your servers and the update will be shown as an optional update on Windows / Microsoft update a few days after general release on Download Center.

Will the new features and fixes released in the HU also be rolled into future updates, or must we install this specific HU to get them?
Content of this HU will be included in subsequent updates for Exchange Server SE.

Can HUs be uninstalled (if the need arises)?
Yes. HUs, like SUs, can be uninstalled.

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

Updates to this post:

5/8/2026: Updated the FAQ related to Windows / Microsoft Update availability

The Exchange Server Team

Deprecating Legacy TLS and Endpoints for POP and IMAP in Exchange Online

The_Exchange_Team — Mon, 27 Apr 2026 19:03:29 GMT

Security on the internet continues to evolve, and older cryptographic protocols no longer provide the protections required for today’s threat landscape. As part of our ongoing work to help customers keep their email environments secure, we’re taking another step in modernizing Exchange Online connectivity.

What’s changing

We’re planning to fully deprecate support for legacy TLS versions (TLS 1.0 and TLS 1.1) for POP3 and IMAP4 connections to Exchange Online. These older TLS versions have been industry‑deprecated for some time and are no longer considered secure.

Modern email clients and libraries already support TLS 1.2 or higher, and the vast majority of POP and IMAP traffic to Exchange Online today uses these newer protocols.

Several years ago we started the move to block these older versions, but we did allow you to use them by opting-in, we’re now removing support for them entirely. Our expectation is that only customers who have explicitly opted into using those legacy endpoints are impacted by the deprecation we are announcing today.

What customers should do

If you’re using POP or IMAP with Exchange Online, ensure that:

Your email clients, applications, and libraries support TLS 1.2 or later and are not using legacy endpoints to connect to our service.
Any custom or embedded applications (such as devices or legacy services) are updated accordingly.

If you aren’t sure if you are using legacy versions, check the configuration of your POP and IMAP clients and if you are, your application or device vendor can typically confirm TLS support and provide upgrade guidance.

What’s next

We will start to block legacy version connections starting in July 2026.

As always, our goal is to make these transitions predictable and well‑communicated, while continuing to strengthen security across Microsoft 365.

The Exchange Team

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