How DNS Changes Break DKIM Signatures

How DNS Changes Break DKIM Signatures and How to Prevent It Before Your Next Migration

A client recently migrated their DNS to a new provider. Within two hours, their invoicing system had sent dozens of legitimate emails straight to recipients' spam folders. The cause was not a spam filter finding a malicious payload. The cause was a broken DKIM signature.

This happens more often than it should. DNS migrations are treated as routine infrastructure work, but when they touch DKIM records without proper validation, the consequences land in inbox spam and in DMARC failure reports. Here is how the mechanism works and how to prevent it.

What Actually Went Wrong

DKIM works by attaching a cryptographic signature to an outbound email. That signature is published as a TXT record at a DNS address called a selector -- something like selector._domainkey.yourdomain.com. When a receiving mail server gets the email, it looks up that TXT record, verifies the signature against the public key it finds there, and reports the result.

During a DNS migration, the DKIM TXT record gets moved from the old DNS provider to the new one. If the record is not fully migrated before the old zone is taken down -- or if the DKIM selector value itself was generated by an email platform that is also being reconfigured -- the signature and the DNS record stop matching.

When the record vanishes or points somewhere different, the receiving server cannot verify the signature. That is a DKIM "none" or "fail" result. Combined with DMARC alignment checking, a failed DKIM verification can cause the receiving server to reject the email or file it as spam -- even though the email itself is entirely legitimate.

Why DNS TTLs Do Not Protect You During a Migration

This is the most common misconception about DNS and DKIM. DNS TTLs (Time To Live) tell recursive resolvers how long to cache a record before asking again. TTLs are useful for normal operation -- they reduce query load and allow for planned record changes.

But TTLs do not protect you during a migration. Here is why.

When you change or delete a DKIM TXT record at the authoritative DNS server, that change is immediate at the source. The old record does not persist for the TTL duration. Recursive resolvers that already cached the old value may serve it for up to the TTL, but once the TTL expires and the resolver re-queries, it gets the new value -- or a NXDOMAIN if the record was deleted.

The window of vulnerability is not the old TTL. The window is the period between when the old DNS server is taken down and when all downstream resolvers have re-queried. That window can be minutes or hours, depending on resolver behavior and TTL values across the chain.

For DKIM, this means the signature on an email and the DNS record that validates it can become desynchronized at any point after a migration -- not on a predictable schedule based on your TTL, but as soon as the authoritative record changes.

The DKIM-DMARC Alignment Connection

Here is the step that turns a broken DKIM signature into a rejected email. DMARC checks not just whether DKIM verifies, but whether the DKIM signature domain aligns with the RFC5322.From domain -- the address the recipient sees as the sender.

DKIM lets you sign emails with a domain that is different from the RFC5322.From. DMARC enforcement requires that domains either match exactly or be in a trusted subdomain relationship.

When a DNS migration breaks DKIM and the selector no longer resolves, the DKIM verification returns "none" (no signature found) or "fail" (signature did not verify). Neither result satisfies DMARC alignment for the RFC5322.From domain. If your DMARC policy is p=quarantine or p=reject, the email gets flagged or rejected.

This is why DKIM failures during DNS migrations tend to have a broad blast radius. It is not just that the signature does not work. It is that DMARC enforcement treats the misalignment as a policy violation and acts accordingly -- often on every single email sent during the affected window.

Pre-Migration DKIM Validation Checklist

Before you move DNS, run through this:

Query every DKIM selector for your domain and save the results. Run dig TXT selector._domainkey.yourdomain.com for each known selector. Do this before you touch anything. These are your baseline values.
Note the current TTL for each DKIM TXT record. Write them down. You need these numbers for the next step.
Verify each selector resolves to a valid DKIM public key. A selector that exists but contains no valid key data will still cause verification failures.
Calculate your minimum safe migration window: take the longest DKIM TXT TTL for any of your selectors, multiply by two, and add your DNS retry interval. Do not touch anything related to DKIM or email DNS until this window has fully elapsed after your migration.
After the migration cutover, before declaring success, re-verify all DKIM selectors. Query each one from an external resolver (not your internal recursive resolver, which may still be serving cached data).
Do not delete the old DKIM records until the new records have been confirmed live and verified for at least one full TTL cycle.

The goal is to never have a DKIM selector that exists in an email but does not have a valid, matching TXT record in DNS.

Post-Migration Monitoring: Catch Failures Before Users Do

DNS migration windows are high-risk periods. The best way to catch failures fast is to watch DMARC aggregate reports in the first 24 to 48 hours after cutover.

DMARCFlow monitors your DMARC aggregate reports and alerts you when DKIM alignment failures spike -- specifically when the number of DKIM fail or none results increases sharply from your baseline. When that spike coincides with a DNS migration window, you have a clear signal to investigate your DKIM selectors before the blast radius grows.

Without automated monitoring, you are relying on recipients to report spam complaints or on checking your sending logs manually. With DMARCFlow, you know within hours that DKIM verification is failing, which narrows the investigation to your DKIM DNS configuration rather than your mail server setup.

This is especially useful for organizations that do not send high volumes of email -- a small number of DKIM failures can be lost in the noise of a busy mail system. DMARCFlow surfaces the signal regardless of volume.

User complaints are a lagging indicator. By the time someone replies to an invoice asking why it went to spam, the damage to sender reputation may already be done. DMARC aggregate reports tell you within hours, not days.

Quick Reference: DNS Migration and DKIM Safety Checklist

[ ] Query and record all DKIM selector TXT records before migration
[ ] Note TTL values and calculate 2x TTL + retry minimum holdover window
[ ] Verify each selector resolves to a valid public key before cutover
[ ] After cutover, re-verify all selectors from an external resolver
[ ] Keep old DKIM records live until new records confirmed for at least one TTL cycle
[ ] Monitor DMARC aggregate reports in the first 24-48 hours post-migration
[ ] Alert on DKIM fail/none spikes with DMARCFlow

FAQ

How long should I keep old DKIM records after a migration?

Keep old DKIM TXT records live for at least 2x the maximum TTL of your DKIM selectors, plus your DNS retry interval. For selectors with TTLs of 3600 seconds, that means holding old records for at least 7200 seconds (two hours) after the new records are live. If your TTLs are longer, extend proportionally. Some teams keep old DKIM records for 72 hours post-migration to account for slow global DNS propagation.

How do I check if my DKIM selectors are working?

Use dig TXT selector._domainkey.yourdomain.com @8.8.8.8 from an external resolver (not your local network) to check whether the selector resolves correctly. Then send a test message to a mailbox you control and check the authentication results headers -- receiving servers typically report DKIM verification status in the Authentication-Results header. If the header shows dkim=fail or dkim=none when you expect dkim=pass, your selector is not working correctly.

Can a DKIM selector be valid in DNS but still fail verification?

Yes. DKIM verification requires both a valid DNS record and a matching signature in the email header. If your email platform rotates its DKIM private key but the DNS TXT record still points to the old public key, verification will fail even though the DNS record exists. This can happen during platform migrations or key rotation without corresponding DNS updates.