Blog · Dkim
What Happens to DKIM When You Migrate DNS (and How to Recover)
The scenario
A client migrates their DNS to a new provider on a Friday night. By Monday morning, their billing system has sent two hours of invoices that all landed in spam. The mail server logs show DKIM failures. Nobody touched the mail server. The DNS migration is the only thing that changed.
This is not rare. DKIM is tightly coupled to DNS, and DNS changes are one of the most reliable ways to break email authentication without touching a single mail server config.
How DKIM uses DNS
DKIM adds a digital signature to every outbound email. The receiving server verifies that signature using a public key published in your DNS as a TXT record.
The record lives at:
selector._domainkey.yourdomain.com
The selector is a string your mail server inserts into the DKIM header. Most providers use a fixed selector like s1 or default. Some use multiple selectors for key rotation.
The TXT record contains the public key in this format:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA...
For DKIM verification to work, three things must be true:
1. The TXT record exists and is publicly resolvable
2. The selector in the email header matches the selector in DNS
3. The public key matches the private key your mail server is using to sign
DNS migrations can break all three.
Three ways DNS migrations break DKIM
1. The DKIM TXT record disappears or gets truncated
When you export a zone file from one DNS provider and import it into another, DKIM TXT records are often the first to get mangled. They tend to be long - 2048-bit DKIM keys run about 350 characters of base64 - and DNS interfaces are not always good at handling long TXT records without line breaks, extra quotes, or whitespace corruption.
A DKIM record that looks fine in the old provider's UI may import as a broken record at the new provider. When the receiving server tries to look up your DKIM key, it gets a format error or no answer at all.
2. The selector record points to the wrong domain
Some DNS migration tools preserve the relative record names but lose the origin. A DKIM record for selector._domainkey.example.com might get imported as a record for selector._domainkey.newdnsprovider.com or just selector._domainkey without the domain suffix.
When your mail server signs an email with selector s1, the receiving server looks for s1._domainkey.example.com. If the DNS record is missing or points elsewhere, verification fails.
3. TTL caching keeps serving a stale or removed record
Even when the migration itself is clean, DNS caching can cause problems. If your DKIM record had a 24-hour TTL before the migration, some resolvers will keep serving the old record for up to 24 hours after the migration completes.
If you removed the old DKIM record before the new one propagated, you have a window where DKIM verification returns no record at all. Similarly, if you changed your DKIM selector during the migration but some resolvers still cache the old one, emails signed with the new selector will fail verification.
This is the failure mode that catches people off guard: the migration looks complete, the DNS looks right when you check it, but deliverability keeps failing for another day or two because of cached stale records.
How to diagnose a DKIM failure after DNS migration
Step 1: Check the DKIM selector in your email header
Find a recent email that went to spam. View the raw email headers and look for the DKIM-Signature header. The s= tag shows the selector:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
In this case the selector is s1, so the full DKIM record name is s1._domainkey.example.com.
Step 2: Query that record directly with dig
bash
dig TXT s1._domainkey.example.com
Look for:
NXDOMAIN- the record does not exist- A record that does not look like a DKIM key (wrong format)
- A DKIM record that matches what your email provider says it should be
If dig returns nothing from your local resolver, try:
bash
dig @8.8.8.8 TXT s1._domainkey.example.com
Using Google's resolver bypasses your local cache and tells you what is actually published.
Step 3: Use an online DKIM checker
MxToolbox, dkim.studio, and DMARCFlow all offer DKIM lookup tools. Paste your selector and domain to see whether the record is valid, malformed, or missing.
Step 4: Read the auth results header
Receiving servers add an Authentication-Results header to every email. Look for:
auth=fail; dkim=FAIL
dkim=fail with no additional detail, the receiving server could not verify the DKIM signature. If it says dkim=permerror, the DNS lookup returned a permanent failure (record not found or malformed). dkim=temperror means a transient DNS failure - retry later.
permerror after a DNS migration usually means the record did not import correctly. temperror might mean the record exists but DNS propagation is still in flight.
How to fix it
Re-publish the DKIM TXT record
Log into your DNS provider and manually add the DKIM TXT record exactly as your email provider specified it. Do not copy from the old provider's zone export - get the record directly from your email provider's dashboard or documentation.
When entering a long DKIM key, paste the entire value without line breaks. Some DNS UIs wrap long values visually; make sure the stored record has the key on a single line.
Verify the selector matches
Check that the record name exactly matches selector._domainkey.yourdomain.com. If your email provider uses multiple selectors (common with key rotation), publish all of them.
Force a DNS refresh
Lower the TTL on the DKIM record to 300 seconds (5 minutes) before making changes next time. This makes future updates faster. For immediate recovery after a broken migration, there is no way to force all resolvers to refresh - you have to wait. Most cached records update within 2 hours. Stale records at recursive resolvers with long minimum TTLs can persist for 24-48 hours.
Retest from a clean resolver
After republishing the record, test with:
bash
dig @8.8.8.8 TXT s1._domainkey.example.com
How to prevent it
Lower your DKIM TTL before any DNS change
Set the DKIM record TTL to 300 seconds at least 48 hours before a planned DNS migration. This ensures that when you make the change, cached copies expire quickly and resolvers pick up the new record.
Snapshot your DNS before the migration
Save a text copy of all your DNS records - especially TXT records - before touching anything. If the migration corrupts a record, you have the exact values to re-enter manually.
Pre-flight check the DKIM record after migration
After completing a DNS migration, immediately query your DKIM record from a clean resolver (not your local machine). Verify it resolves correctly before sending any production email.
Monitor DKIM health during DNS change windows
This is the part most teams skip, and it costs them. You finish the DNS migration, everything looks correct when you check it, and then Monday morning a batch of invoices lands in spam. The problem is not that the DNS was wrong - it is that nobody was watching DKIM while the migration was in flight.
Set up DKIM authentication monitoring before any planned DNS change. When DKIM starts returning permerror or temperror during a migration window, you want an alert within minutes - not a delayed notification after a pile of emails has already been classified as spam. DMARCFlow monitors DKIM authentication results continuously and can alert you when failures start, so you can investigate and fix before deliverability is affected. The alert fires before the problem compounds, not after.
FAQ
How long does DKIM take to work after a DNS change?
If you are publishing a new DKIM record for the first time, it typically takes 5 minutes to 2 hours to propagate globally, depending on the TTL you set. If you are changing an existing DKIM record, propagation can take 24-48 hours in the worst case if resolvers have cached the old value with a long TTL.
Can DNS caching cause DKIM failures even after I fix the record?
Yes. If a recursive resolver cached the old DKIM record or an NXDOMAIN response before you fixed the record, it will keep serving the stale value until its cache expires. This is why lowering the TTL before making changes matters. For a record that is already broken and causing spam issues, the fastest fix is to lower the TTL, wait for propagation, and then make your change during a low-traffic window.
My DKIM record looks correct but emails still fail verification. What else could it be?
If the DNS record is fine but DKIM still fails, the problem may be on the signing side. Check whether your mail server is actually adding the DKIM signature header. Some mail servers only sign certain message types or require the signing domain to match the From: header exactly. Also check whether an intermediary (forwarding service, spam filter, or transport encryption gateway) is modifying the message body after signing, which invalidates the DKIM body hash.
I migrated DNS and DKIM broke. Should I switch DKIM selectors?
Switching selectors is a valid fix if you cannot get the old record to publish correctly, but it requires updating your email provider's DKIM configuration and waiting for the new selector to propagate. It is usually faster to fix the existing record first and treat selector switching as a last resort.