# Cloudflare DKIM setup > Cloudflare DKIM setup requires sender-generated DNS values, Cloudflare DNS publication, and separate DNS, message, and DMARC validation for your domain. Cloudflare DKIM setup means publishing the DKIM DNS record generated by your email sender in the correct Cloudflare DNS zone, then validating the published record and a real message. Cloudflare is the DNS publishing layer, not the service that creates the selector or signing key. A current authenticated Cloudflare DNS UI path was not verified from the available official material, so do not rely on copied menu labels or record examples. ## Quick takeaways - Your email sender generates the DKIM selector and DNS value for the sending domain. - Cloudflare publishes the DNS record, but it does not create the DKIM key pair for your sender. - Do not copy a selector, CNAME target, token, or public key from another account or an online example. - A published DNS record does not prove the sender is signing production messages. - A sender's verified status does not replace inspection of a newly delivered message. - Keep Cloudflare DNS publication separate from the broader [vendor email authentication workflow](/learning/vendor-email-authentication). ## What should I check before configuring Cloudflare? First, identify the exact email path that needs DKIM. Marketing mail, transactional mail, employee mailbox mail, and mail sent through an outbound security service can use different DKIM configurations. The sending provider for the path in scope must generate the record values. Confirm that you have access to the Cloudflare account that owns the authoritative DNS zone for the From domain. Also confirm that you can access the sender account that generated the DKIM request and a mailbox where you can inspect a delivered test message. Cloudflare's public website confirms that the service has an authenticated account entry point through its [Login control](https://cloudflare.com). It does not, by itself, document the current DNS dashboard path, record-entry labels, supported DKIM record workflow, or verification state. Verify those details in current Cloudflare documentation or in your authenticated account before making a DNS change. If you are unsure why a selector and public key are needed, review the DKIM model before changing DNS. A subdomain can also require a separate configuration when it is a distinct sending identity. See [Does a subdomain need its own DKIM setup?](/learning/dkim-for-subdomains). > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Record the intended sending domain, sender platform, selector, DNS zone owner, change approver, and test mailbox in the change request. This helps prevent a record generated for one domain or account from being placed in another zone. ![Checklist showing the evidence needed before publishing a sender-generated DKIM record in Cloudflare](/images/editorial/cloudflare-dkim-setup/cloudflare-dkim-setup-evidence-checklist.webp "1200x582") *Source: Palisade.* ![The evidence sequence for publishing and validating a sender-generated DKIM record](/images/editorial/cloudflare-dkim-setup/cloudflare-dkim-setup-validation-flow.webp "1200x829") *Source: Palisade.* ## Which setup method should I use? Use the method and exact values supplied by the service that sends the mail. The available material does not verify which DKIM record types Cloudflare currently supports for this workflow, or the current Cloudflare controls for creating them. Do not infer that every sender uses the same record type or host format. Some senders provide a TXT record with a DKIM public key. Others provide a CNAME record that delegates the DKIM lookup to the sender. The sender's account-specific setup instructions determine which record you must publish. Do not convert one form to the other. Use one controlled DNS change per sender and domain. If a selector already exists, stop before replacing it. The existing record may support active production mail. Follow the sender's rotation or migration process instead of overwriting a known working selector. A DNS provider may accept either a relative host label or a fully qualified domain name, depending on the interface. Confirm how Cloudflare renders the final owner name after saving. A duplicated zone name can leave the DKIM record at the wrong DNS owner. ## How do I configure SPF and DKIM for Cloudflare? Cloudflare does not generate SPF or DKIM values for an email sender. Obtain the sender's approved DNS instructions first. The steps below describe the evidence sequence without asserting unverified Cloudflare UI labels. ### 1. Open the correct Cloudflare account and DNS zone Sign in to the Cloudflare account that controls the authoritative DNS for the visible From domain. Confirm the selected zone before creating or editing anything. The current authenticated navigation path and exact record-creation labels must be confirmed in Cloudflare's current documentation or account interface. Do not use an old tutorial as proof of the present UI. ### 2. Select the sending domain in the email sender Open the sender platform that sends the mail in scope. Select the domain that appears in the production From address, then generate or reveal the sender's DKIM instructions. The selector, public key, CNAME target, and any verification token belong to that sender account and domain. Treat them as account-specific configuration, even when the resulting DKIM public key will be visible in public DNS. ### 3. Publish the sender-generated DNS record Create only the record type, owner name, and value that the sender supplies. The example below shows the record structure and is not a publishable Cloudflare record. **Record type:** Sender-generated, such as `TXT` or `CNAME` **Host (illustrative only):** ```text selector1._domainkey ``` **Value (illustrative only):** ```text Copy the complete record value generated in your sending provider account. ``` > Do not publish this example. Copy the complete host and value from the sender account that will sign your mail. Do not reuse another account's selector, target, token, or public key. Before saving, inspect the final owner name Cloudflare will publish. If the interface appends the zone automatically, entering a full domain can produce a duplicated name. Also check for an existing record at the same owner. A CNAME cannot coexist with other DNS data at the same owner. Do not replace an existing SPF TXT record to add a sender. SPF has one policy record for a domain, so sender-provided SPF content may need to be merged into the existing record. The available source material does not establish a Cloudflare-specific SPF editing workflow. Use the sending provider's current SPF instructions and preserve the existing policy until the merged record is reviewed. ### 4. Verify the record in the sending provider Return to the sender platform and use its documented verification process after the record is publicly available. The sender's status confirms what that sender account sees for its configuration. A green sender indicator does not prove that every production path signs mail or that a receiving mailbox accepted the signature. Continue to a delivered-message test. ### 5. Send a real test message Send a new message through the exact production path that uses the configured domain. Send it to a mailbox where you can inspect the complete message source. Record the visible From domain, the sender platform, the send time, and a redacted copy of the authentication results. Test each materially different route separately. A marketing platform and transactional provider can sign with different selectors or domains. ## How does this setup affect DMARC? DKIM supports DMARC only when the signing domain aligns with the visible From domain under the domain's DMARC policy. A record can exist in DNS while the sender uses a different selector, fails to sign, or signs with a domain that does not align. Check the published DMARC policy with Palisade's [DMARC checker](/tools/dmarc) before changing enforcement. A public record check cannot prove the behavior of a specific delivered message, a receiver's private filtering decision, or future mail from a newly added source. SPF and DKIM are separate authentication mechanisms. Do not assume that an SPF pass means DKIM is configured, or that a DKIM DNS record means SPF is correct. If the sender supports both methods, validate each one against a real message. ## How do I validate the setup? ### Check public DNS Query the exact owner name supplied by the sender after Cloudflare publishes the change. Compare the authoritative DNS answer with at least one public resolver. Use Palisade's [DKIM checker](/tools/dkim) to inspect public DKIM DNS. A lookup can help find a published record, but it cannot prove the exact production sender used that selector or that a delivered message passed DKIM. ### Check the sender status Return to the sender account and check its current domain-authentication or verification state. Preserve a dated record of the selected domain and status. The sender status validates the sender's view of the published configuration. It does not prove that all sending routes use the same key or signing domain. ### Inspect a delivered message Inspect a new message sent after the DNS change. Compare the visible From domain with the DKIM signing domain and selector shown in the message evidence. Do not accept a dashboard status as a substitute for this test. The delivered message is the evidence for the path that actually sent mail. ### Review DMARC reports After DMARC aggregate reports accumulate, review the configured domain's sources and authentication outcomes. Separate the sender you configured from other services that use the same domain. Palisade is AI-first, agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence supports it, while a human reviews the evidence and applies the change. ## Troubleshooting ### The sender cannot verify the domain Confirm that the sender-generated record was published in the authoritative Cloudflare zone for the intended domain. Compare the complete record owner and value with the sender account. Do not shorten the value or substitute an example from another sender. If the current Cloudflare UI is unclear, verify the workflow from current Cloudflare documentation before editing the record again. ### The DKIM record cannot be found publicly Check the final fully qualified owner name. A DNS interface that appends the zone can create a duplicate domain when a fully qualified owner is entered into a relative host field. Also confirm that you queried the selector generated by the sender, not a selector from an unrelated service. ### The sender shows verified but the delivered message fails Send a new message through the exact production route and inspect its authentication evidence. The verified configuration may apply to a different domain, message stream, or sending environment. Compare the configured sender domain and selector with the message evidence before changing DNS. ### DKIM passes but DMARC still fails Compare the DKIM signing domain with the visible From domain and inspect the domain's DMARC policy. A DKIM result for a different domain may not satisfy DMARC alignment. Check the published policy with the [DMARC checker](/tools/dmarc), then compare that DNS result with the actual delivered message and DMARC reports. ### An existing DNS record would be overwritten Stop the change. The existing selector or SPF policy may support active mail flow. Obtain the sender's documented rotation or coexistence instructions and prepare a rollback plan before editing production DNS. ## Check the published DKIM record after Cloudflare DNS changes After you publish the sender-generated record in the correct Cloudflare zone, inspect the public result with Palisade's [DKIM checker](/tools/dkim). Compare the lookup with the exact owner and value supplied by the sender, then verify the sender status and a newly delivered production-path message. A public DNS check cannot prove that the sender signed a particular message, repair a failed signature, monitor later DNS drift, or guarantee receiver acceptance. For an ongoing multi-domain workflow, Palisade analyzes DMARC aggregate-report data and identifies authentication or alignment issues, while your team reviews the evidence and applies DNS or policy changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=cloudflare-dkim-setup). ## Sources and further reading - [Cloudflare public website](https://cloudflare.com) - [Palisade DKIM checker](/tools/dkim) - [Palisade vendor email authentication guidance](/learning/vendor-email-authentication) - [Mimecast DKIM setup](/learning/mimecast-dkim-setup) ## Frequently asked questions ### Is DKIM still relevant? Yes. The available official source material for this guide does not establish current DKIM requirements or relevance claims. Before making a policy decision, consult current sender requirements from the mailbox providers that receive your mail and validate your own delivered-message and DMARC-report evidence. ### How do I set up DKIM? Only the email sender can generate the account-specific DKIM record values. Publish those exact values in the authoritative Cloudflare DNS zone, verify the sender's status, inspect a new delivered message, and review DMARC reports after data accumulates. ### How do I set 1.1.1.1 Cloudflare DNS? The question can mean different things: configuring a device to use a public resolver, changing a domain's authoritative nameservers, or publishing a DNS record. This guide covers publication of sender-generated DKIM records in a Cloudflare-managed DNS zone. The available material does not verify instructions for configuring `1.1.1.1`. ### Does Cloudflare generate my DKIM selector? No. The sending service generates the selector and DKIM DNS value for its own account and domain. Cloudflare publishes the record in DNS when it is the authoritative DNS provider for the domain. ### Can a DKIM DNS lookup prove mail is authenticated? No. A public lookup can show that a record is published. It cannot prove that a particular production message used the selector, passed DKIM, aligned with the visible From domain, or satisfied a receiver's private delivery decision.