Microsoft has issued an important alert for organizations that send or receive email through Exchange Online over SMTP. If the systems involved do not trust the DigiCert Global Root G2 root certificate and its subordinate certificate authorities, secure mail flow can fail once older trust paths are no longer accepted.
This matters because Exchange Online relies on TLS certificates that chain back to DigiCert Global Root G2. If a server, gateway, appliance, or application cannot validate that trust chain, it may reject secure SMTP connections, which can interrupt inbound or outbound email delivery.
Reading our article? Try our product:
What the issue is
Microsoft uses intermediate certificate authorities under DigiCert Global Root G2 to sign TLS certificates for services such as Exchange Online. For TLS validation to succeed, the connecting system must trust the DigiCert Global Root G2 root certificate and be able to validate the intermediate certificates in the chain.
If that trust is missing, SMTP connections may fail during TLS negotiation. Microsoft notes that affected systems may refuse to send mail, fail to accept inbound connections, or in some cases fall back to unencrypted SMTP if their configuration allows it.
Who needs to pay attention
Most organizations running mail workloads on Windows will not need to take action. Microsoft says Windows updates certificate trust automatically by default through the CTL updater, so customers that have not disabled that feature are generally already covered.
The higher-risk group includes organizations that have disabled the Windows CTL updater, maintain their own root and intermediate trust stores, or rely on legacy Java runtimes, embedded systems, outdated Linux images, air-gapped environments, security appliances, or third-party email gateways for SMTP connectivity with Exchange Online.
Microsoft’s current deadline is March 22, 2026. The company also updated its guidance on March 16, 2026, after republishing the Microsoft 365 root certificate chain bundles because the earlier published bundles were missing an intermediate certificate.
That means any organization that previously downloaded the bundle and needed to install it manually must download the updated version again and repeat the certificate trust steps. Microsoft warns that failing to trust the updated DigiCert Global Root G2 chain and intermediates may cause email disruption after the deadline.
What needs to be done
The first step is to verify whether the DigiCert Global Root G2 certificate is already trusted on the affected machine. Microsoft identifies the required root certificate with SHA1 thumbprint DF3C24F9BFD666761B268073FE06D1CC8D4F82A4.
On Windows, Microsoft recommends checking for the certificate with this PowerShell command:
Get-ChildItem -Path Cert:\LocalMachine\Root\ | Where-Object { $_.Thumbprint -eq "DF3C24F9BFD666761B268073FE06D1CC8D4F82A4" }If the output shows the thumbprint and subject, you should be good and no further actions are required:
If the certificate is present, no further action is generally required on that machine. If it is missing and you do not plan to re-enable the Windows CTL updater, Microsoft says you should manually download the latest Microsoft 365 root certificate chain bundle and import the certificates into the correct certificate stores.
Microsoft’s recommended remediation
Microsoft provides Microsoft 365 root certificate chain bundles in .p7b format for Worldwide and for GCC High/DoD environments. After downloading the latest bundle, administrators should import root certificates into the LocalMachine\Root store and intermediate certificates into the LocalMachine\CA store.
Microsoft shared the following PowerShell example for that import process:
$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"
}After import, Microsoft says administrators should validate again that the required root is trusted. This is especially important for organizations using manually managed trust stores or appliances that do not inherit Windows’ normal automatic trust updates.
What failure can look like
If the issue is not addressed, administrators may see SMTP or TLS-related failures when Exchange Online tries to connect to on-premises systems, or when on-premises systems try to connect to Exchange Online. Microsoft gives examples such as 451 5.7.3 STARTTLS is required and OpenSSL errors indicating the local issuer certificate cannot be retrieved or trusted.
In practice, that can mean delayed messages, rejected messages, or failed secure mail delivery between Microsoft 365 and on-premises or third-party email infrastructure.
Call to action
Organizations should identify every system involved in SMTP mail flow with Exchange Online, including on-premises Exchange servers, Linux-based gateways, secure mail appliances, and third-party email security products. They should then verify trust for DigiCert Global Root G2, re-download the updated March 16 bundle if manual installation is required, complete certificate imports where needed, and test SMTP/TLS connectivity before March 22, 2026.
For third-party email gateways or appliances, Microsoft specifically advises contacting the vendor directly for support. That is important because some products use their own certificate stores and may need vendor-specific update steps.
Fortify Your Server with Messageware Security
Data breaches have increased by 72%, servers are compromised in under 90 minutes. Ensure you have multiple layers of security software protecting your Windows Servers.
Server Threat Guard (STG) for All Windows Servers: Next-gen server protection, providing detection, alerting, and response (MDR) to zero-day and server penetration cyber-attacks. No need to research complicated deployments and no learning curve to install and manage.
EPG Guard for Exchange Servers: Real-time security. Stop AD account lockouts, eliminate password attacks, intelligent GEO blocking, and prevent Exchange Server vulnerability probing.
Don’t leave your critical infrastructure vulnerable, be proactive and stay ahead of evolving threats.