How to Set Up SPF, DKIM, and DMARC in Cloudflare

If you are trying to learn how to set up SPF DKIM and DMARC in Cloudflare, start with one plain fact: Cloudflare stores the DNS records, but your mail provider supplies the values. That sounds small. It is not small.

Cloudflare is the place where the records live, and that means you will edit TXT or CNAME entries in its DNS panel. The actual SPF include string, the DKIM selector, the public key, and the DMARC policy come from the service that sends your mail, whether that is Google Workspace, Microsoft 365, SendGrid, Mailgun, or another platform. Without those values, you are guessing.

1. Confirm what Cloudflare can and cannot do for email authentication

Cloudflare does not invent SPF, DKIM, or DMARC values. It only publishes them. If your provider says to add a TXT record for SPF, Cloudflare can host it. If the provider gives you a DKIM selector and a CNAME target, Cloudflare can host that too. But it cannot decide which servers may send mail for you.

This matters because people often open Cloudflare first and search for a magic button. There is none. You need the exact record content from your sender before you touch DNS, or you risk publishing a record that passes a dashboard check and fails in a real mailbox.

2. Collect the DNS values from your email-sending platform

Before you edit anything, collect three things from the provider’s documentation. First, gather the SPF include mechanisms and any IP addresses the service wants in your SPF record. Second, gather the DKIM selector names and the public key data, or the CNAME targets if the provider uses CNAME-based DKIM. Third, gather the DMARC policy string, including the policy you plan to start with and any reporting tags.

Write the values down in one place. Use the exact selector names. If your provider gives you two selectors, do not rename them because they look messy. If the documentation says the record should be `_spf.example.net`, keep it that way. Tiny formatting mistakes cause long afternoons.

There is a useful habit here: capture the sender name, the hostname, the record type, and the destination string in one table before you log in to Cloudflare. That makes the editing phase faster, and it also prevents the common mistake of pasting the right value into the wrong name field.

3. Add an SPF record in Cloudflare DNS

In Cloudflare, open DNS and create or edit the TXT record at the root of the domain if your provider sends mail from the bare domain. Some services use a subdomain instead, such as `mail.example.com`, so use the hostname your provider specifies, not the one you assume. One hostname. One record.

An SPF record should usually exist only once for a hostname. That is the point people miss. If you already have an SPF TXT record, do not create a second SPF TXT record beside it. Merge the authorized senders into a single string so the receiving server sees one policy, not two competing answers.

A typical SPF value includes mechanisms such as `include:` or `ip4:`. If your service adds a second sender later, update the existing record instead of adding another one. A duplicate SPF record can cause a permerror, which means receiving systems may treat the check as failed even if the individual parts look correct.

Use the record name your provider gives you. For the root domain, Cloudflare often shows `@` as the name field. For a subdomain, enter that exact label. Do not add quotes around the value unless your provider explicitly tells you to do so. Cloudflare stores the text as plain DNS content.

4. Publish DKIM TXT or CNAME records in Cloudflare

DKIM is where the selector matters. The provider may give you a TXT record like `selector1._domainkey` with a long public key, or it may give you a CNAME record that points to another hostname. Cloudflare supports both, but the type must match what the provider says. A TXT value in a CNAME field will not help you.

Many services use two selectors. That is normal. Google Workspace often uses two keys during rotation, and other providers do something similar so one key can be replaced without interrupting delivery. If the sender gives you `s1` and `s2`, publish both records. If a second sender uses a different selector family, keep those records separate too. The names can look repetitive; the records are not redundant.

Enter the DKIM hostname exactly as given. If the provider tells you to create `selector1._domainkey.example.com`, use that full label in Cloudflare. If the provider gives a CNAME target, paste the destination exactly as written. Cloudflare does not need a translation. It needs accuracy.

For teams following DKIM SPF DMARC setup for transactional, the same rule applies even when the mail volume is small: the selector in DNS must match the selector in the message header. If they differ, DKIM fails. No drama, just failure.

5. Create a DMARC record at _dmarc

DMARC belongs at `_dmarc.yourdomain.com`. In Cloudflare, create a TXT record with that exact name. The value begins with `v=DMARC1`, then adds your policy and optional tags. A common starting policy is `p=none`, because it lets you collect reports before you block anything. That is the least aggressive starting point.

If your organization is ready to receive reports, add the `rua` tag with the aggregate reporting address and, if needed, the `ruf` tag for forensic reports. Use an address that someone actually monitors. A dead mailbox is not a strategy. It is a trap.

One practical rule helps here: start with a DMARC policy that matches your current tolerance for false positives, then tighten it later after you know the legitimate senders are aligned. If you move too fast, you can block invoices, alerts, or password resets. That gets noticed immediately.

Cloudflare will store the DMARC TXT record like any other text entry, but the details matter. The record name must be `_dmarc`, not `dmarc`, not `_dmarc1`, and not the root domain. The policy string must follow the syntax your provider expects. If your mail platform suggests tags such as `sp`, `adkim`, or `aspf`, add them only when you understand the effect.

6. Check Cloudflare-specific DNS settings that can block validation

Cloudflare has one setting that causes more confusion than it should: proxying. Email authentication records should not be proxied. SPF, DKIM, and DMARC live in DNS, not behind the orange cloud. If you accidentally proxy a mail-related hostname, you are mixing web traffic rules with email DNS records.

Record names are another common failure point. A DKIM selector that should be `selector1._domainkey` may be entered as `selector1._domainkey.` with a stray dot, or as `selector1 domainkey` with a space copied from a provider page. Cloudflare accepts many DNS entries, but receiving systems are less forgiving than the interface.

Older records can also interfere. If an old SPF TXT record remains beside the new one, or if a stale DKIM CNAME still points to a retired service, validation can fail in ways that look random. Remove the dead entry only after you confirm it is no longer needed. That keeps the live sender intact.

If you are also working on email authentication setup for transactional email, this is the moment to check every sending host listed by the vendor. A forgotten subdomain can make a support message pass while a receipt message fails, and that split behavior is hard to spot until a customer complains.

7. Verify propagation and mail authentication from Cloudflare-managed DNS

After saving the records, wait for DNS propagation. The exact time depends on your TTL and the resolver cache in front of you, so do not assume the record is visible everywhere the moment Cloudflare says it is saved. Check externally with a DNS lookup tool and confirm each record name returns the expected value.

Then send a real test message from the service that uses the records. Do not test from a random inbox that bypasses your normal mail flow. Open the message headers in the receiving mailbox and look for SPF pass, DKIM pass, and DMARC alignment pass. The message can still land in spam for other reasons, but the authentication result should tell you whether the DNS side is correct.

One quick check is enough for the first pass, but a second check from a different mailbox gives you a better signal. A Gmail test and a Microsoft 365 test can behave differently if one resolver sees the old record briefly while another sees the new one. That is not rare. It happens.

If deliverability is part of the same project, pair this work with email deliverability best practices. Authentication is not the whole story, but it is the part that lets receivers decide whether your domain is speaking for itself.

8. Update records when your mail provider changes

Mail setups change. A provider rotates DKIM keys, a marketing platform is added, or a transaction service is moved after a migration. When that happens, update the DNS records in Cloudflare before you switch traffic, not after. That order saves you from a day of broken signatures.

DKIM rotation is usually the cleanest change. The provider gives you a new selector and key, you publish it in Cloudflare, and you wait until the new selector validates before retiring the old one. Keep both live during the transition if the provider supports it. Two selectors are easier than one outage.

SPF changes are a little more delicate because the record must stay under the DNS TXT size and lookup limits set by the SPF standard. If a new sender joins the stack, add its include mechanism to the existing SPF record instead of stacking another record beside it. If you are close to the lookup limit, reduce unnecessary includes where possible and confirm the provider’s current guidance.

For teams that send through multiple services, maintenance gets easier if one person owns the list of authorized senders. That list should name the service, the hostname, the DKIM selector, and the date of the last change. A simple table keeps Cloudflare edits consistent, and consistency matters more than cleverness.

If bounce handling and sender changes are part of the same mailbox project, the same discipline helps with email bounce handling best practices. A provider migration can change both authentication and error behavior on the same day, and neither side should be guessed at.

Cloudflare makes the publishing part straightforward, but the records still need discipline. One sender. One SPF record. Each DKIM selector in the right place. One DMARC record at `_dmarc`. If you keep those four points straight, the rest is mostly patience, a few header checks, and the willingness to update DNS before the next platform change arrives.