How do you configure DKIM, SPF and DMARC records in Cloudflare DNS?

What each DNS record does in the mail authentication chain

Cloudflare is only the DNS host here, so the real job is to publish the mail service’s exact DKIM, SPF, and DMARC values without altering them. SPF is the policy record for who may send, DKIM is the cryptographic signature published by your mail system, and DMARC ties them to the visible From domain through alignment and policy.

That separation matters because each record solves a different failure mode. SPF alone can permit forwarding-related breaks, DKIM alone does not tell receivers what to do with failures, and DMARC depends on both records being syntactically correct and aligned with the domain you actually present to recipients.

For a practical reference point on mail-authentication architecture, the Email Security Guide covers how SPF, DKIM, DMARC and routing fit together in a broader mail stack.

The DNS layer is also where mistakes become visible immediately: a missing selector, an extra character in SPF, or a DMARC policy published on the wrong host name can break authentication without any mailbox-side change. The operational question is not just whether the record exists, but whether it matches the sender and the service that signs or transmits mail.

How to publish the records correctly in Cloudflare

Start with the exact hostnames and values from your mail provider. In Cloudflare DNS, SPF is usually published as a TXT record at the root domain, DKIM is usually one or more TXT records under a selector label, and DMARC is published as a TXT record at _dmarc for the domain you want protected.

If your provider gives multiple DKIM selectors, publish each one exactly as provided. If you use subdomains to send mail, decide whether they need their own SPF and DMARC policy or whether they inherit the organisational policy, because DMARC evaluation is driven by the domain relationship, not by the presence of a record alone.

To avoid cross-record drift, keep the mail vendor’s published values as the source of truth and treat Cloudflare as a registry. The DMARC, SPF and DKIM Guide is a useful navigation point for alignment, rollout staging, and record interpretation.

In Cloudflare specifically, the practical checks are simple: use the correct record type, confirm the name field is exactly where the mail service expects it, and avoid accidental proxies or extra formatting. TXT values are often long, especially DKIM keys, so copy them exactly and recheck for wrapping or quote changes before you save.

If you want a broader view of how mail security controls fit together, the Email Security Guide also helps distinguish DNS configuration from downstream filtering, remediation, and policy enforcement.

What to verify after publishing and what usually breaks

After the records propagate, verify three things: the DNS lookup resolves as expected, the sending service signs mail with the DKIM selector you published, and the visible From domain aligns with the SPF-authenticated or DKIM-signed domain that DMARC checks. A record that is “present” but misaligned can still fail in real delivery.

Look first for common setup errors: publishing SPF on a subdomain when the service sends from the apex, using the wrong selector name for DKIM, or publishing DMARC at a non-standard label. Another frequent issue is changing the mail provider but leaving old SPF includes or stale DKIM selectors behind, which makes the configuration appear correct while mail reputation quietly degrades.

It can help to think of the records as trust declarations. SPF and DKIM identify who is allowed to speak for the domain, while DMARC tells receivers how strictly to react when that trust chain fails. A good mail rollout usually starts with monitoring and only then moves toward enforcement.

The DNS Security Guide is useful when you need to distinguish ordinary mail-authentication records from broader DNS hygiene issues such as logging, takeover risk, or accidental zone changes.

Risk and Threat Considerations

Mail-authentication records are often treated as routine DNS entries, but they directly affect spoofing resistance and delivery trust. A weak or inconsistent SPF, DKIM, or DMARC setup can let impersonation succeed, block legitimate mail, or create blind spots when a sender changes infrastructure without updating DNS.

Failure mechanism: Attackers benefit when a domain has permissive or stale mail-authentication policy, because recipients may have less evidence to reject forged mail or may accept mail from unapproved infrastructure. Operationally, the same misconfiguration can also break legitimate mail during forwarding, vendor migration, or key rotation.

Impact: The practical impact is domain impersonation, delivery disruption, reduced sender trust, and in some cases easier business email compromise. If DMARC is moved to enforcement before SPF and DKIM are stable, you can also create self-inflicted outages for legitimate messages.

Practitioner Guidance

What to verify: Confirm the sender documentation before you publish anything in Cloudflare. The important check is not “does the record exist?” but “does the record exactly match the domain, selector, and sending path your provider uses?”

Implementation sequence: Publish SPF and DKIM first, validate that outbound mail passes authentication, then move DMARC from reporting toward quarantine or reject only after you have enough message-flow evidence to trust the alignment.

Common mistake: Treating DMARC as a single switch. In practice, the safest rollout is staged, because policy enforcement without validated sending coverage is the fastest way to block your own mail.

Practitioner takeaway: Cloudflare is the publishing point, not the policy owner, so correctness depends on exact record values, correct labels, and alignment with the real mail flow rather than on DNS presence alone.

Related resources from NHI Mgmt Group

• Why do misconfigured SPF, DKIM, and DMARC records create real phishing and spoofing risk?
• Why do SPF, DKIM, and DMARC all matter for enterprise email security?
• What do security teams get wrong about SPF, DKIM, and DMARC?
• Why do SPF, DKIM, and DMARC need to be aligned?