Is DKIM more secure as a TXT or a CNAME record?

Neither is inherently more secure, both publish a public key in DNS. TXT keeps the key in your own zone, which some security policies require. CNAME delegates to your provider so they can rotate keys without you touching DNS. Pick based on who should manage rotation.

Can I use a CNAME for DKIM on my root domain?

You don't need to worry about that restriction. DKIM records always live on a subdomain (selector._domainkey.yourdomain.com), never the apex, so the rule against CNAMEs at the root domain doesn't apply to DKIM setup.

Why did my DKIM suddenly stop passing?

Common causes are a provider rotating a key while your TXT record stayed stale, a CNAME whose target record was removed, or a DNS edit that deleted the selector. In CNAME setups the break is often on the provider's end; monitoring the record's resolution is the fastest way to catch it.

DKIM CNAME vs TXT Records: Which Does Your Provider Use

VigilDog Team · September 25, 2026 · 7 min read

When you set up DKIM for a sending service, the exact records it asks you to add vary in a way that trips people up: some hand you a long TXT record to paste in, others give you a short CNAME that points somewhere else entirely. Both authenticate your mail. The difference in DKIM CNAME vs TXT is really about who holds the signing key and who rotates it, and knowing which model your provider uses tells you what can silently break later.

A quick DKIM refresher

DKIM lets a receiving mail server verify that a message was signed by your domain and wasn't tampered with in transit. Your outbound mail carries a signature; the receiver looks up your public key in DNS to check it. That public key lives at a predictable location: selector._domainkey.yourdomain.com, where 'selector' is a label the sender chooses (like s1, google, or selector1).

The only question is how that public key gets published at that location. There are exactly two ways: put the key there directly as a TXT record, or put a CNAME there that delegates the lookup to a record your provider controls. Everything else about DKIM is the same.

The TXT approach: you publish the key

With the TXT model, your provider generates a keypair and gives you the public key as a text string. You create a TXT record at selector._domainkey.yourdomain.com containing something like v=DKIM1; k=rsa; p=MIGfMA0G...(a long base64 blob). The key now physically lives in your DNS zone, under your control.

The tradeoff is rotation. When the key needs to change, a new selector, a longer key, a security refresh, you have to update the TXT record yourself. If your provider rotates keys and you don't update DNS in step, signatures start failing. Google Workspace is the best-known example of this model: you generate the key in the Admin console and paste a TXT record at google._domainkey.

The CNAME approach: you delegate to the provider

With the CNAME model, you don't publish the key at all. You add a CNAME at selector._domainkey.yourdomain.com that points to a hostname on the provider's domain, and the provider publishes the actual TXT/key record over there. When a receiver looks up your selector, DNS follows the CNAME to the provider's record and reads the key from it.

The payoff is hands-off rotation: because the provider owns the target record, they can rotate keys whenever they need to and your DNS never changes. This is why most third-party sending platforms prefer CNAME delegation. The catch is that you're trusting the provider to keep that target record healthy, and if you ever remove the CNAME, DKIM breaks instantly.

How a domain name resolves to a server

Which providers use which

It's easier to plan a setup when you know the pattern each service follows. Broadly, mailbox providers lean toward TXT and specialized sending platforms lean toward CNAME delegation, but always confirm against your provider's current setup screen.

Google Workspace, TXT (you paste the key at google._domainkey)
Microsoft 365, CNAME (two records: selector1 and selector2 pointing to your onmicrosoft.com tenant)
Amazon SES (Easy DKIM), CNAME (three records delegating to amazonses.com)
SendGrid, CNAME (s1._domainkey and s2._domainkey)
Mailchimp / Mandrill, CNAME delegation
Postmark, TXT by default, with a CNAME option to enable automatic key rotation

The tradeoffs that actually matter

Choose based on who you want doing key rotation. CNAME delegation means the provider handles it and your DNS stays stable, great for platforms you don't want to babysit. Direct TXT means you own the key outright, which is what some security teams require, at the cost of doing rotations yourself. Neither is 'more secure' in a meaningful sense; both publish a public key in DNS.

One practical gotcha: a naked/apex domain can't be a CNAME, but DKIM records always live on a subdomain (selector._domainkey), so that classic restriction doesn't apply here. The real failure modes are subtler, a CNAME that points at a provider record that later disappears, or a TXT key the provider rotated while your record went stale. Both fail the same way from a receiver's view: no valid signature.

Verify it, then keep watching it

After setup, confirm the record resolves the way you expect. For a TXT setup, a dig TXT selector._domainkey.yourdomain.com should return the key. For a CNAME setup, dig CNAME selector._domainkey.yourdomain.com should show the delegation, and following it should land on a valid key. If DKIM interacts with SPF and DMARC in ways you're still untangling, our guide to fixing SPF, DKIM, and DMARC walks through how the three fit together.

The hard part isn't the initial setup, it's noticing months later when a provider rotates a key, a CNAME target goes missing, or someone edits the wrong record during a DNS cleanup. That's exactly what VigilDog's email deliverability monitoring watches for: it checks that your DKIM records still resolve and validate, alongside SPF and DMARC, so a silent break turns into an alert instead of a deliverability mystery.