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

> DKIM CNAME records delegate your signing key to your provider so they rotate it for you. See how CNAME delegation works, how to set it up, and when to use TXT.

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.

## 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 `<selector>._domainkey.<domain>`. 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](/learning/what-is-a-cname-record) covers how aliases resolve; this article is about the DKIM-specific case.

![Example DKIM records published as CNAME delegation, aliasing two selectors to a provider-hosted signing host.](/images/figures/dkim-cname-records.webp)
*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](/learning/dkim-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](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy.html).

As a concrete example, Amazon SES [Easy DKIM](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses) 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](/learning/dkim-testing) walks through reading the `Authentication-Results` header, and the [DKIM checker tool](/tools/dkim) 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](/learning/check-dkim-record) 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](/learning/why-does-my-dkim-signature-fail-alignment) for the fix — it usually means enabling domain-aligned signing in the platform.

## Frequently asked questions

### Is a DKIM CNAME record less secure than a TXT record?

No. Receivers validate a CNAME-delegated key and a self-hosted TXT key identically, and a signed message passes DKIM the same way in both cases. The only practical difference is that with CNAME delegation you cannot see or set the key value yourself — the provider does.

### Can I have more than one DKIM CNAME record?

Yes, and it is normal. Providers typically publish two or three CNAMEs so they can rotate keys by activating a fresh selector without breaking the old one. Each points to a different target host. You can also run different selectors for different sending services on the same domain.

### Does Google Workspace use a DKIM CNAME?

No. Google Workspace generates a DKIM key and asks you to publish it as a **TXT** record at the `google._domainkey` selector, not a CNAME. CNAME delegation is more common with third-party ESPs and marketing platforms than with mailbox providers.

### Can I switch a selector from TXT to CNAME later?

Yes, but not at the same host simultaneously. Remove the existing TXT record for that selector, then add the CNAME, because one name cannot hold both. Test a live message after the change to confirm mail still shows `dkim=pass`.

## 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](/tools/email-security-score).

## Related reading

- [What is DKIM? DomainKeys Identified Mail explained](/learning/what-is-dkim)
- [How to check a DKIM record and interpret the result](/learning/check-dkim-record)
- [How and when to rotate DKIM keys](/learning/dkim-key-rotation)