How to Correct CNAME Flattening Issues for DKIM

When configuring DomainKeys Identified Mail (DKIM) for third-party platforms like SendGrid, Salesforce, or Microsoft 365, administrators are typically instructed to publish CNAME records pointing to the provider’s managed keys. However, if your DNS provider enables “CNAME flattening” across all subdomains or proxies the traffic, receiving mail servers will fail to retrieve your public key. Instead of receiving the cryptographic TXT record located at the target, resolvers receive flattened IP addresses or empty responses, causing DKIM validation to fail.

Quick Answer

CNAME flattening breaks DKIM when a DNS provider replaces the alias with flattened IP addresses instead of allowing resolvers to follow the record to the vendor’s TXT key. To fix this, change your DKIM CNAME record from “Proxied” to “DNS only” (gray cloud in Cloudflare) and ensure CNAME flattening is restricted strictly to the root domain.

---

Why CNAME Flattening Breaks DKIM

CNAME flattening is a DNS feature developed by providers like Cloudflare to circumvent an RFC limitation: by specification, a standard CNAME record cannot exist at the zone apex (example.com) alongside other records like MX or NS. CNAME flattening solves this by querying the target behind the scenes and returning an A or AAAA IP address directly.

While flattening is helpful at the root domain, applying it to DKIM subdomains breaks email authentication:

1. How DKIM via CNAME Works: Your sending provider gives you a record such as s1._domainkey.example.com pointing to s1._domainkey.sendgrid.net.
2. When a receiving mail transfer agent (MTA) validates an email, it queries DNS specifically for a TXT record at s1._domainkey.example.com.
3. Under normal DNS operation, the resolver follows the CNAME alias to s1._domainkey.sendgrid.net and reads the public key inside the vendor’s TXT record.
4. The Flattening Conflict: If your DNS provider attempts to flatten the subdomain, it expects to return web traffic IP addresses (A records). Because the target (s1._domainkey.sendgrid.net) only contains a TXT record and has no A record, the flattened query returns NODATA or an empty response. The receiving mail server cannot find the key and marks the signature as invalid.

[Standard DKIM Lookup]
Query: s1._domainkey.example.com (TXT)
       │
       ▼ Follows CNAME
Query: s1._domainkey.sendgrid.net (TXT)
       │
       ▼ Returns Public Key
Result: v=DKIM1; k=rsa; p=MIIBIj... (SUCCESS)

---------------------------------------------------------

[Flattened / Proxied DKIM Lookup]
Query: s1._domainkey.example.com (TXT)
       │
       ▼ DNS Provider flattens to A/AAAA or proxies web traffic
Query: Searches for IP Address on mail vendor's key
       │
       ▼ No A record exists / Proxy returns web IPs
Result: NODATA or Invalid Record (DKIM FAILS)

---

Diagnostic Steps: Verifying the CNAME Response

To confirm that CNAME flattening or DNS proxying is corrupting your DKIM keys, query your DNS record directly from the command line.

1. Query the Record Type Specifically

Run two consecutive lookups using dig:

# Check if the CNAME alias resolves properly
dig s1._domainkey.example.com CNAME +short

# Check if the TXT record resolves through the alias
dig s1._domainkey.example.com TXT +short

2. Analyze the Output

• Healthy Configuration: The first command returns the vendor’s target (e.g., s1._domainkey.sendgrid.net.), and the second command returns the v=DKIM1; ... public key string.
• Proxy / Flattening Conflict: The CNAME lookup returns nothing, or querying for an A record (dig s1._domainkey.example.com A) returns Cloudflare proxy IPs (such as 104.21.x.x or 172.67.x.x).

If the TXT query returns completely blank across all public resolvers, see DKIM “Public Key Not Found” Error.

---

Step-by-Step Fixes

Fix 1: Disable Proxy Status (Cloudflare “Gray Cloud”)

The most frequent cause of broken DKIM CNAMEs in Cloudflare is setting the record to Proxied (Orange Cloud). Cloudflare’s proxy only handles HTTP/HTTPS web traffic; it cannot route email authentication lookups.

1. Log in to your Cloudflare Dashboard.
2. Select your domain and navigate to DNS > Records.
3. Locate your DKIM CNAME records (e.g., ._domainkey).
4. Click Edit on the record.
5. Toggle the Proxy status from Proxied to DNS only (the icon will turn from orange to gray).
6. Click Save.

[Record Type]   [Name]                  [Target]                        [Proxy Status]
CNAME           s1._domainkey           s1._domainkey.sendgrid.net      DNS only (Gray Cloud)
CNAME           s2._domainkey           s2._domainkey.sendgrid.net      DNS only (Gray Cloud)

Fix 2: Adjust Zone-Wide CNAME Flattening Settings

Some DNS providers allow you to flatten all CNAME records across the entire zone by default. This must be restricted so that subdomains remain standard aliases:

1. In your Cloudflare DNS settings, scroll down to the CNAME Flattening panel.
2. Review the selection menu.
3. Change the setting from Flatten all CNAMEs to Flatten CNAME at root.
4. This ensures your apex domain (example.com) can safely alias root services without interfering with subdomains like _domainkey.

Fix 3: Convert to a Static TXT Record (Fallback Method)

If your DNS host enforces CNAME flattening unconditionally and cannot be reconfigured, bypass CNAME resolution entirely:

1. Query the vendor’s target hostname directly to extract the raw public key: dig s1._domainkey.sendgrid.net TXT +short
2. Copy the full public key string ("v=DKIM1; k=rsa; p=MIIB...").
3. Return to your DNS manager, delete the problematic CNAME record, and create a standard TXT record:
   • Name/Host: s1._domainkey
   • Type: TXT
   • Value: Paste the copied v=DKIM1; ... string.
4. Caution: If you use static TXT records instead of CNAMEs, automatic key rotation managed by your third-party vendor will no longer update your DNS automatically.

For guidance on properly configuring third-party email tools with your domain, review How to Align SPF/DKIM for Third-Party Apps. If this key issue occurred right after moving mail platforms, see Troubleshooting “Invalid DKIM Signature” after Migration.