Should I use CNAME or TXT for DKIM?

Use CNAME if your ESP offers it—they handle key rotation automatically. Use TXT if you want full control over keys or if your DNS provider doesn't support CNAME for this purpose. Both work; CNAME is more convenient, TXT is more control.

Can I use CNAME for SPF records?

Not directly. SPF must be a TXT record at your domain root. However, you can use the 'include:' mechanism in SPF to reference other domains, achieving similar delegation. Example: v=spf1 include:_spf.google.com ~all

Why do some ESPs require CNAME for DKIM?

CNAME lets the ESP manage your DKIM keys. When they rotate keys for security, your CNAME automatically points to the new key. With TXT, you'd need to manually update your DNS every time they change keys.

What's the DNS record limit that affects CNAME vs TXT choice?

TXT records have a 255-character string limit per segment, requiring multiple strings for long DKIM keys. CNAME has no content length limit since it just points elsewhere. This matters for 2048-bit DKIM keys which exceed 255 characters.

Can CNAME and TXT records coexist for the same name?

No. DNS doesn't allow CNAME to coexist with other record types at the same name. If you have a CNAME for selector._domainkey.example.com, you can't also have a TXT there. This is a fundamental DNS limitation.

CNAME vs TXT for Email Authentication Records

The Choice: CNAME vs TXT

Email authentication records can use either CNAME or TXT record types, depending on the record:

Record	Typical Type	Can Use CNAME?
SPF	TXT	No (use `include:` instead)
DKIM	TXT or CNAME	Yes, ESP preference
DMARC	TXT	No (must be TXT)

The most common decision point is DKIM: should you use CNAME (ESP-managed) or TXT (self-managed)? For full authentication setup, see our email authentication guide and DNS configuration guide.

Understanding the Difference

TXT Record: You Host the Value

selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The DKIM public key lives in your DNS. You control it directly.

Pros:

Full control over the key
No dependency on ESP's DNS infrastructure
Works with any ESP

Cons:

You must update DNS when key rotates
Large keys may require splitting across multiple strings (see DKIM key management at scale)
More manual work

CNAME Record: ESP Hosts the Value

selector._domainkey.example.com.  CNAME  selector.esp.example.net.

Your DNS points to the ESP's DNS where they host the actual key:

selector.esp.example.net.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

Pros:

ESP manages key rotation automatically
Simpler setup (copy one CNAME)
No worrying about TXT string limits

Cons:

Dependent on ESP's DNS availability
Less visibility into actual key
Must trust ESP's key management

DKIM: The Main Decision

When to Use CNAME for DKIM

ESP offers CNAME option (SendGrid, Mailgun, Brevo, etc.)
You want automatic key rotation handled
You're not planning to change ESPs frequently
You trust your ESP's infrastructure

Example CNAME setup:

s1._domainkey.example.com.  CNAME  s1.domainkey.u12345.wl.sendgrid.net.
s2._domainkey.example.com.  CNAME  s2.domainkey.u12345.wl.sendgrid.net.

When to Use TXT for DKIM

You need to use your own key (compliance requirements)
You're using multiple ESPs with the same selector
You want complete control over key rotation
You're running self-hosted email (Postfix, Mailcow, etc.)

Example TXT setup:

selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

Practitioner note: For most clients, I recommend CNAME if the ESP supports it. Key rotation is something people forget about, and ESPs handle it automatically with CNAME. The only time I push for TXT is when clients have compliance requirements for key custody or when they're frequently switching ESPs.

SPF: No CNAME, Use Include

SPF must be a TXT record at your domain root. But you can delegate SPF checking via include::

example.com.  TXT  "v=spf1 include:_spf.google.com include:amazonses.com ~all"

The include: mechanism tells receivers to also check those external domains for authorized IPs. It's similar to CNAME delegation but within SPF's own syntax.

Why not CNAME for SPF?

SPF record must be at the domain apex
CNAME at apex conflicts with other records (A, MX, etc.)
SPF specification requires TXT record type

DMARC: Always TXT

DMARC records must be TXT at _dmarc.yourdomain.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Some DMARC monitoring services offer "hosted DMARC" via CNAME, but this just redirects to their TXT record:

_dmarc.example.com.  CNAME  example.dmarc.service.com.
example.dmarc.service.com.  TXT  "v=DMARC1; p=reject; rua=..."

This works for some providers but not universally. Standard practice is direct TXT.

DNS Record Size Limits

TXT records have a 255-character limit per string. Long DKIM keys (2048-bit = ~400 characters) must be split:

selector._domainkey.example.com.  TXT  (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
    "zN8EuIxWUhDSjVvAhLQK1lOvRz3yXxA2MvkJvXkJvRzW6lMvAlOxRz3yXxAm"
    "... more chunks ..."
    "DAQAB"
)

CNAME avoids this because it just points to another name—no content to split.

Practitioner note: DNS providers handle TXT splitting differently. Cloudflare auto-splits long values. Some control panels require you to split manually. If you're getting "invalid DKIM" errors with a TXT record, check whether the splitting is correct. Often it's a missing quote or extra space between chunks.

ESP-Specific Recommendations

SendGrid

Offers both CNAME and TXT. CNAME is default and recommended.

s1._domainkey.yourdomain.com  CNAME  s1.domainkey.u12345.wl.sendgrid.net.
s2._domainkey.yourdomain.com  CNAME  s2.domainkey.u12345.wl.sendgrid.net.

Mailgun

Prefers CNAME for DKIM.

smtp._domainkey.yourdomain.com  CNAME  mailgun.org

Postmark

Uses TXT records by default.

20220101._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=..."

Google Workspace

Uses CNAME.

google._domainkey.yourdomain.com  CNAME  google._domainkey.GOOGLE_GENERATED.gappssmtp.com.

Amazon SES

Offers both. CNAME is simpler.

abc123._domainkey.yourdomain.com  CNAME  abc123.dkim.amazonses.com.

Migration Considerations

Switching ESPs with CNAME

If old ESP used CNAME:

Add new ESP's CNAME with new selector
Configure new ESP to use new selector
Remove old ESP's CNAME after confirming new one works
Both can coexist briefly (different selectors)

Switching ESPs with TXT

Same process, but you generate and publish keys:

Generate new key pair, publish TXT with new selector
Configure new ESP to sign with new key
Remove old TXT after transition

From CNAME to TXT (or vice versa)

Can't have CNAME and TXT at same name. Options:

Use a new selector for the new record type
Remove old record, add new record (brief DKIM gap)

Troubleshooting

"DKIM check failed" after CNAME setup

dig TXT selector._domainkey.yourdomain.com
# Should return ESP's DKIM record via CNAME chain

dig CNAME selector._domainkey.yourdomain.com
# Should show the CNAME target

If CNAME exists but TXT lookup fails, the ESP's DNS might have issues.

TXT record not resolving correctly

dig TXT selector._domainkey.yourdomain.com +short

Check for:

Proper quoting
Correct string splitting
No extra whitespace

CNAME chain too long

Some resolvers fail if CNAME points to CNAME points to CNAME... (chain > 5-8 hops).

Check the full chain:

dig +trace selector._domainkey.yourdomain.com

If you're setting up email authentication and uncertain whether to use CNAME or TXT records, schedule a consultation.

Sources

RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
RFC 7208: Sender Policy Framework (SPF)
RFC 7489: Domain-based Message Authentication (DMARC)
RFC 1035: Domain Names - Implementation and Specification
Google Workspace: DKIM Setup
SendGrid: Authenticating Your Domain

v1.0 · March 2026