Exchange Team Blog articles

Released: June 2026 Exchange Server Security Updates

The_Exchange_Team — Tue, 09 Jun 2026 17:20:52 GMT

NOTE: Our partners in documentation publishing notified us of an issue that is causing documentation on learn.microsoft.com domain to not show latest documentation version. The issue is being worked on.

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.

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

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.

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

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.

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.

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

How to determine which Resource Mailboxes are being actively used

The_Exchange_Team — Thu, 21 May 2026 13:38:55 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 module

Import-Module Microsoft.Graph

Connect to Graph using PowerShell with a certificate

Connect-MgGraph -ClientId <App ID> -TenantId <your tenant ID> -CertificateThumbprint <cert thumbprint>

Connect to Graph using a client secret

Connect-MgGraph -ClientSecretCredential -TenantId <your tenant ID>

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, 09 Jun 2026 17:13:57 GMT

UPDATE June 9, 2026: Please see our release blog post for June 2026 Security Update for more information on this CVE: Released: June 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.
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:

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

High Volume Email reaches General Availability in Exchange Online

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

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

High Volume Email Is Now Available in Exchange Online

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

Nino Bilic

Upcoming Breaking Changes to Modifying Sensitive Email Properties via Graph API

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

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

Immutability of Received Email Messages

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

Required Permissions for Modifying Sensitive Properties

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

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

Timeline and Recommendations

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

The Exchange Team

Celebrating 30 Years of Microsoft Exchange

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

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

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

The start: email becomes enterprise messaging

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

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

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

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

Exchange shapes the market

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

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

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

The foundation of Exchange Online

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

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

Exchange Server still matters in 2026

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

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

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

Through it all, community helped shape Exchange

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

How things are changing

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

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

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

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

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

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

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

The Exchange Team

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

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

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

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

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

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

Nino Bilic

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

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

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

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

That is where this tool comes in!

If this sounds interesting, check it out here:

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

Nino Bilic