Blog · Dmarc
Why Your Exchange Server Auth Certificate Rotation Stalls and How to Fix It
Your Exchange Server auth certificate is about to expire. You have done the rotation. The new certificate is in the store. And then nothing happens. It stays in "Next" status, never promotes to "Current," and your DKIM signing breaks. Nobody sends you an alert. Your users start reporting NDRs a week later. This is a known failure mode in Exchange Server that does not get enough coverage.
How Exchange Server Auth Certificate Rotation Is Supposed to Work
Exchange Server uses an authentication certificate for two things: securing internal server-to-server communication and DKIM-signing outbound mail. This certificate expires roughly 12 months after installation. The rotation process is supposed to be automatic: Exchange detects the approaching expiration, generates a new certificate, and promotes it to replace the expiring one. When it works, you never have to touch it.
In practice, the certificate lifecycle has three states:
- Expired: the original certificate has passed its validity date and is no longer usable
- Next: the certificate is valid and available but not yet the active certificate
- Current: the certificate is actively in use for transport and DKIM signing
Automatic rotation is supposed to move the certificate from Next to Current before expiration. When it does not, the cause is almost always one of four specific problems.
The Four Most Common Causes of a Stalled Rotation
The Microsoft Exchange Transport service did not restart. This is the most common cause. The transport service loads its certificate references at startup. If the service is not restarted after a new certificate is imported, it keeps referencing the old certificate's thumbprint. The new certificate sits unused.
Thumbprint mismatch after renewal. When you renew a certificate through a certificate authority rather than using Exchange's self-signed renewal, the new certificate has a different thumbprint. Exchange sees a valid certificate but does not recognize it as the intended replacement.
Wrong certificate promoted. When multiple certificates exist in the store, Exchange may promote the wrong one, particularly if a previous rotation attempt left behind old certificates from earlier failed attempts.
Services not assigned to the new certificate. A certificate must be explicitly assigned to SMTP and IIS before Exchange will use it. If the import step skipped the service assignment, the certificate cannot promote because it is not eligible.
How to Tell If Your Rotation Has Stalled
A stalled rotation does not generate a dedicated alert. Instead, it shows up as a cascade of symptoms that are easy to misdiagnose.
DKIM signing failures on outbound mail. This is the most reliable signal. Exchange Server uses the auth certificate to DKIM-sign outbound messages. When the transport service is still referencing the wrong certificate, DKIM signatures are incorrect or absent. The headers show a DKIM-Signature that receivers cannot validate against your published selector record.
DMARC reports showing sudden DKIM alignment failures. If you are reading your DMARC aggregate reports, a certificate problem appears as an abrupt drop in DKIM pass rate for mail you did not change. This often gets misdiagnosed as a DNS problem or a DKIM key rotation problem.
Non-delivery reports for internal mail between Exchange servers. When servers in the same Exchange organization cannot authenticate to each other because the certificate they expect is not the one being presented, internal mail flow breaks. Messages between mailboxes on different servers fail with NDRs.
Event ID 12014 or 12015 in Windows Event Viewer. Event ID 12014 means Microsoft Exchange could not enable a certificate for SMTP transport. Event ID 12015 means a logon failure due to a certificate problem. These are the clearest diagnostic indicators that the certificate is not correctly assigned.
How to Fix a Stalled Exchange Auth Certificate Rotation
Force the certificate to promote using PowerShell. Log into the Exchange Server via Remote PowerShell and run the following steps in order.
Step 1: Find the right certificate
Get-ExchangeCertificate | Format-List Subject, Thumbprint, NotAfter, Services
Identify the certificate that is valid (NotAfter in the future), has no services or only partial services assigned, and matches your server's FQDN in the Subject. If multiple certificates meet these criteria, choose the one with the most recent NotAfter date.
Step 2: Enable it for SMTP and IIS
Replace <Thumbprint> with the thumbprint from Step 1:
Enable-ExchangeCertificate -Thumbprint "<Thumbprint>" -Services "SMTP, IIS"
Running this command on a certificate that is already partially enabled overwrites the previous assignment. That is fine.
Step 3: Force promotion if it stays in Next
In most cases, Step 2 is enough. If the certificate is still listed as "Next" after enabling services, try:
Set-ExchangeCertificate -Thumbprint "<Thumbprint>" -Default
This forces the certificate to be the default for all services. Availability of the -Default flag depends on your Exchange version; Exchange Server 2019 CU12 and later support it.
Step 4: Restart the transport services
Restart-Service MSExchangeTransport
Restart-Service MSExchangeIS
These are the two services that load certificate references at startup. Restarting them forces a fresh load of the current certificate state.
Step 5: Verify it worked
Get-ExchangeCertificate | Format-List Subject, Thumbprint, NotAfter, Services
Services should now show "SMTP, IIS, POP, IMAP" or the full list of assigned services. Send a test message to an external address and check the authentication results headers. The DKIM-Signature header should be present and the auth result should show "pass."
If Event ID 12014 or 12015 appears in Event Viewer after the restart, the certificate is still not correctly assigned. Go back to Step 1 and verify you have the right thumbprint.
Step 6: Confirm in your next DMARC report
DMARC aggregate reports typically arrive daily. After completing the rotation, your next report should show DKIM alignment restored for your outbound mail. If DKIM failures persist after two consecutive reports, the certificate promotion completed but a separate DKIM configuration issue exists independently of the certificate.
How to Catch Certificate Problems Before They Break Mail
The most practical early warning system for certificate rotation problems is your own DMARC aggregate reports. A certificate stall shows up as a sudden drop in DKIM pass rate on mail you did not change. If your DKIM pass rate falls noticeably without any corresponding change in your sending configuration, a certificate problem is a likely cause.
DMARCFlow monitors DKIM pass rates across your domains and can alert you when the rate drops unexpectedly. This catches rotation stalls weeks before the old certificate expires and causes a mail flow incident. You do not need to remember to check the Exchange certificate store every month. The DMARC report tells you something is wrong as soon as it is wrong.
The Exchange Admin Center will generate alerts for certificates within 30 days of expiration, but that only helps if the rotation completed. A stalled rotation produces no expiration alert because the old certificate is still technically valid. The gap between "rotation failed" and "old certificate expires" can be weeks or months, and during that window your DKIM signing is broken without any warning from Microsoft tooling.
Setting up DKIM alignment rate monitoring in DMARCFlow closes that gap. A daily check on DKIM pass rate across your domains costs nothing in terms of effort and catches this class of problem the moment it appears in your aggregate data.
What You Should Do Now
Run this on your Exchange Server before you close this article:
Get-ExchangeCertificate | Format-List Subject, Thumbprint, NotAfter, Services
Note the expiration date. If it is within 90 days, schedule the rotation now. More importantly, plan to verify the rotation completed successfully after the expiration date. The worst time to discover a stalled rotation is when your users start calling about NDRs.