DKIM CNAME and TXT conflict at the same selector after a provider change

Why this is a DNS conflict before it is a DKIM problem

A CNAME record aliases one DNS name to another and, by DNS rules, is not meant to coexist with other data at the same owner name. A DKIM TXT key also needs that exact owner name. If both are left at selector1._domainkey.example.com, you have created an ambiguous or invalid DNS state before a receiver even applies DKIM semantics. The correct design is not to ask receivers to choose between the TXT and CNAME. Give each active signing key a clean selector name with one coherent resolution path.

Read the selector from a real signature

Do not troubleshoot by guessing which DNS label the provider uses. Send or retrieve a real message, find DKIM-Signature, and record s= plus d=. The lookup name is s._domainkey.d. Query that exact name for TXT and CNAME answers. This is especially important during migrations because the visible From domain may be the same while the signing domain or selector changed. A provider dashboard that says “selector1” is not proof that every production message is currently using selector1.

dig CNAME selector1._domainkey.example.com +short
dig TXT selector1._domainkey.example.com +short

Decide which system owns the selector

Map the existing TXT key to the signer that created it. If the old provider is still sending queued or live mail with that selector, deleting the record immediately can break those signatures. If the new provider can use a different selector, prefer that path: publish the new CNAME under the new selector, validate it, then switch signing. If the new provider insists on the same label, schedule a controlled cutover and understand the queue overlap. The selector is effectively a versioned key identifier, so treat ownership explicitly.

Do not “merge” DKIM keys

SPF mechanisms can be combined into one policy, which sometimes trains operators to expect the same for DKIM. DKIM is different. Two public keys cannot be concatenated into one p= value, and a TXT key cannot be combined with a CNAME target. Each signature points to one selector and expects the key material found through that name. Multiple providers are supported by multiple selectors, not by multiple records at one selector. Keeping this mental model prevents a large class of migration mistakes.

TXT and CNAME differ operationally, not in the signature itself

With TXT, you publish the public key directly. With a provider-hosted CNAME, your selector points to a provider-controlled name that ultimately resolves to the key. Receivers still obtain a DKIM public key for the selector referenced in the signature. CNAME can make provider-managed rotation easier because the provider can update its target without asking you to edit the selector record. TXT gives you direct control. Neither choice fixes alignment automatically; the d= domain in the actual signature still has to align for DMARC.

Migration sequence with minimal ambiguity

If possible, create newprov._domainkey as the new provider’s CNAME while oldprov._domainkey remains the old TXT key. Confirm the CNAME chain resolves and the provider begins signing with s=newprov. Keep oldprov published while old-signed mail can still arrive. Once headers show only the new selector and the overlap window has passed, retire oldprov. This avoids ever having to replace record type at the same owner name during active traffic and gives you a clean rollback if the new signer fails.

Watch for DNS-panel conveniences that hide the real name

Registrars differ in how they display hostnames. Some expect only selector._domainkey in the host field and automatically append the zone; others show the full FQDN. A common migration error is publishing selector._domainkey.example.com.example.com or putting the CNAME target in the host field. Always verify with an external DNS query. The user interface is only an input method; the authoritative answer seen by receivers is what determines verification.

Finish with receiver-side proof

After DNS cleanup, send a fresh message through the new provider and inspect Authentication-Results. Confirm DKIM passes, s= points to the intended selector, d= is the intended signing domain, and DMARC passes through aligned SPF or DKIM. Save one raw header as the migration evidence. If the provider later changes its hosted key behind the CNAME, you can compare the current DNS chain with that known-good message instead of reconstructing the original setup from memory.

Make selector ownership explicit before a provider switch

A selector should have one clear DNS owner. Some providers ask you to publish a TXT public key directly; others ask for a CNAME that points the selector name into provider-controlled DNS. A DNS name with a CNAME is not supposed to coexist with ordinary data at that same owner name, so leaving an old TXT key beside a newly added CNAME is not a legitimate way to support both providers. Resolver behavior, DNS control panels, and validation tools can make the resulting state look confusing even though the architectural error is straightforward: two incompatible publication models are competing for one selector name.

Avoid that conflict by allocating provider-specific selectors before migration. For example, keep `old2025._domainkey` for the retiring signer and publish `outbound2026._domainkey` for the new one. Confirm that the new signer actually emits `s=outbound2026` on received mail before changing or deleting the old selector. If the provider insists on a fixed selector already in use, schedule an explicit cutover and preserve the old key long enough for in-flight messages; do not improvise a TXT+CNAME combination. Your DNS inventory should record selector, provider, record type, signing domain, creation date, and retirement state. With that ownership table, a future DNS cleanup is much less likely to break authentication accidentally.

Field checklist

• Extract s= and d= from a real DKIM-Signature.
• Query both CNAME and TXT at the exact selector name.
• Use different selector names for different active providers when possible.
• Never concatenate DKIM public keys or stack CNAME and TXT at one name.
• Verify the authoritative DNS answer after any control-panel edit.
• Confirm receiver-side DKIM and DMARC results after migration.