Why DKIM Breaks After DNS Migration and How to Prevent It

Why DNS migrations break DKIM - and how to stop it the next time

When you change DNS providers or move a domain's nameservers, the last thing you expect is for email authentication to silently break. But DKIM breaks during DNS migrations more often than most administrators realize - and by the time you notice, legitimate email has been landing in spam folders for hours.

The problem is not that DKIM is fragile. It is that DNS migration tools were not built with DKIM's specific requirements in mind. This post explains the three specific ways DNS migrations break DKIM, how to diagnose the failure fast, and what to do before your next migration window.

The three failure modes

1. Multi-line TXT record splitting

DKIM TXT records contain a public key and are stored as a single string. The format looks like this:


v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC

In practice, DKIM keys are long enough that they need to be split across multiple quoted strings in the DNS record:


"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB"
"AgENBgkqhkiG9w0BAQEFAAOCAQ"

DNS migration tools that copy TXT records literally sometimes insert a space or line break between the quoted strings, or they concatenate them incorrectly into a single line without proper spacing. The result is a DKIM record that looks syntactically fine but resolves to a malformed value that mail servers cannot parse.

2. DKIM selector orphaning

DKIM uses selector records - the TXT record at selector._domainkey.example.com - to find the public key. During a DNS migration, migration tools often copy the main domain records but miss subdomains, especially those that are not obvious like the _domainkey subdomain used for email authentication.

If the DKIM selector record does not exist at the new DNS provider, outgoing mail servers cannot find the public key to verify signatures. Emails fail DKIM checking at receiving servers, which then fail DMARC alignment if the domain uses p=reject or p=quarantine.

3. TTL caching gaps

This is the hardest failure mode to predict. When you update a DNS record, recursive resolvers still serve the cached (old) value until the TTL expires. If you delete the old DKIM record before the new one propagates, there is a window - potentially hours - where the DKIM selector is not resolvable at all.

For low-volume mail servers, this gap may not matter immediately. For high-volume senders, that window is enough to trigger permerror responses from receiving servers and start affecting deliverability within a single business day.

How to diagnose DKIM failure after a DNS migration

If you have already noticed DMARC failures or spam folder placement after a migration, here is how to confirm whether DKIM is the cause.

Step 1: Identify your DKIM selector

Check your mail server configuration for the selector name. It is usually stored in your MTA config (Postfix, Exim, Exchange, or your email service provider settings). Look for the _domainkey subdomain prefix.

If you do not know the selector, check a recent DMARC aggregate report. The selector field in a DKIM failure record tells you which selector failed.

Step 2: Check DNS resolution with dig

bash
dig TXT selector._domainkey.yourdomain.com

Replace selector with your actual selector name and yourdomain.com with your domain. If the record does not resolve or returns SERVFAIL, the DKIM TXT record is missing or malformed at the new DNS provider.

Step 3: Validate the key format

Even if the record resolves, check that it has not been corrupted. A valid DKIM TXT record starts with v=DKIM1; and contains a p= parameter with a Base64-encoded key. If p= is empty or the record is truncated, the key was not copied correctly.

You can use an online DKIM checker to verify the record is valid and retrievable by external mail servers.

Step 4: Read DMARC reports for permerror patterns

In your DMARC aggregate reports, look for <result>permerror</result> paired with <selector> fields. A permerror means the receiving server could not even attempt DKIM verification because the DKIM record was invalid, unreachable, or malformed. This is different from a hard fail (fail) which means DKIM verified but alignment failed.

If you see permerrors appearing suddenly after a DNS change, the DKIM record is the likely culprit.

How to fix it and restore email deliverability

Once you have identified the broken DKIM record, fixing it is usually fast. The delay in恢复 is typically from time spent diagnosing, not from re-publishing.

Re-publish the DKIM record

Go to your original DNS provider (or your email service provider's dashboard) and copy the exact DKIM TXT record. Paste it into your new DNS provider exactly as it appears - do not reformat it, do not add line breaks manually, and do not let the provider auto-format the record.

If your DNS provider breaks multi-line TXT records, split the record manually and ensure each segment is in its own quoted string with a single space between segments.

Force re-sign on the mail server

After republishing, restart your MTA or trigger a re-sign operation to ensure outgoing emails use the current DKIM selector. Some mail servers cache the DKIM signing configuration and will not pick up the new record until restarted.

Verify before declaring the problem solved

Run the dig command again and use an external DKIM checker to confirm the record resolves and validates. Then check your next DMARC aggregate report - the permerror count should drop to zero within one reporting period (typically 24 hours).

Prevention checklist for the next DNS migration

The best time to prevent DKIM breakage is before the migration window, not after.

Before the migration

Identify every DKIM selector in use (check MTA config and email service provider settings)
Verify all DKIM TXT records resolve correctly at the current DNS provider
Set TTLs for DKIM selector records to 300 seconds (5 minutes) at least 24 hours before the migration window
Export a plain-text backup of all DKIM records including the full key values and selector names
Notify your email service provider if you use one - some providers republish DKIM keys automatically and may need to be coordinated

During the migration

Keep the old DNS provider active in parallel for at least 48 hours after the migration
After updating nameservers, immediately verify each DKIM selector resolves at the new provider before doing anything else
If using a DNS provider web interface, double-check that multi-line TXT records are preserved exactly - do not trust the provider's preview, use dig to verify the actual resolver response
Check DMARC reports every 2 hours during the first business day after cutover

After the migration

Restore DKIM TTLs to their normal values once propagation is confirmed
Monitor DMARC aggregate reports for 7 days after the migration to catch any delayed permerrors
If your email service provider manages DKIM on your behalf, confirm they have synced the new DNS and are still signing with the correct selector

How DMARCFlow helps catch DKIM failures fast after a migration

After a DNS migration, the fastest way to know DKIM has broken is to look at DMARC aggregate reports. A permerror spike within hours of a nameserver change is a reliable signal that something in the authentication chain is wrong.

DMARCFlow processes these reports automatically and can alert you within hours of a migration cutover - before users start reporting spam folder issues or you receive complaints about undelivered email.

This is the part where DMARCFlow fits naturally into the workflow. After a DNS migration, DMARC aggregate reports are the fastest signal that DKIM has broken - you see permerrors appearing within hours, before users start complaining about missing email. If you are planning a DNS migration, the right time to set up DMARC report ingestion is before the migration window opens, not after. That gives you a clean baseline and the ability to react to alerts instead of discovering the problem through customer complaints.

FAQ

Can DNS migration break DKIM even if I copy the exact same record?

Yes. Even when the TXT record content is identical, the way it is stored at the new DNS provider can differ. Multi-line records are the most common casualty - if the new provider concatenates or reformats the quoted strings, the resulting record value changes even though it looks the same in the provider's UI.

How long does a DKIM failure take to show up in DMARC reports?

DMARC aggregate reports are typically generated daily, though some providers send them more frequently. You may not see DKIM permerrors in a report until 24 to 48 hours after the failure starts. This is why proactive DNS validation with dig immediately after a migration is faster than waiting for DMARC reports.

Should I pause email sending during a DNS migration?

For low-volume or non-critical email, pausing for a few hours during the migration window reduces risk. For high-volume production mail servers, pausing is disruptive and usually unnecessary if you follow the prevention checklist. The key is verifying DKIM resolution immediately after nameserver cutover before resuming full email traffic.

What does DKIM permerror mean in a DMARC report?

A permerror means the receiving mail server could not attempt DKIM verification at all because the DKIM record was invalid, unreachable, or malformed. This is different from a fail result, which means DKIM verified but alignment with the sender domain failed. Permerrors after a DNS change point directly at a broken DKIM TXT record.