If you run an on-premises Exchange Server or any Windows-based SMTP relay that sends mail to or receives mail from Exchange Online, then you might have a hard deadline coming up: March 22, 2026.
Miss it, and you can risk breaking your mail flow, if the Root Certificates used by Exchange is not updated.
What Is Changing
Microsoft Exchange Online is switching its TLS certificates to the DigiCert Global Root G2 certificate authority.
This is part of a broader industry-wide move away from older root CAs.
For most organisations running Windows with default settings, this is a non-event — Windows handles certificate trust updates automatically via the Windows Certificate Trust List (CTL) updater. But if your environment falls into either of the following categories, you need to act manually:
- You have disabled the Windows CTL Updater (via Group Policy, a custom trust store, or redirected Microsoft Automatic Update URLs)
- You use non-Windows runtimes for SMTP connectivity — legacy Java, Linux-based mail gateways, embedded appliances, or air-gapped environments
If neither applies to you, you are almost certainly fine. But it is worth a quick check to be sure.
Who and What Is Actually Affected
The scope of this change is specifically SMTP traffic. The requirement is:
Any system that sends or receives email to or from Exchange Online over SMTP with TLS must trust the DigiCert Global Root G2 CA and its subordinate intermediate CAs before March 22, 2026.
This means the following systems are in scope:
- On-premises Exchange Server (all versions with hybrid or direct SMTP to EXO)
- Windows-based SMTP relay hosts and smart hosts
- Third-party mail gateways (Mimecast, Proofpoint, Barracuda, etc.) — contact your vendor
- Any application sending mail directly to
smtp.office365.comor similar Exchange Online endpoints over SMTP
The following are not affected by this change:
- Outlook, macOS Mail, mobile clients — these use HTTPS/MAPI/EWS, not SMTP
- Applications using the Microsoft Graph API (
/sendMail) — Graph uses HTTPS REST, not SMTP - On-premises systems that relay through an on-prem Exchange Server (only the Exchange Server itself matters)
What Breaks If You Do Nothing
If your system cannot validate the DigiCert G2 certificate chain during a TLS handshake, STARTTLS negotiation fails and the SMTP session is dropped.
In practice, you will see errors like these:
In Exchange Online message traces (inbound to your server):
450 4.4.317 Cannot establish session with remote server
[Message=451 5.7.3 STARTTLS is required to send mail]
In your on-premises protocol logs (outbound to Exchange Online):
451 5.7.3 STARTTLS is required
5.7.0 Must issue a STARTTLS command first
Both directions are affected, mail stops flowing in and out until the certificate trust is resolved.
The Two Certificates You Need
The full chain requires trusting both a root CA and an intermediate CA:
| Type | Certificate Name | SHA1 Thumbprint | Store |
|---|---|---|---|
| Root CA | DigiCert Global Root G2 | DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 | Cert:\LocalMachine\Root\ |
| Intermediate CA | DigiCert Global G2 TLS RSA SHA256 2020 CA1 | 1B511ABEAD59C6CE207077C0BF0E0043B1382612 | Cert:\LocalMachine\CA\ |
A note on the intermediate: Windows can often retrieve it dynamically during TLS handshake via the Authority Information Access (AIA) extension, but in restricted or air-gapped environments, this may not work. It is safer to install it explicitly.
Also worth noting: Microsoft republished their .p7b certificate bundle on March 16, 2026 after community members discovered the original bundle was missing the intermediate certificate. If you downloaded the bundle before that date, you need to re-download it.
How to Check Your Server
Run these two PowerShell commands on any on-premises Exchange Server or SMTP relay host (elevated session):
# Check Root CA
Get-ChildItem -Path Cert:\LocalMachine\Root\ |
Where-Object { $_.Thumbprint -eq "DF3C24F9BFD666761B268073FE06D1CC8D4F82A4" }
# Check Intermediate CA
Get-ChildItem -Path Cert:\LocalMachine\CA\ |
Where-Object { $_.Thumbprint -eq "1B511ABEAD59C6CE207077C0BF0E0043B1382612" }
If both commands return a certificate, you are good to go. If either returns nothing, you need to install the missing certificate before the deadline.
Automating the Check (and Fix)
I have published a PowerShell script Check-ExchangeRootCerts.ps1 that handles both the check and the remediation in one go:
🔗 Check-ExchangeRootCerts.ps1 on GitHub
The script:
- Checks both the root CA and intermediate CA thumbprints against the local machine certificate store
- Displays the result with a days-until-deadline countdown
- If anything is missing, prompts to download and install the certificates directly from DigiCert
- Installs each certificate into the correct store — root into
Cert:\LocalMachine\Root\and intermediate intoCert:\LocalMachine\CA\— viacertutil - Re-verifies both thumbprints after installation and confirms the result
Usage:
# Check only — no changes made (suitable for monitoring / pre-flight)
.\Check-ExchangeRootCerts.ps1 -CheckOnly
# Interactive check + remediate if missing
.\Check-ExchangeRootCerts.ps1
Requires an elevated (Administrator) PowerShell session. Run it on every on-premises Exchange Server and SMTP relay host in your environment.
Note on certutil quoting: If you are running the
certutil -addstorecommand manually, pass the file path as a plain argument without wrapping it in extra quotes when calling from PowerShell — the extra quoting causesERROR_INVALID_NAME(exit code-2147024773).