DKIM Records: TXT vs CNAME — Which to Use?

DKIM public keys live in DNS. But you have two ways to publish them: as a TXT record containing the key directly, or as a CNAME record that points to a provider-hosted key. Choosing the right type depends on who manages your email sending infrastructure.

How DKIM DNS Lookups Work

When a receiving server checks a DKIM signature, it extracts the d= (domain) and s= (selector) values and queries DNS:

selector._domainkey.yourdomain.com

If the result is a TXT record, the server reads the public key directly. If the result is a CNAME record, the server follows the pointer to the target hostname and reads the TXT record there.

Either way, the receiver ends up with a DKIM public key in the standard v=DKIM1; k=rsa; p=... format. The difference is where that key is hosted.

TXT Records: Direct Key Publishing

A TXT record contains the DKIM public key directly in your DNS zone.

Example:

; DNS Zone for yourdomain.com
selector1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..."

When to use TXT:

• You run your own mail server (Postfix, Exchange on-premises, etc.)
• You generated the keys yourself
• You want full control over key rotation timing
• You use a provider that gives you the raw public key to publish

CNAME Records: Provider-Hosted Keys

A CNAME record doesn't contain the key — it points to a hostname controlled by your email provider. The provider hosts the actual TXT record with the public key at that target hostname.

Example (Microsoft 365):

; DNS Zone for yourdomain.com
selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

When a receiver queries selector1._domainkey.yourdomain.com, DNS follows the CNAME to Microsoft's infrastructure, where the actual TXT record with the public key lives.

When to use CNAME:

• Your email provider requires it (Microsoft 365, SendGrid, Mailchimp, etc.)
• You want the provider to manage key rotation automatically
• You're delegating DKIM signing to a third-party service

Side-by-Side Comparison

Which Providers Use CNAME?

Most cloud email services use CNAME records for DKIM. This lets them rotate keys on their end without requiring you to update DNS every time.

Pros and Cons of Each Approach

TXT Record Advantages

• Full control — You decide when to rotate keys and what key size to use
• No provider dependency — Your DKIM works even if you switch providers
• Single DNS lookup — Slightly faster verification (one fewer DNS hop)
• Transparency — You can see the exact public key in your DNS zone

TXT Record Disadvantages

• Manual rotation — You must generate new keys and update DNS yourself
• Human error risk — Copy-paste mistakes in long Base64 keys can break DKIM
• DNS record length — 2048-bit keys may exceed some DNS providers' TXT limits

CNAME Record Advantages

• Automatic rotation — Provider handles key rotation without DNS changes on your end
• Simpler setup — Short CNAME value instead of a long Base64 key
• No length issues — CNAME values are short, no DNS size limits to worry about
• Provider-managed security — The provider uses their security practices for key storage

CNAME Record Disadvantages

• Provider dependency — If the provider's DNS goes down or the record is removed, DKIM fails
• Less control — You don't choose the key size, algorithm, or rotation schedule
• Extra DNS hop — Two lookups instead of one (minimal real-world impact)
• Vendor lock-in — Switching providers means updating CNAME targets

Can You Use Both?

Yes. If you send email from multiple sources — say, your own mail server and a marketing platform — you'll likely have both:

; Your own mail server (TXT record, self-managed)
mail._domainkey.yourdomain.com       TXT    "v=DKIM1; k=rsa; p=MIIBIjAN..."

; SendGrid for marketing emails (CNAME record, provider-managed)
s1._domainkey.yourdomain.com         CNAME  s1.domainkey.u12345.wl.sendgrid.net

Each sending source uses a different selector, so the records don't conflict. This is a normal and recommended setup.

How to Check Your Current DKIM Record Type

You can verify what type of record exists for a selector using a DNS lookup:

# Check for TXT record
dig TXT selector._domainkey.yourdomain.com

# Check for CNAME record
dig CNAME selector._domainkey.yourdomain.com

# Or use nslookup on Windows
nslookup -type=txt selector._domainkey.yourdomain.com
nslookup -type=cname selector._domainkey.yourdomain.com

If you see a CNAME response, follow the chain to the final TXT record to see the actual public key.

Common Mistakes

Using TXT when the provider expects CNAME If your provider rotates keys on their side, a TXT record with a static key will become stale. Use the CNAME they provide.

Using CNAME when you should use TXT If you generated your own keys, a CNAME pointing nowhere will break DKIM. Publish the key directly as a TXT record.

Having both TXT and CNAME at the same selector DNS does not allow a CNAME to coexist with other record types at the same hostname. If you add a CNAME and a TXT at the same selector, DNS behavior is undefined and verification will be unreliable.

The Bottom Line

• Use TXT when you manage your own keys (self-hosted mail servers, custom setups).
• Use CNAME when your email provider tells you to (cloud services that rotate keys for you).
• Use both (different selectors) when you send from multiple sources.

When in doubt, follow your email provider's setup instructions. They'll tell you exactly which record type and value to use.

---

Need a properly formatted DKIM TXT record? Generate one with the correct syntax for your DNS provider.