When configuring DKIM records for email authentication, many administrators encounter a peculiar limitation with CNAME records containing underscores. While mail._domainkey.example.com TXT works perfectly fine, attempting to create mail._domainkey.example.com CNAME often results in validation errors from DNS management interfaces.

The root cause lies in RFC 1034 (Domain Names - Concepts and Facilities) which states:

; CNAME record format
<alias-name>    IN    CNAME    <canonical-name>

While RFC 2181 (Clarifications to the DNS Specification) explicitly permits underscores in DNS names, many DNS implementations historically treated underscores as special characters in CNAME records due to legacy systems.

For those needing to work around this limitation while maintaining DKIM functionality, consider these approaches:

; Option 1: Direct TXT record (if your provider allows long records)
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

; Option 2: Split TXT records (RFC 7208 compliant)
mail._domainkey IN TXT ("v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
    "uJ0xWwkHy0LIfd5dXqq2eYT7IWJ5eJ4HdMuX1+7L4x7/7y9Q5wQ3Y1Y3x4y3Z5w6X7x8y9z0A1B2C3D4E5F"
    "...[remaining key]...")

For organizations requiring CNAME-based DKIM solutions:

1. Create a subdomain specifically for DKIM records (e.g., dkim.example.com)
2. Configure CNAMEs without underscores pointing to your actual DKIM records

; DNS configuration example
dkim1.example.com.    IN    CNAME    mail._domainkey.auth-provider.com.

To verify your configuration works correctly:

$ dig +short mail._domainkey.example.com TXT
$ dig +short dkim1.example.com CNAME
$ openssl base64 -d <<< "BASE64_KEY_HERE" | openssl rsa -pubin -text -noout

Different DNS providers handle this differently:

• AWS Route 53: Allows underscores but may warn about non-RFC compliant names
• Cloudflare: Fully supports underscores in CNAMEs
• Traditional BIND servers: Often require explicit allow-underscore directives

When configuring DKIM records, many administrators encounter a puzzling situation where mail._domainkey.example.com works perfectly as a TXT record but gets rejected as a CNAME. This isn't your DNS provider being difficult - there's actually an RFC specification behind this behavior.

The DNS standard (RFC 1034) specifically states in section 3.5 that underscores are not permitted in hostnames (which CNAME records point to), but are allowed in other record types like TXT. This explains why:

; This is valid
mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

; This is invalid per RFC
mail._domainkey.example.com. IN CNAME dkim.example.net.

When your DNS provider imposes character limits on TXT records, consider these alternatives:

; Option 1: Chunked TXT records (RFC 4408)
selector1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
selector1._domainkey IN TXT "KBgQC+W6scdKiX65G0nKM5X4ScVGX7FStUeN4KaVONKGRQH5v5C"
selector1._domainkey IN TXT "9ZxZ/Uhk="

; Option 2: Use a subdomain without underscore
dkim.example.com. IN CNAME dkim.provider.net.
; Then at provider.net:
selector1.dkim IN TXT "full_key_here..."

Some major DNS providers handle this differently:

• Cloudflare: Automatically concatenates multiple TXT records
• AWS Route 53: Supports up to 255 characters per string segment
• Google Domains: Requires manual chunking at 255-character boundaries

After implementation, verify with these commands:

# For TXT records
dig TXT selector._domainkey.example.com +short

# For CNAME resolution
dig CNAME dkim.example.com +short
nslookup -q=TXT selector.dkim.example.com