To avoid mail flow disruption between your organization and Exchange Online, organizations that send or receive email to or from Exchange Online must ensure that their servers and clients trust the DigiCert Global Root G2 Certificate Authority and its subordinate CAs before April 30, 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 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.If no result is returned, you must act:
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.
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 April 30, 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 April 30, 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.
Microsoft 365 Messaging Team
