UPDATE 3/16/2026: We worked with the partner team to republish the Microsoft 365 Root Certificate Chain Bundles for Worldwide (WWMT) and GCC High / DoD (ITAR) after identifying that the previously published bundles were missing the intermediate certificate. If your organization needed to install the certificate bundle, you must re-download the updated bundle (released on 3/16) to get the new intermediate certificate and complete the certificate trust steps again as soon as possible (by March 22, 2026). Failure to trust the updated DigiCert Global Root G2 chain and its intermediates may result in mail flow disruption once providers begin distrusting the DigiCert G1 root.
To avoid mail flow disruption between your organization and Exchange Online, organizations that send or receive email to or from Exchange Online over SMTP must ensure that their servers and clients trust the DigiCert Global Root G2 Certificate Authority and its subordinate CAs before March 22, 2026.
You can find a comprehensive list of the root and subordinate certificate authority chain in the Azure Certificate Authority Details documentation and in the DigiCert Knowledge Base.
The following information can help you identify the DigiCert Global Root G2 Certificate:
SHA1 Thumbprint:
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
Serial Number:
03:3A:F1:E6:A7:11:A9:A0:BB:28:64:B1:1D:09:FA:E5
Who needs to take action
NOTE: Windows operating system handles updating certificate trusts automatically by default. Customers running email workloads on Windows (e.g. on-premises Exchange Server) who never disabled this Windows feature do not need to take any action.
However, if your organization sends or receives email to or from Exchange Online over SMTP and meets either of the following two criteria, you may need to complete the installation steps in “What you must do”:
1. Your organization has disabled the Windows CTL Updater feature that by default downloads the Certificate Trust List (CTL), which contains trusted and untrusted root certificates. This could be the case if your organizations maintain their own set of trusted Root and Intermediate Certificates via Group Policy or via redirected Microsoft Automatic Update URL.
You can check the last sync state for the trusted and untrusted root certificates by running the following commands from Windows Command prompt (note that running these commands will trigger an on-demand synchronization of the Microsoft trusted root list, if the feature is not explicitly disabled and if Windows determines that the local AuthRoot CTL is stale or incomplete):
certutil -verifyctl AuthRoot | findstr /i "lastsynctime"
certutil -verifyctl Disallowed | findstr /i "lastsynctime"
If the time returned is recent – Windows CTL Updater feature is working. Most of our customers do not disable this.
2. You use older application runtime environments like legacy Java runtimes (e.g., legacy JDK/JRE versions), embedded systems and appliances, custom or outdated Linux images or air-gapped environments to connect or receive email from Exchange Online.
This change applies to any system performing full certificate chain validation against Exchange Online, including Exchange Server, security appliances, and third-party email gateways. If you use third-party email appliances, please contact the vendor directly for support.
Why this matters
Root Certificate Authorities (CAs) form the foundation of public certificate trust, as operating systems, browsers, and applications rely on their root certificates in trust stores. CAs use these root certificates to issue Intermediate CA certificates, which then issue TLS and other digital certificates.
If a Root CA certificate becomes invalid or untrusted, all certificates issued by its Intermediates lose trust as well. That also implies that if a Root CA is not explicitly trusted, then the certificates issued by its Intermediate CAs are not valid either.
Microsoft uses multiple intermediate certificate authorities that are issued by the DigiCert Global Root G2 root certificate authority to sign TLS certificates for its services (e.g., Exchange Online). For this trust chain to work, the DigiCert Global Root G2 root certificate must be present and trusted in the client’s trust store; otherwise, TLS connections will fail.
If the DigiCert Global Root G2 root certificate is not installed or if the client cannot obtain the intermediate CA certificate from the server during the TLS handshake or retrieve it via the Authority Information Access (AIA) extension, you may see:
- The client may refuse to send email if strict certificate verification is enabled, or it may fall back to unencrypted SMTP if allowed
- The client may refuse to accept incoming connections from Exchange Online, resulting in failed or delayed email retrieval
If the email client cannot trust the server, a secure communication is blocked.
What you must do
Check to see whether your machines have the DigiCert Global Root G2 certificate installed
You can use the following PowerShell command to validate if the DigiCert root certificate is trusted:
Get-ChildItem -Path Cert:\LocalMachine\Root\ | Where-Object { $_.Thumbprint -eq "DF3C24F9BFD666761B268073FE06D1CC8D4F82A4" }
If this command returns a certificate (the output shows the thumbprint and subject), you should be good and no further actions are required:
Result indicating the required certificate is already trusted on the local Windows machine.In addition to the Root certificate, there are several related Intermediate certificates.
If no result is returned, and you do not want to re-enable the Windows CTL Updater feature you must act by doing the following:
Manually download and import the latest Microsoft 365 Root Certificate Chain bundles
Microsoft supplies a collection of root certificates that are required to be trusted, as their associated Intermediate Certificate Authorities issue certificates essential for Microsoft 365 services.
You can download the certificate bundles (.p7b / PKCS #7 file format) from here (use the latest download):
- Microsoft 365 Root Certificate Chain Bundle – Worldwide
- Microsoft 365 operated by 21Vianet customers should use the Worldwide bundle
- Microsoft 365 Certificate Bundle - DoD/GCC High
After downloading, open an elevated PowerShell window and execute the following command. Ensure that you update the path and file name to correspond to the actual .p7b bundle you have obtained:
$p7bPath = "C:\path\to\m365_root_certs_20260316.p7b"
$certCollection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$certCollection.Import($p7bPath)
foreach ($cert in $certCollection) {
$storeName = if ($cert.Subject -eq $cert.Issuer) { "Root" } else { "CA" }
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store($storeName, "LocalMachine")
$store.Open("ReadWrite")
$store.Add($cert)
$store.Close()
Write-Host "Imported: $($cert.Subject) to store: LocalMachine\$storeName"
}Confirm the import worked by running the command mentioned in step 1 above.
What would the error look like, if this is not addressed?
If you don't install the DigiCert Global Root G2 root certificate and your systems rely on old root certificates for validation, your mail flow could be disrupted after March 22, 2026. The specific issues you encounter will depend on your operating system and application configuration. Here are some possible examples:
If Exchange Online can't connect to your on-premises Exchange Server, you may see the following when running a message trace in the Exchange Online Admin Center:
Reason: [{LED=450 4.4.317 Cannot establish session with remote server [Message=451 5.7.3 STARTTLS is required to send mail]How Exchange Online Message Tracking might show the error if the receiving server does not trust the certificate.
The issue could also be present if your on-premises environment tries to connect to Exchange Online. The error in your on-premises protocol log would be similar to:
451 5.7.3 STARTTLS is required, 5.7.0 Must issue a STARTTLS command first
When using OpenSSL to connect (for example, on a machine which is running a Linux operating system or an application that makes use of OpenSSL), it can’t retrieve the local issuer:
OpenSSL s_client -starttls smtp -connect <tenant>.mail.protection.outlook.com:25 -showcertsAn error that (for example) a Linux system could show if it does not trust the certificate when trying to connect to Exchange Online.
Summary
It is crucial to complete the steps outlined in this blog post before March 22, 2026. Failing to perform these updates may result in significant disruptions to your organization's mail flow with Exchange Online.
By ensuring that the necessary certificates are installed and up to date, you help maintain secure and uninterrupted communication between your systems and Microsoft 365. Please prioritize these actions to avoid any potential issues with email delivery after the deadline.
Note: our Exchange Online customers have now received a Message Center (MC) post on this, MC1224565.
Significant changes to this post:
- 3/18/2026: Added a script sample that will import appropriate certificate into the appropriate certificate store (Root vs. Intermediate)
- 3/17/2026: Removed the mention of a single older Intermediate certificate from instructions. The new Certificate bundle contains multiple Internediate certificates needed.
- 3/16/2026: Removed Option 2 (manually downloading the intermediate certificate) as the new intermediate certificate is now included in the certificate bundle.
- 3/16/2026: Latest update to timeline, now set to March 22. Mentioned that the certificate bundle was republished.
- 3/12/2026: Added a clarification in few places that this change applies to customers/systems that send email over SMTP.
- 2/23/2026: Added more detail about importing and validation of intermediate certificate.
- 2/10/2026: Added a note about intermediate certificates (this is very infrequent).
- 2/4/2026: Changed the deadline to March 15 due to speed of overall industry deprecation.
Microsoft 365 Messaging Team
