Cloudflare zone imports orange-cloud your DKIM CNAMEs and silently break email signing

Cloudflare’s zone import optimizes for web traffic. Email infrastructure is collateral damage.

Added a domain to Cloudflare. It scanned the existing zone (imported from Hover) and created records for everything it found. Standard onboarding flow. A week later: DKIM verification failures on outbound email. SPF passed. DMARC failed because DKIM failed. Some recipients soft-bounced, others silently dropped the messages into spam. No alert from Cloudflare. No warning during import. I found out because replies stopped coming.

The cause

Cloudflare’s zone import defaults CNAME records to proxied (orange cloud). It does not distinguish between CNAMEs that should be proxied (web traffic) and CNAMEs that must not be proxied (mail infrastructure). My three _domainkey CNAMEs — fm1._domainkey, fm2._domainkey, fm3._domainkey — all got orange-clouded.

When a receiving mail server looks up fm1._domainkey.fizz.today to verify the DKIM signature, it expects a CNAME pointing to Fastmail’s DKIM key server (fm1.fizz.today.dkim.fmhosted.com). With proxying enabled, the lookup returns a Cloudflare IP instead. The DKIM key is unreachable. Verification fails.

The fix

Turn off proxying on all _domainkey records. In the Cloudflare dashboard, click the orange cloud to grey on each one. Or via API:

# Find the proxied DKIM records
cf_records=$(curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?name=contains:_domainkey" \
  -H "Authorization: Bearer $CF_TOKEN" | jq '.result[] | select(.proxied == true)')

The guard rail

Since Cloudflare doesn’t protect against this, I built the guard rail myself. In the cf_records local, any record whose name contains _domainkey gets proxied = false regardless of what the caller passes:

proxied = length(regexall("_domainkey", record.name)) > 0 ? false : record.proxied

The caller doesn’t need to know about this. It’s enforced at the module level in terraform-multi-provider-dns. If someone adds a new DKIM CNAME with proxied = true (by accident or by copy-paste from a web record), the module silently corrects it. Cloudflare’s editorial decision about proxying shouldn’t propagate through my module.

Cloudflare, please

You’re Cloudflare, not Webflare. You’re a DNS company. You know what _domainkey means. You already treat MX records as unproxied during import — you made the distinction for mail delivery. You just didn’t extend it to mail authentication.

A _domainkey CNAME has exactly one purpose: DKIM key publication. Proxying it is always wrong. The zone import should default these to grey cloud, or at minimum flag them for review. Instead it silently breaks email signing and the user finds out a week later when replies stop coming.

The lesson

After any Cloudflare zone import, audit every CNAME for orange-cloud status. Web CNAMEs should be proxied. Mail CNAMEs (_domainkey) must not be. Cloudflare’s import applies one policy to all CNAMEs, and that policy is wrong for email.