Cloudflare SPF, DKIM and DMARC setup, step by step

To publish SPF, DKIM and DMARC in Cloudflare, obtain the records from the service that actually sends your email, select the correct Cloudflare zone, and add or edit the specified TXT or CNAME records under DNS → Records. Keep one SPF policy per owner, set authentication CNAMEs to DNS only, preserve existing DMARC policy, and finish with a delivered-message test. DNS publication alone does not enable signing in your email service. Cloudflare DNS record management

This guide covers Cloudflare as your authoritative DNS host. Cloudflare Email Routing and the newer outbound Email Sending service are separate configurations, explained below so their records are not confused with ordinary DNS hosting.

This is a documentation-based guide. No customer zone, provider account or delivered message was tested.

Choose the right Cloudflare task

Cloudflare now documents outbound sending through Workers, a REST API and SMTP. Its current onboarding requires Cloudflare DNS. Consequently, the blanket statement “Cloudflare cannot send email” is no longer a safe description of the whole product family. Cloudflare Email Sending

The current managed record sets also differ: Email Sending uses cf-bounce for bounce MX/SPF and cf-bounce._domainkey for its DKIM key; Email Routing uses root-level MX/SPF and a separate cf2024-1._domainkey selector. These are product-specific names, not records to add merely because your DNS is on Cloudflare. Use the actual onboarding record set and review any proposed DMARC change. Email Service domain configuration

For an external sender, start with its configuration guide. EmailAuth's Google Workspace authentication guide and Microsoft 365 authentication guide explain the sender-side work that Cloudflare DNS cannot perform for you.

Prepare the records and a rollback copy

Identify the authoritative DNS zone before editing. A registrar account, a web host and the active DNS provider can be three different systems. For a normal full Cloudflare setup, the delegated nameservers must be the assigned Cloudflare nameservers. For a separately delegated sending subdomain, edit its authoritative zone rather than assuming the parent controls it. Cloudflare says domains added by a hosting partner should have records managed through that partner. Cloudflare management prerequisites

Collect:

• The actual visible From domain and SMTP MAIL FROM domain used by each sender.
• The complete record type, owner name, value or target, and TTL supplied by each email service.
• Each intended DKIM signing domain and selector, plus its activation instructions.
• Existing SPF authorizations, DKIM selectors, DMARC settings and report destinations.
• Access to the sending service and controlled external test mailboxes.

In Cloudflare, open DNS → Records → Import and Export → Export to save a zone copy. Also record the affected rows, proxy state and any product-managed status. A backup is a reference for a targeted rollback, not a reason to import an entire old zone over unrelated changes. Cloudflare export instructions

Use the following names only to understand owner placement. They are fictional examples, not a provider's generated records:

If news.example.com is separately delegated and you edit that child zone, the full DKIM owner mail2026._domainkey.news.example.com uses the relative name mail2026._domainkey, not mail2026._domainkey.news. Publish in the zone that actually serves that owner.

Review the resulting full owner after saving. Never create mail2026._domainkey.example.com.example.com by appending the zone twice. A CNAME target is a destination hostname, not the Name field and not a URL containing https://.

Publish SPF at the correct owner

SPF evaluates the sending IP against the policy for the SMTP envelope identity, normally MAIL FROM. That identity can differ from the visible From address. A provider-owned return path may pass SPF without aligning with your brand, and adding that provider to your root SPF does not change its return path. SPF also has a separate HELO evaluation. SPF identities and record selection

1. Search the correct owner in DNS → Records for an existing TXT value beginning v=spf1.
2. If it exists, select Edit. Merge only the authorizations your sender actually requires into the existing policy.
3. If it does not exist and your sending service requires it there, choose Add record → TXT.
4. Enter the correct Name, approved complete Content and TTL, then save.
5. Validate the whole policy, not just the newly added include.

Do not publish a second SPF policy at the same owner, concatenate two v=spf1 strings, or place a new mechanism after all. Preserve legitimate existing senders and the approved terminal qualifier. Avoid +all, and do not replace provider includes with a one-time copied IP list that nobody maintains. Check the ten DNS-querying-term limit across evaluated mechanisms and nested dependencies. The number of visible includes is not the total lookup cost. SPF evaluation and limits

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Some providers issue a CNAME for a dedicated return-path owner and manage SPF at its target. Follow that exact arrangement instead of adding TXT at the CNAME owner. Do not create an obsolete DNS record of type “SPF”; the published policy belongs in TXT.

Publish DKIM without changing the selector

Get the DKIM configuration from the sender's verified domain workflow first. Depending on the provider, this may be one public-key TXT record or several CNAMEs. Do not generate a random public key and publish it for a hosted service that does not hold the matching private key.

For TXT, choose TXT, enter the issued owner and paste the full public value into Content. Keep the p= material intact. A long TXT answer may contain multiple quoted strings within one record; those strings form one logical value. Several separate TXT key records at one selector are not a substitute. DKIM key representation

For CNAME, enter the issued Name and Target and select DNS only. TXT records cannot be proxied, so there is no TXT orange-cloud toggle to fix. Cloudflare documents that only A, AAAA and CNAME records can be proxied. Cloudflare proxy behavior

If Cloudflare refuses the name because another record occupies it, inspect the existing service before deleting anything. Ask the sender for a different selector when appropriate. An ordinary CNAME owner cannot also carry unrelated record data. Cloudflare same-name conflicts

Also check CNAME flattening. Flattening all CNAMEs can prevent a third-party validator from seeing the expected CNAME answer. Preserve the authentication delegation rather than treating it like a website alias. Cloudflare CNAME flattening

For the required literal authentication aliases, turn per-record Flatten off where available, and ensure applicable zone-wide settings do not suppress them. Cloudflare offers per-record flattening on paid zones; a flatten-all setting cannot be overridden per record. Apex CNAMEs are flattened by default on all plans, and same-zone targets are flattened regardless of the setting. If mandatory behavior or shared settings prevent the required literal answer, stop and coordinate a supported configuration with the sender and DNS owner instead of changing the whole zone blindly. Preserve NS delegation and publish with the actual authority. Cloudflare flattening settings and plan limits, CNAME verification controls.

After DNS is visible, return to the email service. Complete its verification and any separate enable signing step. Cloudflare's successful save cannot activate Google Workspace signing, enable Microsoft 365 DKIM, or select the branded sending domain inside another application.

Publish DMARC and preserve reporting

DMARC evaluates the visible From domain against authenticated SPF and DKIM identities. Either aligned SPF or aligned DKIM can pass DMARC. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. DMARC alignment

Before creating _dmarc, inspect the existing policy and any policy inherited by the actual From subdomain. Preserve a working policy, its report destinations and alignment settings. Do not replace p=reject or p=quarantine with a beginner example simply because a wizard suggests it.

Only if no established policy applies, including an inherited policy, use a separately approved first-policy monitoring rollout. Choose DNS → Records → Add record → TXT in the authoritative Cloudflare zone. Map the full owner to the selected zone:

Choose the applicable row and zone, not both zones for the same owner. Confirm the editor's resulting full owner, enter the approved policy as the TXT value, and save. The illustrative value below is not a replacement for an existing or inherited policy. Replace its placeholder mailbox with an authorized working report destination before deployment:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none requests monitoring, not rejection. A reporting address must be provisioned to receive and process reports; an external reporting service may require destination authorization. Follow its current setup instructions and the external-destination verification rules. Reports contain operational data, so agree ownership, access and retention. DMARC aggregate reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Cloudflare DMARC Management can display reporting information and an email-record overview. It is not the switch that enables DKIM at an unrelated sending provider. Review its proposed records against your existing policy before making changes. Cloudflare DMARC Management and security record overview

Verify authoritative and public DNS

These are read-only examples. Replace example.com, ns1.example.net, bounce and mail2026 with the actual zone, one of its authoritative nameservers, envelope owner and selector:

dig +short NS example.com
dig @ns1.example.net example.com TXT +noall +answer
dig @ns1.example.net bounce.example.com TXT +noall +answer
dig @ns1.example.net mail2026._domainkey.example.com CNAME +noall +answer
dig @ns1.example.net mail2026._domainkey.example.com TXT +noall +answer
dig @ns1.example.net _dmarc.example.com TXT +noall +answer
dig @1.1.1.1 mail2026._domainkey.example.com TXT +noall +answer
dig @8.8.8.8 _dmarc.example.com TXT +noall +answer

A TXT-based selector should return the issued key. A CNAME-based selector should expose the issued target; also query that target's TXT record through a recursive resolver. An authoritative server for your zone may return the CNAME without resolving a target in someone else's zone.

At the envelope owner, expect exactly one SPF policy, alongside any unrelated TXT records. Evaluate it for syntax, nested lookup limits and the actual sending IP. At the applicable DMARC owner, expect one policy, or the intentional hosted-policy arrangement already in use. Repeat queries for a delegated subdomain using its own authoritative servers.

If authoritative DNS is correct but a recursive answer is old, compare TTLs and cached negative responses. If authoritative DNS is wrong, waiting does not repair it. “A TXT record exists” is not a message-level SPF pass, DKIM pass or alignment result.

Activate signing and inspect a delivered message

Send through each actual production route after the email service confirms activation, using harmless content and controlled recipients. A direct test from a staff mailbox does not validate a marketing tool or an application relay.

Inspect the receiving system's trusted Authentication-Results and the original message's headers. Record:

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For this setup's acceptance, require the intended branded DKIM signature to pass and align. SPF-only DMARC success is insufficient proof that DKIM setup worked. Record SPF pass and alignment separately; if a provider-owned envelope cannot align, document that limitation rather than claiming dual alignment. Any actual SPF error still needs investigation.

For example, From news@example.com, DKIM d=example.com with a passing signature, and passing SPF for bounce.example.com satisfy relaxed alignment. Under strict SPF alignment, that subdomain is different from example.com; the exact-match DKIM signature can still supply the DMARC pass. This is a fictional interpretation example, not a tested Cloudflare account.

Troubleshoot Cloudflare authentication records

For deeper diagnosis, see SPF permerror and finding a DKIM selector from a message.

Rollback without breaking another service

Restore only the affected manual DNS change from the approved backup. Coordinate DKIM rollback with the signing provider: reverting a key while the provider signs with its replacement can break every new signature. Keep old selectors available for the provider's required overlap period rather than deleting them immediately after one passing test.

Cloudflare's current documentation says only Email Routing records can be unlocked; Email Sending records remain managed. Removing an Email Sending domain deletes the records it created, including its created DMARC record. Disabling Email Routing also deletes service-associated records even if they were previously unlocked and edited. Those operations are not ordinary DNS rollback buttons. Plan any service migration separately, inspect dependencies and verify the final mail flow. Managed records and removal consequences

Keep domain-wide DMARC enforcement separate from this DNS change. Review all legitimate senders and indirect mail paths before strengthening policy. A successful sample from one application cannot establish that every departmental or seasonal sender is ready.