How DKIM breaks over time

Whether your DKIM setup survives the next few years is mostly decided by one detail you probably never chose deliberately: whether the record in your DNS is a CNAME pointing into your provider's DNS, or a static TXT copy of a key. The CNAME setups sail through events that kill the TXT setups on the spot. Almost every DKIM failure I see on long-running domains traces back to that fork, or to a DNS cleanup that didn't know what _domainkey meant.

From DKIM, explained you know the shape: the public key lives in DNS at selector._domainkey.yourdomain.com, the provider signs each message with the private half, and receivers fetch the public half to verify. The question for this lesson is narrower. How does a key that verified perfectly in year one stop verifying in year three?

CNAME or TXT: the fork that decides

There are two ways a provider's key ends up reachable under your domain.

The first is delegation. Your record is a CNAME, a DNS alias that says "the answer lives over there". MailerLite's is a clean example: ml._domainkey.yourdomain.com points at a record on mlsend.com, inside MailerLite's own DNS. When a receiver looks up your selector, the alias forwards them to the provider, and the key they fetch is whatever the provider is publishing at that moment. Mailchimp works the same way (k1._domainkey pointing at dkim.mcsv.net), as do Klaviyo's km1/km2 records on klaviyodns.com and beehiiv's s1/s2 records into SendGrid's DNS.

The second is a static copy. The provider generates a keypair, shows you a long block of text (the public key), and you paste it into your zone as a TXT record. On day one, both approaches verify identically. There is no functional difference a checker can see.

The difference is entirely about time. Providers rotate keys: they retire a signing key and start signing with a fresh one, which is basic hygiene, because a private key that never changes is a private key with years of exposure behind it. Under a delegated CNAME, rotation is invisible to you. The provider swaps the key at their end of the alias, your record never changes, verification never blinks, and you never even hear it happened. Under a static TXT, your pasted copy is frozen at the moment you pasted it. The day the provider's signer moves to a new key, signatures stop matching the record you published, and every message starts failing verification.

The detail that makes this decay rather than breakage: your DNS still looks perfect. The TXT record is well-formed, the right length, at the right name. Every casual inspection says "DKIM is set up". It just validates nothing anymore.

Keys regenerated behind your back

Rotation is scheduled. Regeneration is incidental, and it's the sneakier version.

Provider-side account events can mint a new keypair without anyone framing it as a DKIM change: a plan migration, an account merge after an acquisition, support moving you between platform versions, or someone deleting and re-adding the sending domain in the dashboard as a troubleshooting reflex. With a delegated CNAME into infrastructure that stays yours, this is usually survivable. With a static TXT, the new server-side key orphans your pasted record instantly.

And the timeline hides it. The account migration happens Tuesday. Your newsletter goes out Friday. Friday's send folders, and the investigation starts from "what's wrong with this campaign?" instead of "what did support do Tuesday?", because nobody involved believes a billing-plan change touches DNS.

One caution for the CNAME crowd, so this doesn't read as a free pass: some providers issue per-account CNAME targets rather than shared ones. Kit's verified sending domain works this way, with your cka._domainkey record pointing at a target specific to your account. Delegation like that is only as durable as the account it points into; recreate the account and the old alias can point at nothing that's yours.

Selector generations

Providers rename their selectors across account generations, and the old names linger in customer DNS like fossils.

Real, sourced examples from the table our checkers run on: Brevo's newer accounts use brevo1/brevo2 where earlier generations used mail/mail2. MailerLite's older accounts used a mailerlite selector before the current ml. Mailchimp is k1 for most accounts, with k2/k3 appearing on some. Constant Contact goes further than any of them and issues per-account numeric selectors, so no fixed list of names can enumerate what a given account was assigned.

Why this is a rot mode rather than trivia: records and instructions from one generation keep meeting accounts from another. You migrate plans, or the provider migrates its platform, and new records get issued under new names while the old-name records sit in your zone looking healthy. Now your DNS contains selectors that verify nothing, you diagnose against a help article written for the other generation, and you conclude you're configured when you're not (or that you're broken when you're fine).

This is also an honest limitation of DNS-only checking, ours included. Because Constant Contact's selectors are per-account, our checker's verdict for a zero-match domain deliberately reads "not found at the usual names" rather than "broken". From public DNS alone, nobody can tell those apart. The proof that settles it is a delivered email, which is why the path-level DKIM check on a real message outranks any selector probe (how that works: checks explained).

The _domainkey purge

The fourth mode is the same migration wipe that kills SPF records, aimed at stranger-looking targets.

To whoever is rebuilding a zone at a new DNS host, s1._domainkey reads like nothing. It has no visible connection to the website or to mail routing, and deleting it breaks nothing anyone can see that afternoon. So it gets dropped, or the import tool skips it. The provider keeps attaching signatures to every message it sends for you; receivers just can't find the key to check them against anymore, and verification fails on mail that is completely legitimate.

Re-entering the records by hand at the new host has its own trap, one our Mailchimp checker sees regularly: some DNS interfaces silently append your domain to whatever you type in the name field, so entering the full k1._domainkey.yourdomain.com creates a record that actually answers at k1._domainkey.yourdomain.com.yourdomain.com. (You met this trap in the overview lesson; a post-migration re-entry is the moment it usually springs.) beehiiv setups have a cousin of this after a move to Cloudflare: their records must be plain DNS entries, and leaving Cloudflare's proxying enabled on them breaks verification even though the records are "there".

A note on how loudly any of this fails. DMARC passes when either aligned leg passes. Most ESPs use their own envelope domain, which means SPF doesn't align with your From domain and DKIM is your only aligned leg (the full logic is in authentication alignment). For those setups, DKIM dying is DMARC dying, same day. If you do have aligned SPF as well, a dead DKIM key can hide behind it for months instead, and surface only when SPF has its own bad week.

What to actually do with this

Prefer delegation wherever a provider offers it, know which of your records are static copies, and treat any account-level event at a provider as a reason to re-verify. Verification from outside is cheap: the free health check probes the common selector names on your domain right now, and a monitored test send proves the signature end to end.

DKIM rot happens in DNS. How DMARC drifts covers a slipperier kind: the policy layer falling out of sync with what actually sends, watched over by reports nobody reads.

Terms from this lesson

• delegated CNAME - a DKIM record that's an alias into the provider's own DNS, so the provider can rotate keys without you touching anything.
• static TXT key - a pasted copy of a provider's public key in your zone. Frozen at paste time; it fails the day the provider's signing key changes.
• key rotation - a provider retiring a signing key and starting to sign with a new one. Routine hygiene that only breaks setups holding stale copies.
• key regeneration - a new keypair created as a side effect of an account event (migration, merge, domain re-add) rather than on a schedule.
• selector generation - the set of selector names a provider issued during one era of its platform. Different account generations get different names.
• fossil selector - a DNS record for a selector the provider no longer signs with. Looks healthy, verifies nothing.

Check yourself

1. Why does a CNAME-delegated DKIM record survive provider key rotation while a static TXT copy doesn't?

The CNAME resolves to whatever key the provider currently publishes, so rotation happens at their endCNAMEs are cached longer by receiversStatic TXT records have a shorter maximum lengthReceivers skip verification for CNAME records

2. A domain's DKIM record is well-formed, correctly named, and has verified for years, yet mail now fails verification. Which cause fits?

The record's TTL expiredDKIM records must be re-signed annuallyThe selector name is case-sensitive and the receiver changed casingThe provider regenerated the signing key after an account migration, orphaning the pasted copy

3. Why can't a DNS-only check definitively say a Constant Contact domain has DKIM misconfigured?

Constant Contact blocks DNS queries to its selectorsConstant Contact doesn't support DKIMConstant Contact issues per-account numeric selectors, so fixed-name probes can miss a correctly configured domainDKIM records are encrypted in DNS

4. For a typical ESP that uses its own envelope domain, what happens to DMARC the day the DKIM key record is lost?

Nothing, DMARC only evaluates SPFDMARC fails, because DKIM was the only leg aligned with the From domainDMARC keeps passing on the unaligned SPF resultDMARC downgrades to p=none automatically