Why Exchange 2016 DKIM Signing Stops Working After an Update (And How to Fix It)

Exchange DKIM signing regularly stops working after an update. Not because the update is faulty, because Microsoft's DKIM implementation in Exchange is tightly coupled to the Windows components that handle cryptographic signing and DNS lookups. When one of those components changes, DKIM can silently break.

If you run Exchange Server and rely on DKIM to satisfy DMARC alignment, this is a problem you'll hit eventually. Here's why it happens, how to find it, and how to fix it, and how to make sure you find out about it faster next time.

Why Exchange DKIM is fragile across updates

Exchange Server's DKIM signing uses the Windows Cryptographic Modern provider via the Exchange Transport service. The DKIM signing keys are stored in Active Directory under the Microsoft Exchange Server configuration container, and the actual signing operation happens in the Transport service's Mailbox Transport submission worker.

When you apply a Windows update that replaces the SChannel cryptographic components, or when an Exchange Cumulative Update (CU) replaces underlying DLLs that handle crypto operations, the existing DKIM signing configuration can fail silently. The service keeps running. Email keeps flowing. But the signatures are wrong, or missing entirely. Your DMARC aggregate reports start showing DKIM alignment failures, and you may not notice until a receiving domain flags your mail as unauthenticated.

This is one of the most common DKIM failures Exchange admins encounter and one of the easiest to miss without proactive monitoring. DMARCFlow monitors your DKIM selector records and alerts you when signing health changes, so you catch post-update failures within minutes rather than days.

The specific failure mode varies:

• The private key stored in AD becomes inaccessible because the new Windows version uses a different key storage format
• The signing module can't find the DKIM selector DNS records because the new crypto provider handles name resolution differently
• The Exchange transport service's DKIM signing agent stops running without producing an error visible in the standard Exchange logs

Most admins discover this only when they check their DMARC aggregate reports and see DKIM alignment failures appearing suddenly, often 24 to 72 hours after the update was applied.

Common update triggers that break Exchange DKIM

Exchange Cumulative Updates are the most predictable triggers. When you apply a CU, it updates the Exchange binaries and resets services, which can interrupt the DKIM signing agent. The signing configuration persists, but the agent may not restart properly if the update changes the order in which services start.

Windows SChannel updates are less obvious. SChannel is the Windows component that handles TLS and cryptographic operations. Microsoft periodically updates SChannel as part of Patch Tuesday. If your Exchange server is running DKIM signing and a SChannel update changes how keys are loaded from AD, signing stops. You won't see a warning in the Exchange event log.

Key rollover initiated by the domain's DNS can also trigger a brief outage. If your DNS provider auto-rotates DKIM selector keys and your Exchange server's DKIM agent caches the old public key, the mismatch causes authentication failures until the cache refreshes.

How to diagnose DKIM failures after an update

The fastest way to confirm a DKIM failure is to check the headers of an outbound email sent after the update was applied.

Look for the DKIM-Signature header. If it's missing from emails that should be signed, DKIM signing has stopped working.

If the header is present, check the h= tag for the selector and the d= tag for your domain. Then run a DKIM lookup against that selector:

dig TXT 20240605._domainkey.yourdomain.com

Replace 20240605 and yourdomain.com with your actual selector and domain. If the lookup returns no DKIM record, your DNS may have rotated the key without updating Exchange's signing configuration.

You can also use the Exchange Management Shell to verify the DKIM signing configuration is still applied:

Get-TransportConfig | Select-Object *DKIM* Get-DkimSigningConfig | Select-Object Domain, Enabled, Selector1Key, Selector2Key

If Enabled shows True but your DMARC reports show consistent DKIM failures, the signing is configured but not working.

How to restore Exchange DKIM signing

If a recent update is the cause, restarting the Exchange Transport service often restores DKIM signing:

Restart-Service MSExchangeTransport

If that doesn't fix it, you may need to reset the DKIM signing configuration:

Set-DkimSigningConfig -Identity yourdomain.com -Enabled $false # Wait 30 seconds Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true

This forces the signing agent to re-read the keys from AD and re-initialize the signing module.

For SChannel-related breakage, you may need to verify the cryptographic provider chain. Microsoft published a fix for an issue where Windows updates caused the Exchange DKIM signing agent to fail to load the RSA key from AD. The fix involves ensuring the Microsoft Exchange Server Security Authenticator Windows feature is enabled.

After restoring signing, send a test email and verify the DKIM-Signature header appears in the message source. Then check your DMARC aggregate report 24 to 48 hours later to confirm alignment is restored.

How to monitor DKIM health proactively after updates

Proactive monitoring is where most Exchange shops are caught short. DKIM failures post-update don't produce Exchange event log entries by default. You find out when your DMARC reports show the problem, which might be days later.

The most reliable approach is DNS-based monitoring. After any update cycle, verify that your DKIM selector record is still present and resolves correctly. If you use DMARCFlow, DNS monitoring alerts catch selector record changes or disappearances automatically, so you don't have to manually check after every update.

You should also treat your DMARC aggregate reports as monitoring data. Set up alerts for any sudden increase in DKIM alignment failures. A spike in DKIM failures immediately after a maintenance window is a strong indicator that an update broke signing.

FAQ

Q: Why did my Exchange DKIM signing stop working after an update?
A: Most commonly because the Windows SChannel update or Exchange CU changed the cryptographic components that Exchange uses for DKIM signing. The signing service may restart but fail silently, or the keys stored in AD may become inaccessible to the signing module.

Q: How do I restore DKIM signing in Exchange Server 2016 or 2019?
A: Restart the Exchange Transport service first. If that doesn't work, disable and re-enable DKIM signing for the affected domain using Set-DkimSigningConfig. In persistent cases, verify the Windows Cryptographic provider is functioning correctly and that the Microsoft Exchange Server Security Authenticator feature is enabled.

Q: Can I monitor DKIM status automatically after updates?
A: Yes. DNS monitoring that checks your DKIM selector records periodically will catch most failures within minutes, rather than waiting for DMARC aggregate reports to show alignment failures. DMARCFlow's DNS monitoring alerts you when a DKIM selector record disappears or changes unexpectedly, including after update cycles when breakage is most likely. You can also set up alerts on your DMARC aggregate reports for sudden spikes in DKIM alignment failures.

Q: What causes Exchange DKIM to break during key rotation?
A: If your DNS provider auto-rotates DKIM keys without coordination, the new public key may not match what Exchange is signing with. Exchange caches DKIM keys, so a DNS rotation can cause a brief mismatch until the cache refreshes. If the rotation also changes the selector name, you need to update the Exchange DKIM signing config to use the new selector.

Q: Does disabling DMARC checking help during an Exchange DKIM outage?
A: No. Disabling DMARC checking removes the verification, not the problem. Your outbound mail will still fail DMARC alignment for receiving servers that check it. Fix the DKIM signing, don't disable DMARC.