What issues occur when adding DKIM record to DNS via CName with Cloudflare?
Published 20 Jun 2025
Updated 21 Oct 2026
13 min read
Summarize with
Updated on 21 Oct 2026: We added DKIM propagation checks and clarified how to verify Cloudflare records against real message results.
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 and the provider's DKIM TXT key? Second, does a real message contain a DKIM-Signature header that uses the signing domain and selector you just configured? If DNS is correct but messages still use older selectors, check the sending source and its activation settings.
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.
Common Cloudflare DKIM CNAME issues
Check the orange-cloud proxy and CNAME flattening first. DKIM is not web traffic. A DKIM CNAME must be published as normal DNS, so the Cloudflare record should show DNS only (grey cloud), and Flatten should be off where available. These settings let the sender verify the CNAME and let receiving mail servers follow it to the public key.
- 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 its hostname with an A, AAAA, TXT, or MX record, or point to a second CNAME target. Different selectors can coexist.
- Sender activation: After DNS resolves, complete any verify or enable step required by the sending platform before it signs mail.
Check the key before activation
A visible CNAME proves only that the pointer exists. Check that its target returns a valid DKIM TXT key, then 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 the chain must end at a TXT record containing 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 table illustrating DKIM CNAME selectors and DNS only proxy status.
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
In Cloudflare, select the domain, open DNS > Records, and choose Add record > CNAME. Check the name and target, choose a TTL, set DNS only, and save. Review DNS > Settings for zone-wide flattening before testing the record.
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 for the external target | CNAME hidden by flattening |
Name | s1._domainkey | Domain twice |
Target | Full provider hostname | Shortened host |
TTL | Auto or a chosen TTL | Previous answer still cached |
Cloudflare checks for DKIM CNAME records.
For the first example, enter s1._domainkey in the Name field of the example.com zone and s1.example._dkim.provider.net as the Target. The target is a hostname, not a URL or a TXT value beginning v=DKIM1. Use the actual values supplied by your sender.
Cloudflare accepts a full hostname in its own zone 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. On paid zones, Cloudflare offers zone-wide and per-record CNAME flattening. Flattening replaces the CNAME with final address data, so a sender expecting to verify the CNAME can reject the result. A target with no A or AAAA records can also produce NODATA even when it has a DKIM TXT key; adding address records is not the fix.
- Zone setting: Open Cloudflare DNS Settings and turn off CNAME flattening for all CNAME records if it is enabled.
- Record setting: Edit the DKIM selector and turn off Flatten if that option appears. The per-record option is unavailable while zone-wide flattening is on.
- Delegated DNS: Check for an NS record at _domainkey or a parent name. If it exists, publish the selector at the delegated DNS provider. Removing the delegation affects every record beneath it.
- Provider target: Query the CNAME target directly. Some senders publish the target only after a key is generated or DKIM is enabled, so an unpublished target can make the chain appear broken.
Cloudflare's flattening documentation also notes that CNAME targets within the same zone are flattened regardless of the setting. Use the exact external target supplied by the sender rather than adding an intermediate alias within your zone.
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 long DKIM DNS changes take
Cloudflare's TTL documentation sets Auto to 300 seconds (five minutes) for DNS-only records. This is a cache lifetime, not a guarantee that every validator will refresh within five minutes. An older answer remains cached according to its previous TTL; lowering the TTL after an edit does not clear that cache.
Compare a direct authoritative lookup with your normal recursive lookup. Replace ns1.example.net below with an authoritative nameserver for the selector, using the delegation trace in the next section if necessary. The authoritative answer shows what is published; the recursive answer shows what your resolver currently returns.
Compare authoritative and cached CNAME answersBASH
dig @ns1.example.net s1._domainkey.example.com CNAME +norecurse +noall +answer +authority +comments dig s1._domainkey.example.com CNAME +noall +answer +authority +comments
If the authoritative answer is correct but the recursive answer is old, wait for the relevant cache TTL, then retry verification. A lookup made before the selector existed can cache NXDOMAIN or NODATA under the negative-cache TTL in the SOA response. Repeatedly deleting and recreating the CNAME does not clear that cache.
If the authoritative answer is wrong or missing, fix the record or delegation first. For a standard Cloudflare full DNS setup, the domain's delegated nameservers must be the Cloudflare nameservers assigned to that zone; adding a row to an inactive Cloudflare zone does not publish it to the internet.
How to verify the DKIM CNAME and public key
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 NS example.com +short dig CNAME s1._domainkey.example.com +short dig +trace s1._domainkey.example.com TXT dig TXT s1._domainkey.example.com +noall +answer dig TXT s1.example._dkim.provider.net +noall +answer
The NS lookup identifies the domain's nameservers. With proxying and flattening off, the CNAME lookup should return the provider target. The trace follows delegation and helps locate the authoritative zone; an empty NS lookup at _domainkey alone does not rule out delegation higher in the name. The final TXT queries test the complete chain and the target separately. Expect a DKIM key with a nonempty p= value, typically prefixed v=DKIM1.
For a faster check, use our 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. Check whether the target publishes a valid key, the sender has activated DKIM, the domain is verified under the correct account, and the test message came through the sending source you configured. A valid key lookup does not prove that the message's cryptographic signature is valid.
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 key and activation
Confirm the target TXT key, then complete any sender verification or activation step.
Header mismatch
Check headers
Inspect the message signing domain and selector, then query that exact name.
DKIM passes
Check DMARC
Check whether the signing domain satisfies DMARC domain matching, then monitor sending sources.
In the DKIM-Signature header, d= is the signing domain and s= is the selector. Query s._domainkey.d using those actual values. For d=mail.example.com and s=s1, the name is s1._domainkey.mail.example.com; in the example.com zone, the relative Name is s1._domainkey.mail. An old selector means this signature uses the old key, so check the sending source before editing the new record.
Relevant 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 header.s=s1
Read the Authentication-Results added by the receiving mail service. If the correct key resolves but it reports a signature or body-hash mismatch, investigate changes to signed content after signing and a mismatch between the sender's private key and the published public key. A DKIM pass contributes to DMARC only when the signing domain also meets DMARC's domain matching rules for the visible From address.
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 is our DMARC reporting and email authentication platform. Use it to connect a successful DKIM lookup with the authentication results receivers report for your sending sources. Aggregate reports show observed authentication results; they do not replace a fresh message test or arrive immediately after a DNS change.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
For teams managing several senders or domains, validate the DKIM selector, send a real message, then review aggregate reports for the relevant sending source and reporting period. Suped's domain health checker checks the domain's authentication setup alongside the individual DKIM lookup.
Once DNS is correct, Suped's DMARC monitoring helps identify sources with DKIM failures and check whether DKIM satisfies DMARC domain matching. Use subsequent reports to watch for regressions after key rotation or changes to a sending platform.
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, authority, or flattening | Check the authoritative answer and record settings |
Orange cloud | Proxied | Set DNS only |
Record already exists | Another record uses the same hostname | Identify its sender; request a different selector if still active |
NXDOMAIN or NODATA | Missing name, record type, target, or cached negative answer | Check authority, target TXT key, and cache TTL |
Portal fails | Target key missing, activation incomplete, or cached check | Verify the key, then retry the sender verification step |
Old selector | Different sending source or selector not switched | Inspect d= and s= in the test message |
Common Cloudflare DKIM CNAME symptoms and next actions.
Do not delete an existing selector just to clear a record conflict. Identify which sender uses it, remove it only after confirming it is retired, or ask the new sender for a different selector. During key rotation, keep old public keys available while messages signed with them still need verification.
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 signing domain and 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 view
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 view
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
Publish the CNAME exactly as provided, keep it DNS only, turn flattening off, confirm the authority and target TXT key with direct lookups, complete any sender activation step, then send a fresh email. If the headers use a different signing domain or selector, investigate the sending source. If they use the expected values but DKIM fails, inspect the receiver's failure reason before changing DNS again.
Frequently asked questions
No. Set DKIM CNAME records to DNS only. DKIM lookups need the real DNS answer, not Cloudflare proxy behavior.
Yes. Flattening can hide the CNAME that a sender expects to verify or return NODATA when the target has no address records. Disable zone-wide and per-record flattening where available. Cloudflare still flattens same-zone targets, so use the external target supplied by the sender.
Cloudflare often displays names relative to the zone and can remove a trailing period. Those display changes are not problems when the fully qualified DNS name resolves correctly.
No. Publish one CNAME target or a DKIM TXT key at a selector, according to the sender's instructions. Different selectors can coexist; retain an active sender's selector and use a different one for a new sender.
A visible CNAME does not prove its target contains a valid key or that the sender has activated DKIM. Check the target TXT record and the message's d= and s= values. If the correct key resolves and signing is active, investigate the receiver's failure reason, including changes to signed content.
Ask for the saved Cloudflare row, proxy and flattening states, the full CNAME target, authoritative nameservers, and a direct DNS lookup result for the selector.
