How DNS Migrations Break DKIM Signatures (and Prevention)

DNS migrations frequently break DKIM signatures because DKIM keys live in subdomain records that migration tools often miss. Here is how to diagnose, fix, and prevent it.

Why DNS Migrations Break DKIM

DKIM Selectors Live in Subdomains, Not at the Root

Most DNS records for a domain live at the root: example.com. SPF lives here. MX records live here. DKIM does not.

DKIM signing keys are stored in subdomains named after a selector. A typical DKIM record looks like this:


selector1._domainkey.example.com.  IN  TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

The selector is selector1. The subdomain is _domainkey.example.com. Most DNS migration tools display root-level records prominently. Selector subdomains are easy to miss because they look like every other subdomain record in a long list.

Re-importing Zone Files Creates Duplicate Records

When DNS is exported as a zone file and re-imported into a new provider, the process can silently create duplicate TXT records for the same selector name. RFC 1035 does not define behavior for multiple TXT records with the same name, and DNS providers handle them differently. Some return the first record. Some return all of them. Some return unpredictable results based on TTL or query order.

If your DKIM selector has two TXT records and a receiving mail server gets the wrong one during the brief TTL window after migration, DKIM validation fails.

Selective Sync Drops Selector Records Entirely

Some migration tools sync only records that exist in both the source and destination. If the DKIM selector was added after the original zone export was taken, it never reaches the new DNS provider. The record is not deleted -- it was never there to begin with.

Other times, the new DNS provider creates a placeholder record with the right selector name but the wrong value, overwriting the real DKIM key. The record looks correct in the console. The email authentication still fails.

How to Diagnose DKIM Breakage After a DNS Migration

Step 1: Check Your DKIM Record Directly

Query your DKIM selector using dig:

bash
dig selector1._domainkey.example.com TXT

Replace selector1 with your actual selector name (check your email provider's DKIM setup page for the exact value). Replace example.com with your domain.

Compare the result against what your email provider lists as the expected DKIM value. If the record is missing, truncated, or does not match exactly, that is your problem.

You can also use a DKIM inspector tool if you prefer a web interface. Most free DKIM inspectors let you enter the selector and domain directly.

Step 2: Read Your DMARC Aggregate Reports

If you have DMARC monitoring set up, the aggregate report will show a sudden drop in DKIM pass rates, usually coinciding with the date of your DNS migration. Forensic reports (if enabled) will show specific message IDs and receiving servers that failed DKIM validation.

The timing correlation is usually obvious: everything passes DMARC on Thursday, DKIM failures spike on Friday afternoon, and by Monday morning your team has hundreds of bounced message notifications.

This is where DMARCFlow earns its place. The service aggregates your DMARC reports and sends an alert when DKIM pass rates drop unexpectedly -- without requiring you to log into a portal and manually check report after report. The alert tells you when the failure started and which sending sources are affected, so you are not guessing about the cause of a deliverability problem.

Step 3: Send a Test Message

Send a test message to a mailbox you control and inspect the authentication headers in the received email. Look for a DKIM-Signature header. Check whether the header.d= value in the DKIM-Signature matches your sending domain.

If it does not match, DKIM alignment is broken and the message will fail DMARC unless your policy is set to none.

How to Fix DKIM After a DNS Migration

Step 1: Find the Correct DKIM Record

Go to your email provider's DKIM setup page. Every major provider publishes the exact selector name and full TXT record value for their DKIM keys:

Microsoft 365: Go to Exchange Admin > Mail flow > DKIM and select the domain. The selector is selector1 and selector2 by default.
Google Workspace: Admin Console > Apps > Google Workspace > Gmail > Authenticate email. The selector name varies.
Brevo: Settings > Sender & IP > Configure Your DKIM Signature.
Mailgun: Domain management > Domain Verification > DKIM.
SendGrid: Settings > Sender Authentication > Authenticate Your Domain.

Copy the selector and TXT value exactly. DKIM values are Base64-encoded and case-sensitive -- a single wrong character breaks validation.

Step 2: Add the Record to Your DNS

Create a new TXT record in your DNS:

Name/Host: selector1._domainkey (use your actual selector name)
Value: Paste the full TXT value from your provider
TTL: 3600 (1 hour) or lower during setup; increase afterward

Save the record and wait for propagation. Most DNS changes take 5 minutes to an hour. Some can take up to 24 hours depending on your TTL and the receiving server's DNS cache.

Step 3: Verify the Fix

Run dig selector1._domainkey.example.com TXT again and confirm the result matches exactly. Send another test message and check the authentication headers.

Check your DMARC aggregate report within 24 hours to confirm DKIM pass rates have returned to baseline.

Step 4: Clean Up Duplicate Records

If dig returns multiple TXT records for the same selector name, you have duplicates. Most DNS providers require you to delete and re-add the record to resolve this -- editing in place often keeps both records.

Delete all TXT records for that selector name. Add back only the one correct record. Run dig again to confirm only one record is returned.

How to Prevent DKIM Breakage During Future DNS Migrations

1. Document Your DKIM Selectors Before Any Migration

Before touching any DNS, list every selector._domainkey TXT record in use. For each one, record:

The full subdomain name (e.g. selector1._domainkey.example.com)
The complete TXT value
Which email provider or service owns it
When it was last verified

Store this in the same place you keep your other domain documentation. DKIM selectors are not optional maintenance -- they are the key to your outbound email reputation.

2. Include DKIM in Your Migration Scope

Treat DKIM selectors the same as MX and SPF records. Your DNS migration checklist should include a step to verify each DKIM selector resolves correctly after the migration, before you consider the migration complete.

3. Test Email Authentication Immediately After DNS Changes

Do not wait for user complaints. The moment a DNS migration finishes, send a test message to a controlled mailbox and inspect the authentication results. Check your DMARC aggregate report within an hour if your monitoring tool supports it.

This is where ongoing DKIM monitoring pays off. DMARCFlow tracks your DKIM pass rates over time and sends an alert when they drop -- which means you find out about a DNS migration problem on the day it happens, not three days later when a VP asks why the sales team is not getting responses.

4. Use a DNS Provider That Warns on Duplicate TXT Records

Some DNS platforms alert when you try to create a TXT record that already exists. If your provider does not warn on duplicates, use a DKIM checker tool after any migration to verify you have exactly one correct record for each selector.

5. Know Your DKIM Key Rotation Schedule

Some email providers rotate DKIM keys on a schedule -- annually is common. If your provider rotates keys, the DKIM TXT record value changes and you will need to update DNS again at that time.

Plan DNS migration timing around key rotation dates. Never do both at the same time.

FAQ

Can I migrate DKIM the same way I migrate SPF?

Partly. Unlike SPF (which is a single TXT record at the root and migrates with the rest of your zone), DKIM selectors are independent subdomains that must be identified and migrated deliberately. The migration process is different, even though both happen in DNS.

What happens if I lose my DKIM private key?

If you lose the private key, you cannot decrypt DKIM signatures from that key. Your email provider should regenerate a new key pair and give you a new public record to add to DNS. Any email signed with the old key will fail validation until the new record propagates. This is one reason to keep DKIM documentation current.

How long does a DKIM DNS change take to propagate?

Most DNS changes propagate within minutes to an hour. The maximum is 24 hours based on TTL settings. Receiving mail servers that cached the old record may continue to see the old value until their cache expires. This is why setting a short TTL before making DKIM changes is good practice.

Should I use the same DKIM selector across all my email providers?

No. Each email provider should have its own unique selector. Using the same selector name for multiple providers causes record conflicts and validation failures. Most providers assign their own selector name during setup -- do not change it.

My SPF passes but DKIM fails after migration. Is that normal?

Yes. SPF and DKIM are independent mechanisms. SPF passes because it lives at the root domain and migrated correctly. DKIM fails because the selector subdomain was missed. This is exactly the pattern DNS migration DKIM failures follow.

Summary

DNS migrations break DKIM because DKIM records live in subdomains that most migration tools overlook or mishandle. The fix is to document DKIM selectors before any migration, verify them immediately after, and use ongoing monitoring to catch failures before they become user complaints. The prevention checklist is short: know your selectors, include them in scope, test after every change, and keep your DKIM documentation current.