EDIT 2/4/2026: We’ve been notified that some email providers may distrust the DigiCert G1 root on April 15, which could result in broad ecosystem‑wide email impact. To ensure Exchange Online can rotate certificates ahead of this event, our customers must trust the DigiCert Global Root G2 certificate authority by March 15, 2026 (previously April 30).
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 15, 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.It’s recommended to also validate the Intermediate CA certificate. You can use the following PowerShell command to validate if the Intermediate CA certificate (DigiCert Global G2 TLS RSA SHA256 2020 CA1) is trusted:
Get-ChildItem -Path Cert:\LocalMachine\CA\ | Where-Object { $_.Thumbprint -eq "1B511ABEAD59C6CE207077C0BF0E0043B1382612" }
If no result is returned, and you do not want to re-enable the Windows CTL Updater feature you must act by following one of the next options (either option 1 or 2):
Option 1 - 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:
- 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 Command Prompt and execute the following command. Ensure that you update the path and file name to correspond to the actual .p7b bundle you have obtained:
certutil -addstore Root "C:\path\to\m365_root_certs.p7b"
Confirm the import worked by running the command mentioned in step 1 above.
Option 2 - manually download and import the DigiCert Global Root G2 and Intermediate CA certificates
There is a subset of our customers who don't use the Windows CTL Updater feature and instead manage their trusted and untrusted root and intermediate certificates by using their own management solution (e.g., Group Policy).
If your organization manages a certificate package and you only need to include the DigiCert Global Root G2 certificate along with its subordinate authority chains, you can download them from the Azure Certificate Authority details documentation.
To import a root certificate from a .crt file, run this command in an elevated Command Prompt:
certutil -addstore Root "C:\path\to\DigiCertGlobalRootG2.crt"
To import an intermediate certificate from a .crt file, run this command in an elevated Command Prompt:
certutil -addstore CA "C:\path\to\DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt"
Use the PowerShell commands from the previous section to validate that the Root CA and Intermediate CA certificates were successfully imported.
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 15, 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 15, 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/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
