Cloudflare DKIM setup

Choose the implementation approach

Use the exact approach the sending service generated for the selected domain. The record shape is sender-specific. Do not convert a sender-provided CNAME instruction into a TXT instruction, and do not invent a value because another sender used a similar selector.

Use these decision rules:

• If the sender gives a complete DNS record set, publish that record set only after confirming it belongs to the selected account and domain.
• If the sender gives more than one record, treat the set as one configuration request. Do not assume one record is optional.
• If the sender asks you to edit an existing record, compare the current DNS answer with the sender's documented migration instructions before making any replacement.
• If the sender also supplies SPF guidance, handle it as a separate review. Do not replace an existing SPF TXT record without understanding how the existing policy and the sender's required authorization fit together.
• If the sender cannot identify the domain it will sign with, pause the DNS change. DNS publication alone cannot answer that question.

_Source: Palisade._

Publish only the exact DKIM record supplied for the selected sender account and domain. Keep the change scoped to that record, then verify DNS and message authentication separately.

For a comparable DNS-provider workflow, see how to add a DKIM record in GoDaddy. The record values must still come from your own sender account.

How to configure Cloudflare DKIM

1. Identify the exact sending path

Select one application or sender that produces mail with the domain you are configuring. Confirm the From domain used by that path and the person responsible for the sender account.

Do not group unrelated mail streams into one unverified change. A successful configuration for a marketing sender does not establish that transactional messages, employee mail, or gateway-relayed mail use the same signing identity.

2. Obtain the sender-generated DKIM instructions

Open the domain-authentication or DKIM configuration area in the sender that sends the selected mail. Collect the complete instruction set for the account and domain: record type, owner name, content or target, expected signing domain, and the sender's own verification action.

The sender generates these values. Cloudflare publishes them in the DNS zone. If the sender's instructions conflict with an old ticket, screenshot, or copied record, use the sender's current account-generated values and investigate the discrepancy before publishing.

The following is an illustrative shape only. It is not a Cloudflare record and must not be published.

Illustrative only
Record type: <sender-generated TXT or CNAME>
Owner name: <sender-generated selector or owner under yourdomain.com>
Value: <sender-generated public key, target, or verification value>
Expected signing domain: <sender-generated domain>

Do not publish placeholders or substitute a selector, target, token, or public key from another tenant. Copy the real values only from the sender account that will sign this domain's mail.

3. Open the authoritative Cloudflare DNS zone

Sign in to the Cloudflare account that controls the authoritative zone for the selected domain. Confirm the zone name before creating or editing a record.

Follow Cloudflare’s current DNS record instructions: open DNS Records, select Add record or Edit, and choose the sender-provided record type. Enter its exact owner name and value, review the CNAME proxy setting against the sender’s authentication instructions, and save through your approved change process.

4. Publish the sender's record without altering its meaning

Enter only the sender-generated record type, owner name, and value or target. Check the final owner name that the Cloudflare interface displays before saving, especially if the sender supplied a fully qualified name.

Do not merge separate DKIM records into one value. A CNAME owner cannot also hold ordinary TXT or other data records, as RFC 2181 section 10.1 specifies. If an active record occupies the requested name, use the sender’s documented rotation or migration procedure before replacing it.

Keep the DNS change narrowly scoped. Record the time, the intended owner name, the sender account, and the approver. These details let you match later sender status and message-header evidence to the change you actually made.

5. Use the sender's current verification action

Return to the sending service after the DNS record is visible as expected. Use the verification action and status described by that sender's current documentation or account interface.

Treat the sender's status as sender-specific evidence. It can show what that service sees for its domain configuration. It cannot prove that every production mail path signs with the intended identity or that a recipient accepted a particular message.

How to validate the setup

A working Cloudflare DKIM setup needs separate evidence at four layers. Do not mark the change complete from a single green status or public lookup.

• DNS: Inspect the published owner name through the authoritative DNS path and at least one public resolver. Compare the observed record type and value or target with the sender-generated instruction. A public lookup can show only public DNS state.
• Sender: Record the sender's current verification or authentication status for the exact account and domain. This connects the published record to the service that is expected to sign.
• Message: Send a new message through the exact production path. Inspect its complete headers in the receiving mailbox and retain a redacted copy of the authentication evidence. Do not use an older message that predates the DNS change.
• DMARC: After reports accumulate, review the source and authentication results for the configured mail stream. A delivered-message check is evidence for one tested path and time. Reporting helps identify whether additional sources or alignment problems remain.

sending_path: <application or sender>
from_domain: <visible From domain>
dns_owner: <sender-generated owner name>
dns_result: <observed record type and value or target>
sender_status: <sender-reported result>
test_message: <timestamp and redacted header reference>
dmarc_reporting: <observed source and status after reports accumulate>
rollback_status: <unchanged or restored prior configuration>

The DKIM checker can inspect public DKIM DNS after publication. Compare the result with the sender's record instruction, then continue with sender status and a delivered-message test. A DNS lookup cannot prove that the private key is installed, that the intended application signed a production message, that DMARC aligned, or that a receiver will place future mail in the inbox.

A correct DKIM record also does not replace SPF. The two controls evaluate different parts of the sending path. Keep their evidence separate when you review the final message.

Troubleshooting

The sender cannot verify the published record

Start with the sender-generated instruction set and the DNS answer for the exact owner name. Confirm that the selected Cloudflare zone is the authoritative zone and that the record type matches the sender's current instruction.

Then compare the owner name and complete value or target with the sender account. Do not assume that a copied value, a record from a prior domain, or a record from another account is interchangeable.

The DNS result differs from the sender's instruction

Stop before making another change. Confirm whether the Cloudflare interface rendered a different final owner name than intended, whether an existing record is still present, and whether the sender generated a replacement as part of a rotation.

Use the sender's documented migration guidance for any replacement. Avoid deleting a known working record while the cause is unknown.

The sender reports success but the delivered message lacks expected evidence

Send a new message through the exact application and route you configured. Check that the message was not sent by a different platform, alias, or gateway.

Collect the raw headers in redacted form and compare the visible From domain, sending route, and authentication evidence with the sender configuration. Do not conclude that Cloudflare DNS is wrong from sender status alone.

DKIM evidence exists but the DMARC result remains unresolved

Keep the DNS, sender, message, and reporting layers separate. A published record or a sender status does not show how every source using the domain behaves over time.

Review the mail stream in DMARC aggregate reports once data accumulates. For recurring multi-sender or multi-domain work, Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step based on evidence, while a human reviews the evidence and applies any policy change.

Inspect the published DKIM record before the message test

Check the exact domain after you publish the sender-generated record, then compare the public result with the sender's account instructions. This catches an incorrect public DNS owner or value before you rely on the sender's status.

Check the DKIM record

Compare the checker result with a newly delivered production message and the sending provider's DKIM settings. If your team needs to follow unresolved sources and alignment issues across domains after reports arrive, Start with Palisade. Palisade's DMARC Agent analyzes report data and proposes remediation work for human review. You approve changes before deployment.