DKIM broke after switching email tools

DKIM broke because your DNS records changed, and one of two things went wrong with them. Either the DNS panel stored a mangled target for the new tool’s selector, usually by gluing your own zone onto the end of the hostname you pasted, or the old tool’s selectors came down before the mail it had already signed finished arriving. Both show a green tick somewhere and both fail at the receiver. You can tell which one you have in a couple of minutes with dig, and you can fix either without touching a single message.

The switch changed your selectors, and that’s all it changed

Nothing in DKIM itself moved. The old tool signed with its selectors and the new one signs with different ones, normally delegated through two or three CNAME records you added during onboarding. Each selector is its own DNS name, so a migration is a small pile of new names that all have to resolve, and one that doesn’t is enough to fail the lot.

The first failure lives in the DNS panel. Many panels treat a pasted hostname as relative to your zone and store target.provider.example.yourdomain.com when you meant target.provider.example. The record exists, the panel shows it as saved and verified, and the name resolves to nothing, so a receiver looking up the key finds an empty answer.

The second failure is timing. On switch day someone tidies up: the old tool’s selectors get deleted, or the old account gets closed, which removes the CNAMEs it was hosting for you. Messages the old tool signed last week are still sitting in retry queues and forwarding paths, and each one now points at a key that has gone. That mail fails retroactively, days after you thought the move was finished.

A third case hides behind the first two. If the migration also changed nameservers, the corrected records can exist at one nameserver set while receivers are still querying the other. You fixed it, you tested it, and the receiver never saw the fix.

Ask DNS what it stored

Don’t trust the tick. Query the CNAME target for each selector the new tool gave you and read the answer character by character. Here’s the shape of a broken one, with a generic provider target standing in for whatever yours looks like:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.mail.provider.example.yourdomain.com.

The tool asked for s1.domainkey.u1234567.mail.provider.example. The stored target ends in .yourdomain.com, which means the panel appended your zone, and that name has no key behind it. The healthy answer looks like this:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.mail.provider.example.

A single trailing dot in dig output is normal; it marks a fully qualified name. What you’re looking for is your own domain glued onto the end of the provider’s hostname, and it’s either there or it isn’t.

The trailing dot is also why the same pasted value works in one panel and breaks in the next. A trailing dot means “this name is absolute, stop appending my zone”. Some panels require it, some add it for you, and some reject it as invalid and handle absoluteness on their own. If the stored target came back with your zone on the end, re-enter the value with the dot; if the panel rejects the dot, re-enter it without one and read the stored value again. The test after saving is the same dig command, and the panel’s own display of the record doesn’t count as a test.

If the CNAME target is correct, follow it one hop:

$ dig TXT s1._domainkey.yourdomain.com +short

That should return the provider’s key. A correct CNAME with an empty TXT answer means the delegation is unfinished on the provider’s side, and the fix is to complete their verification step in the admin console rather than to change anything in your DNS. If you’re not certain which selector names the new tool signs with, find your DKIM selector from a message header first.

Check at the nameservers receivers are using

A dig from your laptop asks your local resolver, which may be answering from cache or from the nameserver set you left behind. Find the authoritative servers and ask them directly:

$ dig +short NS yourdomain.com

Then repeat the CNAME check with @<that nameserver> on the end, once for each server the NS answer lists. If the migration changed nameservers, run the checks against both the old set and the new one. A nameserver change at the registrar can take a day or two to reach every resolver, and until it does, some receivers will keep asking the old servers for records that only exist at the new ones.

The same applies to a corrected CNAME. Resolvers that cached the zone-appended version keep serving it until its TTL runs out, so a fix you made an hour ago can still fail at a receiver that looked the name up yesterday. Read the TTL off the old record before you change it and treat that as the minimum wait before you believe a test result.

Prove the new tool signs before it sends anything real

Send a test through the new tool to a mailbox you control and open the full headers. The line you want is Authentication-Results, and it has to show dkim=pass with d= equal to your domain:

Authentication-Results: mx.receiver.example; dkim=pass header.d=yourdomain.com

A pass on the tool’s default signing domain is a pass for the tool and nothing for you. DMARC checks whether the d= in the signature aligns with the domain in the From address, so a signature under the provider’s own domain leaves your DMARC evaluation resting on SPF alone, and forwarded mail loses that too. The DMARC pillar covers alignment in full; for this fix, the rule is that d= has to say your domain.

The panel and the tool can both report “verified” while receivers still fail. Either the tool verified against a cached lookup while the authoritative servers serve something else, or DKIM passes under the tool’s default domain and DMARC fails on alignment. The header tells you which one you’ve got.

The fix, in order, with the waits built in

Migrations go wrong at cutover because verification happens after the switch, when real mail is already failing. Run it in this order and the checks that matter happen days before any real message moves.

Collect the records the new tool expects. They’re in its admin console; newsletter and CRM tools list them under domain authentication. Add the DKIM CNAMEs and the bounce-domain records at the same time, since the bounce domain is what the tool’s SPF will be judged on.
Save them, then dig each stored target from outside your network and compare it with what the tool asked for. A target ending in your own domain is zone-appended; fix it with or without the trailing dot, whichever your panel demands. Wait out the TTL of any record you replaced before you test again, and allow a day or two on top if nameservers changed.
Complete the tool’s own verification step. Move on when the tool reports verified and dig TXT on each selector returns a key.
Send a test to a mailbox you control. Move on when Authentication-Results shows dkim=pass with d= your domain. Until that line appears, no real mail goes through the new tool.
On switch day, move real traffic to the new tool and touch nothing belonging to the old one: leave its selectors, its CNAMEs and its account alive. Move on when the new tool’s mail passes at real receivers and the old tool keeps passing for anything still flowing through it.
Once real mail has moved, watch your DMARC aggregate reports until the old tool’s selectors stop appearing. Retry queues and forwards run for days, so allow a week or more. Move on when the old selectors have been absent from reports for at least 7 days.
Retire the old tool’s records and account deliberately, then run the free scan. It reads the live records and shows you any selector that still resolves to nothing, along with whatever else on the DKIM pillar is left to do.

The census suggests how often the last two steps get skipped or the first four get rushed. Of the 75,823,110 domains where the September 2026 census could run its DKIM check, 37,999,462 (50.1%) presented a discoverable selector. Of the 316,600,902 domains carrying a grade, 7,862,126 count as fully protected on email. A tool switch done in the order above leaves you in that second group; done in the other order it leaves you with a week of bounces and a panel that still says verified.

Both tools’ selectors can stay up together

DKIM has no single-record rule. Each selector is its own DNS name under _domainkey, so the old tool’s s1 and the new tool’s k1 publish side by side without conflict, and a receiver reads whichever one the signature names. That’s what makes the keep-the-old-selectors rule free to follow: leaving them published through the overlap costs nothing and takes them off the list of things that can break.

So the order of work is the whole fix. Add the new selectors, read back what the panel stored, ask the authoritative servers, get dkim=pass under your own domain on a test, and only then move real mail. Leave the old tool alone until its selectors have been out of your DMARC reports for a week, and retire them on purpose rather than by accident.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.