What is a DKIM CNAME record and how do you set it up?

A DKIM CNAME record is an alias you publish at selector._domainkey.yourdomain.com that points to a hostname your sending provider controls, where the actual public key lives as a TXT record. When a receiver verifies a message, its resolver follows the CNAME to the provider's DNS and reads the key there. The point is delegation: the provider can rotate, lengthen, or replace the key by editing the TXT record on their side, and your DNS never has to change. Most email service providers set DKIM up this way — you publish a few CNAMEs once and they manage the key behind them.

At a glance

Quick takeaways

• A DKIM key is always a TXT record at heart; a CNAME just delegates to where that TXT is hosted.
• You publish the CNAME at selector._domainkey.yourdomain.com; it points to a host the provider owns.
• The big win is automatic key rotation — the provider updates the key without touching your DNS.
• Providers like Amazon SES and SendGrid use CNAME delegation; Google Workspace hands you a TXT to paste instead.
• A name that holds a CNAME can hold no other record — you cannot keep an old DKIM TXT at the same host.
• CNAME delegation trades a little visibility for zero-maintenance signing; both approaches pass DKIM identically.

How does a DKIM CNAME record work?

DKIM verification always ends at a TXT record. The signature on a message carries a selector (s=) and a signing domain (d=), and the receiver looks up the public key at ._domainkey.. Whether that lookup lands on a TXT you host or a TXT your provider hosts makes no difference to the result — the receiver just needs to resolve a valid key.

CNAME delegation inserts one hop. Instead of publishing the key yourself, you publish a CNAME:

• The receiver queries sel1._domainkey.yourdomain.com.
• DNS returns a CNAME pointing to, say, sel1.dkim.provider.net.
• The resolver follows the alias and reads the real TXT key from the provider's zone.

Because the key physically lives in the provider's DNS, the provider owns its lifecycle. That is the whole reason CNAME delegation exists: you delegate control of the key so the people running your sending infrastructure can maintain it. If you want the underlying mechanics of the alias itself, our explainer on what a CNAME record is covers how aliases resolve; this article is about the DKIM-specific case. The values are example-shaped — your provider gives you the exact selector names and targets.

DKIM CNAME vs TXT: which should you use?

Neither is "more secure" — a receiver validates a CNAME-delegated key and a self-hosted TXT key exactly the same way. The choice is about who maintains the key.

• Use CNAME delegation when a provider offers it. If your ESP signs your mail, let them host the key. They handle key rotation, length upgrades, and recovery from a key exposure by editing their own TXT — you never re-touch DNS. This is the low-maintenance default for platform-sent mail.
• Use a self-hosted TXT when you control signing or the provider only gives you a key string. Google Workspace, for instance, generates a DKIM key and asks you to publish it as a TXT record — there is no CNAME to delegate to. Self-hosting also gives you full visibility: you can read the exact key in your own zone at any time.

The tradeoff with CNAME delegation is visibility and control. You are trusting the provider to keep a valid, adequately long key at the target; you cannot see or set the key value yourself. For most teams that is a fair trade for never having to think about rotation again.

How do you set up a DKIM CNAME record?

The provider generates the selectors and targets; your only job is to publish the aliases in DNS. The flow is the same across platforms:

1. Enable DKIM in the sending platform. In your ESP's domain-authentication settings, turn on DKIM (sometimes labelled "authenticate domain" or "Easy DKIM"). The platform returns one or more CNAME records.
2. Copy each CNAME exactly. You will get a host (the left side, e.g. sel1._domainkey.yourdomain.com) and a target (the right side, e.g. sel1.dkim.provider.net). Providers usually give two or three.
3. Add them at your DNS host. Create a record of type CNAME, paste the host into the name field and the target into the value field. Do not add quotes, and do not wrap the target in anything.
4. Wait for propagation, then verify. The platform re-checks DNS and flips the domain to "verified" once it sees the records. Amazon SES, for example, looks for its three CNAMEs and can take up to 72 hours to detect them, per the AWS Easy DKIM documentation.

As a concrete example, Amazon SES Easy DKIM publishes three CNAMEs shaped like token._domainkey.example.com → token.dkim.amazonses.com. SendGrid delegates two DKIM selectors (s1 and s2) the same way. In both cases you paste the aliases once and the provider owns the keys from then on.

Once the records resolve, confirm the key is actually being used by testing a live message rather than trusting the dashboard — our guide on testing and verifying DKIM walks through reading the Authentication-Results header, and the DKIM checker tool resolves a selector on demand.

Common issues with DKIM CNAME records

The provider still shows the domain as unverified

Almost always a propagation or copy-paste problem. Confirm the CNAME resolves with a DKIM record lookup against the exact selector host the provider gave you. Give DNS time to spread — minutes usually, but up to the TTL on your zone. If it still fails after a few hours, re-check that the host and target match the platform's values character for character.

Your DNS host appended your domain twice

Many DNS editors auto-append the zone name to whatever you type in the name field. Paste sel1._domainkey and the editor may store sel1._domainkey.yourdomain.com, which is correct — but paste the full sel1._domainkey.yourdomain.com and you can end up with sel1._domainkey.yourdomain.com.yourdomain.com. If the selector will not resolve, check for a doubled domain and enter just the host portion.

You already had a DKIM TXT record at that selector

A single name cannot hold both a CNAME and any other record type — that is a hard rule of DNS. If you are migrating a selector from a self-hosted TXT key to CNAME delegation, delete the old TXT first. Leaving both in place is a conflict your DNS host will usually reject, and if it does not, resolution is undefined.

DKIM passes but DMARC still fails

A delegated key can verify perfectly while DMARC still fails, because DMARC also requires alignment: the signing domain (d=) has to match your From: domain. If the provider signs with its own domain rather than yours, you get dkim=pass but dmarc=fail. See why a DKIM signature fails alignment for the fix — it usually means enabling domain-aligned signing in the platform.

Where Palisade fits

When mail leaves your domain through several platforms — an ESP, a CRM, a ticketing tool — each one publishes its own DKIM records, some as CNAME delegations and some as TXT, and it is easy to lose track of which selectors are live, aligned, and still signing. Palisade discovers every sending service on your domain, keeps SPF, DKIM, and DMARC correct across all of them, and flags a selector that stops verifying before it dents your deliverability. Check where your domain stands now with the Email Security Score.

Related reading

• What is DKIM? DomainKeys Identified Mail explained
• How to check a DKIM record and interpret the result
• How and when to rotate DKIM keys