DKIM Failing After Switching Email Tools: The CNAME and Selector Migration Guide (2026)

Опубліковано 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

DKIM breaks after a tool switch for two mechanical reasons: your DNS panel mangled the new tool’s CNAME targets — usually by appending your own zone — or the old tool’s selectors were removed before its mail drained. Only 3.87% of domains — 10,092,481 — complete the SPF+DKIM+DMARC triad, according to the Defaults.Exposed census of 261,086,232 graded domains.

The fix order: scan the domain, then check each new CNAME’s stored target with dig — a target ending in your own domain name is the smoking gun. Repair the records at the authoritative nameservers, confirm the new tool signs and passes before routing real mail through it, and keep the old tool’s selectors published until its traffic drains.

Why did DKIM break when you switched tools?

Nothing about DKIM itself changed — your selectors did. The old tool signed with its selectors; the new one signs with different ones, usually delegated via two or three CNAME records added during onboarding. Four gotchas account for nearly every post-migration DKIM failure:

Your DNS panel appended your zone to the CNAME target. Many panels treat any pasted hostname as relative and silently store target.provider.com.yourdomain.com instead of target.provider.com. The record exists, the panel shows a green tick, and it resolves to nothing.
Trailing-dot confusion. Some panels require a trailing dot (target.provider.com.) to mean “absolute — stop appending my zone”; others reject the dot as invalid and handle absoluteness themselves. The same pasted value is right in one panel and mangled in the next.
The old tool’s selectors were deleted on switch day. Mail the old tool already signed sits in retry queues and forwarding paths for days; removing its selectors — or closing the old account, which kills its delegated CNAMEs — breaks that mail retroactively.
You verified at the wrong nameservers. If the migration included a nameserver change, the fixed records may exist at one NS set while receivers still query the other.

Only 51.84% of the 261 million domains in the census present a discoverable DKIM key at scan time (data as of 2026-06-29).

The same migration usually leaves SPF debris too — 1,013,416 domains, roughly 1 in 138 of those attempting SPF, run two v=spf1 records, the classic sign that a provider switch added a record instead of merging one. That side of the move has its own guide: SPF stopped working after you switched email provider.

How do I spot a mangled CNAME record?

Don’t trust the panel — ask DNS what it actually stored. Query the CNAME target for each selector the new tool gave you. An illustrative example, mimicking a SendGrid-style delegated selector (your provider’s target shape will differ):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

The provider asked for s1.domainkey.u1234567.wl123.sendgrid.net — but the stored target ends in .yourdomain.com. The panel appended the zone; that name resolves to nothing, so receivers find no key. The healthy version:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(A single trailing dot in dig output is normal — it marks a fully-qualified name.) If the target is right, follow it one hop: dig TXT s1._domainkey.yourdomain.com +short should return the provider’s key. Empty answer with a correct CNAME means the problem is on the provider’s side of the delegation — finish their verification step, or see DKIM “no key for signature” for the selector-level diagnosis.

The migration runbook: before, during, after

The failure isn’t usually the records — it’s the order. DKIM migrations go wrong at cutover because verification happens after the switch, when real mail is already failing.

Phase	What to do	Gate before moving on
Before the switch	Add the new tool’s DKIM CNAMEs (and bounce-domain records), then prove them: `dig` each CNAME’s stored target from outside your network, complete the tool’s own verification step, and send a test through the new tool to a mailbox you control	Test message shows `dkim=pass` with `d=` = your domain — never route real mail through an unverified tool
Switch day	Move real traffic to the new tool. Touch nothing belonging to the old tool: leave its selectors, CNAMEs and account alive	New tool’s mail passes at real receivers; old tool keeps passing for anything still flowing through it
After the drain	Watch DMARC aggregate reports until the old tool’s selectors stop appearing (retry queues and forwards run for days — allow a week or more), then retire its records and account	Old selectors absent from reports ≥ 7 days before removal

The bold row is where migrations are saved or lost: every check in it can be done days before cutover, with zero risk to live mail. Selector-retirement mechanics — including why republishing with an empty p= beats deletion — are covered in the rotation runbook; this table is about sequencing the tool switch itself.

How do I fix DKIM after the switch?

Run the free scan at defaults.exposed before touching DNS. It reads your live records and shows what receivers actually see — including CNAME targets that got zone-appended and selectors that don’t resolve.
List the DKIM records the new tool expects. From its admin console — for mailbox providers, the Google Workspace and Microsoft 365 setup guides show where; newsletter and CRM tools list their CNAMEs under domain authentication (see Mailchimp/Brevo/Klaviyo emails failing DMARC).
Check each record’s stored value with dig CNAME <name> +short and compare it character-for-character with what the tool asked for. A target ending in your own domain = zone-appended; re-enter it, and if the panel keeps appending, add the trailing dot (or remove it, if the panel rejects dots).
Verify at the authoritative nameservers. dig +short NS yourdomain.com, then repeat the CNAME checks @<that nameserver>. If the migration changed nameservers, check both sets — receivers may still query the old one until delegation propagates.
Re-run the tool’s verification and send a test message. The Authentication-Results header should show dkim=pass with d= equal to your domain — a pass on the tool’s default domain doesn’t align for DMARC.
Leave the old tool’s selectors published until its mail drains, then retire them deliberately. Then re-scan, and work through anything else flagged on the fix DKIM page.

Frequently asked questions

Do I need the trailing dot on my DKIM CNAME or not? It depends entirely on the panel. The dot means “absolute name — don’t append my zone”; some panels require it, some add it for you, some reject it. The only test that matters is the output of dig CNAME <selector>._domainkey.yourdomain.com +short after saving: if the target ends in your own domain, the panel appended the zone and you need the dot (or a different input format).

Can I delete the old tool’s DKIM records on switch day? No. Mail the old tool signed is still in retry queues and forwarding paths, and deleting the key it points to breaks those messages retroactively. Keep the old selectors live until they stop appearing in your DMARC aggregate reports — a week or more — and don’t close the old account before then either.

My DNS panel and the new tool both say “verified”, but receivers still fail DKIM. How? Two common cases: the tool verified against a cached check while the authoritative nameservers serve something else (query them directly with dig @<ns>), or DKIM passes but on the tool’s default signing domain rather than yours, so DMARC still fails alignment. The scan distinguishes the two.

Can both tools’ DKIM records coexist during the overlap? Yes — and they should. DKIM has no single-record rule: each selector is its own DNS name, so both tools’ records live side by side without conflict, which makes the keep-old-selectors-through-the-drain rule free to follow. (SPF is the opposite — two v=spf1 records void it, which is why the SPF migration guide is about merging.)

Send the owner the report

If you’re running this migration for a client or your employer, close it with evidence. Once the new tool signs and aligns, re-run the free scan and forward the graded report to the business owner: dated, plain-language proof that the switch left the domain fully authenticated. It’s the artefact they’ll need for the cyber-insurance renewal and the next supplier security questionnaire — it turns “the migration is done” from a claim into a document.

Check your DKIM free

See whether your new tool’s selectors resolve — and exactly what to fix — privately and owner-only.

Check your domain → · SPF broke after switching provider → · Fix DKIM → · Set up DKIM on Google Workspace → · Aggregate data only. Data stored and processed in the EU.