What issues occur when adding DKIM record to DNS via CName with Cloudflare?
Published 20 Jun 2025
Updated 13 Aug 2026
10 min read
Summarize with
Updated on 13 Aug 2026: We expanded the Cloudflare troubleshooting steps to cover CNAME flattening, delegated DNS, provider target readiness, and live DKIM verification.
The main issues that occur when adding a DKIM record to Cloudflare via CNAME are proxying, CNAME flattening, wrong host formatting, record conflicts, delegated DNS, stale validation, selector mismatch, and missing activation in the sending platform. Cloudflare can host DKIM CNAME records correctly, but the record must be DNS only and unflattened, the name and target must match the provider's instructions, and the sender must actually start signing mail with that selector.
Treat this as two separate checks. First, does DNS return the CNAME chain expected by the sender? Second, does a real message contain a DKIM-Signature header that uses the selector you just added? If the CNAME is visible with a DNS lookup but messages still use older selectors, the problem is usually activation, not Cloudflare.
Cloudflare's DKIM record explainer describes DKIM as DNS-published public key material. Many senders ask for a CNAME instead of a long TXT value so they can rotate keys on their side. That indirection is fine, but it makes small DNS mistakes harder to spot.
The direct answer
The most common Cloudflare-specific issues are the orange-cloud proxy and CNAME flattening. DKIM is not web traffic. A DKIM CNAME must be published as normal DNS, so the Cloudflare record should show DNS only, not Proxied, and Flatten should be off. Otherwise, validators and receiving mail servers do not see the CNAME target the sender expects.
- Proxy status: Set the CNAME to DNS only. The orange cloud is for supported proxied web traffic, not DKIM lookups.
- CNAME flattening: Turn off flattening for the selector and do not flatten all CNAME records in the zone.
- Name field: Use the selector host exactly once. Do not add the domain twice when Cloudflare already appends the zone.
- Target field: Copy the sender's CNAME target exactly. Remove quotes, hidden spaces, and accidental line breaks.
- Record conflict: A CNAME cannot share the same hostname with a TXT record, MX record, or another CNAME.
- Sender activation: After DNS resolves, the sending platform still needs its verify or enable step before it signs mail.
Fast rule
If a DNS lookup can see the CNAME but the sender still says DKIM is not active, stop changing Cloudflare first. Check the sender's activation state and send a fresh test email.
Why Cloudflare DKIM CNAMEs fail
A DKIM CNAME is a pointer. The selector under your domain points to a hostname controlled by the sender, and that target usually resolves to the DKIM public key. Receiving servers follow the DNS answer to find the public key that verifies the signature on the message.
The failure happens when the selector in the message, the selector in Cloudflare, and the selector in the sender's admin screen are not the same thing. This appears most often after a domain adds another sender. One platform already uses selectors such as k2 and k3, while a new platform asks for s1 and s2. Looking up the old selectors proves only that the old platform is configured.
Cloudflare DNS records page with DKIM CNAME records set to DNS only.
Working setup
- Record type: CNAME is used because the sender asked for CNAME-based DKIM.
- Name value: The selector host is entered once under _domainkey.
- Proxy state: Cloudflare shows DNS only, so mail receivers see the real CNAME.
Broken setup
- Double domain: The name contains the domain twice after copying a full hostname into the wrong field.
- Mixed records: A TXT record already exists at the same selector, so the CNAME cannot be valid.
- No activation: DNS is visible, but the sending platform has not started signing with the new selector.
The Cloudflare DNS settings to check
Start in Cloudflare by checking type, name, target, TTL, proxy state, and flattening. Most DKIM CNAME problems are fixed before changing mail settings.
Correct CNAME shapeDNS
s1._domainkey.example.com. CNAME s1.example._dkim.provider.net. s2._domainkey.example.com. CNAME s2.example._dkim.provider.net.
|
|
|
|---|---|---|
Type | CNAME | TXT conflict |
Proxy | DNS only | Proxied |
Flatten | Off | CNAME absent |
Name | Selector host | Domain twice |
Target | Provider host | Shortened host |
TTL | Auto | Old answer cached |
Compact Cloudflare checks for DKIM CNAME records.
Cloudflare sometimes accepts a full hostname in the Name field and shows the shortened version after saving. It can also remove the trailing period from a name or target. Both display changes are normal when the resulting fully qualified hostname is correct. Test the hostname returned by DNS rather than judging the shortened row in the dashboard.
If the sender asks for CNAME-based DKIM, do not convert it to TXT unless their documentation gives a TXT alternative. For a deeper related case, see DKIM without TXT.
Check CNAME flattening and delegated DNS
A DNS-only setting fixes proxying but leaves flattening untouched. Cloudflare can flatten all CNAME records in a zone or flatten one CNAME on supported plans. Flattening replaces the visible CNAME answer with final address data. A sender that expects to verify the CNAME itself can reject that answer, and a DKIM target without A or AAAA data can produce NODATA that looks like a propagation failure.
- Zone setting: Open Cloudflare DNS Settings and turn off CNAME flattening for all CNAME records.
- Record setting: Edit the DKIM selector and turn off Flatten if that option appears.
- Delegated DNS: Check for an NS record at _domainkey or a parent name. If it exists, the delegated nameservers, not the Cloudflare row, answer for that subtree.
- Provider target: Query the CNAME target directly. Some senders publish the target only after DKIM is enabled or a key is generated, so an unpublished target can make the chain appear broken.
Do not patch a flattened answer with extra records
Do not add A, AAAA, or TXT records at the selector to make a flattened lookup return data. Turn flattening off, keep the single CNAME, and fix the provider target or sender activation if the chain still fails.
How to verify the record
Do not rely only on a sender portal during setup. Query DNS directly, then test a real email. A portal can cache a failed check or report a generic error while the record is already visible.
DNS lookup commandsBASH
dig CNAME s1._domainkey.example.com +short dig NS _domainkey.example.com +short dig TXT s1._domainkey.example.com +short dig TXT s1.example._dkim.provider.net +short dig TXT _dmarc.example.com +short
With proxying and flattening off, the first command should return the provider target. If it does not, check the Cloudflare flattening settings and the authoritative nameservers before waiting for propagation. The NS query identifies delegated DNS. The next two TXT queries test the chain and target. The DMARC lookup is not a DKIM test, but it confirms whether broader authentication DNS is available.
For a faster check, use the Suped DKIM checker with the selector and domain. It shows whether the selector resolves, whether the syntax is valid, and whether the public key can be parsed.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
What a good result means
A good DNS result means receivers can find the key. It does not prove that the sending platform is signing new mail. Always send a message after verification and inspect the headers.
When DNS is right but DKIM still fails
The tricky case is a visible CNAME with no DKIM pass. That usually means the sender has not activated DKIM, the domain was verified under a different account, the test message came through a different sending source, or the header uses a selector you did not check.
Troubleshooting priority
Use the observed result to decide where to look next.
DNS missing
Start in DNS
Fix Cloudflare record type, name, target, proxy state, and flattening.
CNAME visible
Check activation
Check the sender's verify or enable step before changing DNS again.
Header mismatch
Check headers
Inspect the message selector and test the selector shown in the header.
DKIM passes
Broader checks
Move on to SPF, DMARC policy, source monitoring, and related DNS.
A message header gives you the truth. Look for the DKIM-Signature header, then check the d value and s value. The d value is the signing domain. The s value is the selector. If the selector is old, the new CNAME is not being used yet.
Header fields to inspectTEXT
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; Authentication-Results: mx.example; dkim=pass header.d=example.com
If the DNS record is accurate but validation keeps failing, compare the sender portal, the DNS lookup, and the live email header. The related guide on accurate DKIM records covers that wider validation problem.
How Suped fits into the workflow
Suped's product is relevant when the DKIM question is part of a larger authentication workflow. A one-off DNS lookup tells you whether one selector resolves. Suped connects that result to DMARC reports, SPF, sending sources, issue detection, and alerts, so a team can see whether the change improved real mail.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
For teams managing several senders or domains, use a monitored workflow: validate the DKIM selector, send a real message, confirm authentication in aggregate reports, then watch for regressions. Suped's domain health checker checks the domain's authentication setup together instead of treating DKIM as an isolated DNS row.
Once DNS is correct, Suped's DMARC monitoring helps confirm which sources pass DKIM and which sources still fail. That is the practical difference between publishing a CNAME and knowing that production mail is authenticating as expected.
When ongoing monitoring helps
Suped can connect DKIM setup to ongoing source monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, and clear issue steps for teams managing several sending systems.
Common symptoms and fixes
The fastest way to resolve this is to map the symptom to the next check. Changing the same CNAME repeatedly without checking the live selector wastes time, especially when a third party controls Cloudflare access.
|
|
|
|---|---|---|
No CNAME | Wrong name or flattening | Check host and Flatten |
Orange cloud | Proxied | Set DNS only |
Record rejected | Record conflict | Remove old record |
NXDOMAIN or NODATA | Delegation or target missing | Check NS and target |
Portal fails | Not active or cached | Verify sender |
Old selector | Wrong sending source | Inspect test header |
Common Cloudflare DKIM CNAME symptoms and next actions.
When a third party controls DNS
- Ask for output: Request the exact saved Cloudflare row and a DNS lookup result, not only a screenshot.
- Ask for state: Confirm DNS only, record type CNAME, Flatten off, and the full target hostname.
- Ask for timing: Find out when the record was created, what the previous TTL was, and whether the sender's verify step has run.
- Ask for proof: Send a fresh message and inspect the DKIM-Signature selector in the headers.
Views from the trenches
Best practices
Keep DKIM CNAME records DNS only in Cloudflare so mail receivers see the target.
Check the live selector in message headers before editing Cloudflare DNS records again.
Separate DNS resolution from sender activation before changing a visible CNAME again.
Common pitfalls
Proxying a DKIM CNAME hides the DNS answer that the sending platform expects to read.
Copying a full host into the wrong field can create a doubled domain name in DNS.
Seeing old selectors in headers does not prove the new CNAME is broken or missing.
Expert tips
Ask third parties for the saved Cloudflare row and an external DNS lookup result.
Use the sender verify button only after direct DNS checks return the CNAME cleanly.
Treat missing activation as likely when DNS resolves but signatures do not change.
Marketer from Email Geeks says Cloudflare DKIM CNAME records should be DNS only because proxying can prevent validators from seeing the expected DNS answer.
2024-08-08 - Email Geeks
Marketer from Email Geeks says direct lookup tools can confirm the CNAME exists even when a sender portal still reports a generic validation failure.
2024-08-08 - Email Geeks
A reliable troubleshooting sequence
Cloudflare is rarely the root cause when a DKIM CNAME is entered correctly, left as DNS only, and not flattened. The failure usually sits in the Cloudflare row, DNS delegation, the provider target, a cached validation check, or sender activation.
Publish the CNAME exactly as provided, keep it DNS only, turn flattening off, confirm the authority and CNAME chain with direct lookups, run the sender's verify or activate control, then send a fresh email and inspect the DKIM-Signature header. If the CNAME resolves and the message still uses a different selector, the next fix is inside the sending platform, not Cloudflare.
