Cloudflare DKIM Not Working

"Cloudflare DKIM not working" is not an SMTP reply code or a DKIM protocol error — it's a configuration symptom. Your provider (SES, SendGrid, Mailgun, Postmark, Mailchimp, Courier, etc.) reports DKIM as unverified or failing even though you added the record in Cloudflare. The DKIM record itself is fine; Cloudflare is changing what the public DNS query actually returns.

What causes "Cloudflare DKIM not working"?

DKIM verification works by the receiving server doing a DNS TXT lookup at <selector>._domainkey.<domain> (RFC 6376 §3.6.2.1 defines the selector namespace; §3.6.2.2 specifies that the lookup defaults to a TXT record) and reading the public key from it. Many providers ask you to publish that key as a CNAME that points to a record they host. Three Cloudflare behaviors commonly break this:

1. The record is proxied (orange cloud). Cloudflare's proxy is for HTTP/HTTPS traffic, not for resolving DKIM. Only A, AAAA, and CNAME records can be proxied, and a proxied CNAME returns Cloudflare's anycast IPs instead of the target the verifier expects. Postmark's Cloudflare guide makes the same point for the Return-Path CNAME, telling you to "click on the orange cloud to disable Cloudflare on the CNAME record" before verifying. (Postmark itself publishes its DKIM key as a TXT record, so this orange-cloud step applies to its Return-Path CNAME — but the principle is identical for any provider that gives you a DKIM CNAME.)
2. CNAME flattening. Cloudflare resolves a CNAME chain and can return something other than the CNAME target itself. Per Cloudflare's docs, flattening is on by default only for CNAMEs at the zone apex (the bare root domain) — since a DKIM selector is always a subdomain (<selector>._domainkey.<domain>), that default does not touch DKIM. The failure mode only shows up if you've also turned on Cloudflare's optional "flatten all CNAME records" setting, which applies flattening to every CNAME including your DKIM selector. Because ESP-hosted DKIM CNAME targets (e.g. Mailchimp's dkim.mcsv.net) typically hold only a TXT record and no A/AAAA record, flattening that selector either returns NODATA (per Cloudflare's docs) or, per real-world reports, surfaces the underlying TXT content instead of the CNAME hostname the verifier expects. Either way, DKIM validation fails — Mailchimp users have documented this exact failure.
3. A wrong selector hostname. Cloudflare automatically appends the zone name to the Name field. If you type s1._domainkey.example.com, Cloudflare stores s1._domainkey.example.com.example.com. Enter only the host portion (s1._domainkey) and let Cloudflare append the domain.

How do I fix DKIM in Cloudflare?

1. Set the record to DNS only. In the Cloudflare DNS table, click the orange cloud next to the DKIM record so it turns grey ("DNS only"). This applies to CNAME-style DKIM records (TXT records can't be proxied in the first place).
2. Turn off "flatten all CNAME records" for that record (if enabled). This opt-in setting is the only way flattening reaches a DKIM selector, since selectors are never at the zone apex. If your provider offers a TXT key instead of a CNAME, publishing the key directly as TXT sidesteps flattening entirely.
3. Use the exact selector host once. For a TXT record, set Type = TXT, Name = the host your provider gave you (e.g. s1._domainkey), Content = the full v=DKIM1; k=rsa; p=... value. Do not repeat the domain — Cloudflare appends it.
4. Verify the public lookup, not the dashboard. Confirm what the world actually sees:

dig +short TXT s1._domainkey.example.com
# or for a CNAME-style record:
dig +short CNAME s1._domainkey.example.com

A CNAME query should return the provider's target hostname (not an IP). A TXT query should return the v=DKIM1... key.

5. Wait for propagation, then re-check in your provider. DNS changes can take up to an hour. Once dig shows the correct value, re-run verification in your sending provider's dashboard.

If dig returns the correct record but the provider still fails, the problem is no longer Cloudflare — check the selector name matches the one your provider is signing with, and that the key wasn't truncated.