A DKIM key is always published as a TXT record. When you see a provider tell you to add a CNAME at your selector, that CNAME is not the key. It is a pointer that delegates the lookup to a record your email provider hosts, so the actual TXT record still sits at the end of the chain on their DNS servers. Use a TXT record when you want to own and manage the key yourself. Use a CNAME when you want your provider to rotate keys for you without you touching DNS again.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Both approaches end at the same place: a resolver following selector._domainkey.yourdomain.com needs to arrive at a TXT record that contains a DKIM public key. The only question is who holds that TXT record and who is allowed to change it.
The one fact that clears up the confusion
DKIM verification, defined in RFC 6376, works by having the receiving mail server fetch a public key from DNS. That key is published in a TXT record at a very specific name: the selector, followed by the literal label _domainkey, followed by your domain. So for a selector named s1 on example.com, the record name is s1._domainkey.example.com.
The value in that TXT record looks like this:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
The p= tag holds the base64 public key. That is the thing a receiver actually needs. It never lives in a CNAME. A CNAME cannot carry a p= value at all, because a CNAME's only job is to say "this name is an alias for that other name, go look there instead."
So when a provider gives you a CNAME to add, they are saying: point your selector at our hostname, and we will publish and maintain the TXT record on our side. The receiver's resolver follows your CNAME, lands on the provider's record, and reads the key from there. From the receiving server's point of view the result is identical. The difference is entirely about control and maintenance.
TXT: you own the key
With a raw TXT record, you paste the full DKIM public key into your own DNS zone. You generated it (or your provider handed you the value), and it now sits in a record you control.
This is the right choice when:
- You run your own mail server or MTA and generate your own key pair.
- Your provider gives you a TXT value to paste rather than a CNAME target.
- You want the key visible and auditable in your own zone file, with no dependency on a third party's DNS for the key contents.
- You are managing multiple selectors on one domain by hand and want each one explicit.
The cost is that you own rotation too. When it is time to roll the key, you generate a new pair, publish a new selector's TXT record, switch your signer to the new selector, and later retire the old one. Nothing rotates unless you do it. If you go this route, keep a real schedule, which we cover in DKIM key rotation.
CNAME: your provider owns rotation
With CNAME delegation, you add records like this:
s1._domainkey.example.com. CNAME s1.dkim.provider.net.
You never see the key. The provider publishes the actual TXT record at s1.dkim.provider.net and keeps it current. When they rotate keys, they change the TXT record on their side and your CNAME keeps pointing at the same alias, so the new key is picked up with zero action from you.
This is the right choice when:
- Your email service provider (most large senders like SendGrid, Amazon SES, Mailchimp, Klaviyo and similar) hands you CNAME targets during setup.
- You want automatic key rotation without a DNS change every time.
- You would rather not store or manage key material yourself.
Most managed providers default to CNAME delegation precisely because it lets them rotate keys on their own schedule to keep signatures healthy. If you are following a provider walkthrough such as SendGrid domain authentication, the CNAME rows you are told to add are exactly this delegation pattern.
Side by side: which is right for you
| Factor | TXT record | CNAME delegation |
|---|---|---|
| What you publish | The full public key (p=...) | An alias to the provider's hostname |
| Who rotates the key | You, manually | Your provider, automatically |
| Where the key lives | Your DNS zone | Provider's DNS zone |
| Best for | Self-hosted mail, custom keys, full audit control | Managed ESPs, hands-off maintenance |
| Main risk | Forgetting to rotate | Provider misconfiguration or broken chain |
| Change on key roll | Add a new selector TXT yourself | None, provider handles it |
Neither is more secure in cryptographic terms. The same RSA or Ed25519 key protects the mail either way. The trade is control versus convenience.
Nested CNAME resolution gotchas
The most common failures with delegation are chain problems, not key problems.
A CNAME cannot sit next to other records
At the exact name selector._domainkey.example.com, you can have a CNAME or a TXT, never both. DNS rules forbid a CNAME coexisting with any other record type at the same name. If you add a CNAME for delegation and also paste a TXT key at the same selector, resolvers will treat the zone as broken. Pick one per selector.
Chains must actually terminate at a TXT
Providers sometimes point their first hostname at a second one, so the resolver walks CNAME to CNAME before reaching the final TXT. That is legal. The problem is when a middle link is broken, expired, or points at a host that no longer publishes the key. Every hop has to resolve, and the last hop has to be a TXT with a valid p= value. If any link returns NXDOMAIN, the whole chain fails and DKIM is treated as if there is no key.
Watch for trailing dots and appended domains
When your DNS panel asks for the CNAME target, some panels append your domain automatically. If the target should be s1.dkim.provider.net and your panel silently makes it s1.dkim.provider.net.example.com, the alias points nowhere. Enter the fully qualified target exactly as the provider gives it, and confirm the final saved value.
CNAME flattening at the apex is irrelevant here
DKIM selectors are never at the zone apex, so the flattening some DNS hosts apply to root records does not affect _domainkey names. You do not need it, and you should not enable anything that rewrites these records.
Check what actually resolves at your selector
Do not trust the provider dashboard alone. Verify what a receiver sees. From a terminal you can trace the chain:
dig +short s1._domainkey.example.com CNAME
dig +short s1._domainkey.example.com TXT
The first command shows whether a CNAME exists and where it points. The second follows the chain and prints the final TXT value, which should start with v=DKIM1 and carry a p= key. If the CNAME lookup returns a hostname but the TXT lookup returns nothing, your delegation is pointing at a dead target and receivers will fail your DKIM.
Running our scanner does the same walk for you and grades the result, so you can see at a glance whether the key that resolves is valid, which is faster than reading raw dig output. If the key resolves but mail still fails DKIM, the problem is usually signing or alignment rather than the record type, which we break down in fix DKIM alignment.
Frequently asked questions
Is a DKIM record a CNAME or a TXT?
The key itself is always a TXT record. A CNAME is only ever a pointer that delegates the lookup to your provider, who publishes the real TXT record on their side. Both are valid setups, but the public key never lives inside a CNAME.
Can I switch from CNAME to TXT later?
Yes. Delete the CNAME at that selector, then add a TXT record at the same name with the full v=DKIM1; k=rsa; p=... value. You cannot keep both at the same selector, so remove one before adding the other, and wait for DNS to propagate before you rely on it.
Why does my provider only give me a CNAME?
Because it lets them rotate keys for you without you editing DNS again. Managed senders prefer delegation so a key roll on their side is invisible to you and your signatures stay valid. It is a maintenance convenience, not a security requirement.
How do I know which one is actually live?
Query the selector directly. dig s1._domainkey.example.com CNAME shows any alias, and dig s1._domainkey.example.com TXT shows the final key the chain resolves to. If the TXT lookup returns a value starting with v=DKIM1, that is the key receivers will use.