SPF, DKIM & DMARC on Cloudflare

Since February 2024, Google says bulk senders, defined as those sending 5,000 or more messages in a day to Gmail personal accounts, must authenticate mail with SPF or DKIM and publish DMARC. That requirement made DNS hygiene a daily operational issue, not a quarterly cleanup task.

If your domain lives on Cloudflare, the good news is that SPF, DKIM, and DMARC are straightforward to publish. The hard part is not adding records, it is adding the right records, in the right place, with the right alignment for the mail streams you actually send.

For RevOps, lifecycle, and deliverability teams, the goal is simple, make sure Gmail, Outlook, Yahoo, and Apple Mail can connect your visible From domain to an authenticated identity. Cloudflare is where that decision shows up in DNS.

What SPF, DKIM, and DMARC do on Cloudflare

SPF answers, “was this sending server allowed?” DKIM answers, “was this message signed by the expected domain?” DMARC answers, “does that authenticated identity align with the domain the recipient sees in From?”

That last point is the one teams miss most often. You can have SPF and DKIM both present, and still have DMARC fail if neither one aligns with the From domain. On Cloudflare, that usually means the DNS record exists, but the sending platform is still signing or returning mail for the wrong domain.

How to add SPF in Cloudflare without creating a lookup problem

In Cloudflare DNS, SPF is published as a TXT record. Most teams publish it at the root hostname, shown as @, unless they send from a dedicated subdomain such as mail.example.com or mg.example.com.

What a good SPF setup looks like

• One TXT record at the sending hostname that starts with v=spf1
• All legitimate sending services included in that single record
• A clear ending policy such as ~all while testing or -all when you are confident

A common example is a root SPF record that includes Google Workspace for employee mail and an ESP for campaigns. The exact value depends on your providers, but the important rule is that Cloudflare should show one SPF TXT record for that hostname, not two or three separate SPF records.

Why that matters, SPF does not merge records for you. If you publish multiple SPF records at the same hostname, receivers can treat the result as invalid. Gmail may still make a delivery decision using other signals, but you have created avoidable ambiguity.

The second SPF trap is the 10 DNS lookup limit. Each include:, some a and mx mechanisms, and nested vendor records all count. If your record is trying to authorize five different tools, the issue is rarely Cloudflare itself. The issue is that your sending architecture has outgrown a single untended SPF record.

Cloudflare SPF checklist

• Create a TXT record, not an MX or CNAME
• Use @ for the root domain unless your provider tells you to use a subdomain
• Keep the value on one logical record, even if Cloudflare displays it cleanly in the UI
• Do not publish a second SPF record for the same hostname
• Retest after every new ESP or CRM connector that sends mail

How to add DKIM in Cloudflare and avoid selector mistakes

DKIM is where Cloudflare setup diverges most by provider. Some platforms ask you to publish a TXT record that contains the public key. Others ask you to publish CNAME records that point to keys they host.

The rule is simple, publish the record type your provider asks for. If the ESP gives you a CNAME for s1._domainkey.example.com, do not convert it into TXT because “DKIM is a TXT thing.” Many modern ESPs verify domain control with CNAME based DKIM delegation.

Where teams trip up in Cloudflare

• The hostname is entered incorrectly, so selector._domainkey becomes selector._domainkey.example.com.example.com
• The record type is wrong, usually TXT instead of CNAME
• The public key is broken by missing characters or pasted quotes
• The ESP is signing with a different selector than the one you published
• The visible From domain uses one domain, but DKIM signs with another

A practical example, if your marketing platform sends with a From address of news@example.com but signs DKIM as d=espvendor.com, DKIM may technically validate, yet DMARC will not see alignment with example.com. The fix is usually custom DKIM on your own domain, published through Cloudflare.

For deliverability, DKIM is often the most durable authentication method because forwarding can break SPF, while DKIM survives as long as the message body and signed headers are not materially altered. That is one reason DKIM alignment matters so much for Gmail and Yahoo decisioning.

How to publish DMARC in Cloudflare and choose the right starting policy

DMARC is a TXT record published at _dmarc.example.com. In Cloudflare, the hostname is typically _dmarc and the value begins with v=DMARC1.

If you are rolling out DMARC for the first time, start with reporting and observability. A typical first record looks like this in structure: v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s. The exact alignment mode can be relaxed or strict, but you should choose it deliberately.

What DMARC is really deciding

DMARC does not ask whether a message had SPF or DKIM somewhere in the header. It asks whether SPF or DKIM passed and whether that result aligns with the visible From domain.

• SPF alignment checks the envelope or return-path domain against the From domain
• DKIM alignment checks the signing domain in d= against the From domain
• DMARC pass needs at least one of those to align

This is why teams can be puzzled by messages that show SPF=pass and DKIM=pass in raw headers, while DMARC still shows fail. The underlying domains are not the same domain, or not close enough under your chosen alignment mode.

For most teams, p=none is the right first step, because it lets you see who is sending on behalf of the domain before you change receiver handling. Once legitimate streams are aligned, you can move to quarantine or reject with more confidence.

That move should be operational, not symbolic. If Sales sends through Outlook, Marketing through an ESP, and Support through a ticketing platform, DMARC policy only becomes stronger when each stream has aligned SPF or DKIM in place.

Cloudflare-specific checks before you call setup complete

Cloudflare itself is usually not the deliverability problem. Configuration drift is. Before you mark the project done, check these four things in the Cloudflare zone.

1. No duplicate TXT records for SPF

Cloudflare will happily let you publish multiple TXT records at the same hostname. SPF receivers will not interpret that as “helpfully combined.” They see multiple SPF policies and the result can become invalid.

2. DKIM selectors are published exactly as your provider expects

If the provider says the host is k1._domainkey, use that exact host. If Cloudflare appends the zone automatically, do not paste the full domain again unless the UI expects a fully qualified name.

3. DMARC report mailbox can actually receive mail

Publishing rua=mailto:dmarc@example.com is only useful if that mailbox or processor exists. Otherwise, you created a DMARC record with no feedback loop. For RevOps teams, that means less visibility into shadow senders and stale platforms.

4. Your sending platforms have finished domain verification

Cloudflare can show the record immediately, but your ESP or CRM may still show “pending” until it rechecks DNS. Wait for provider verification, then send a real message and inspect the Authentication-Results header for Gmail or Outlook.

The operating mindset here is not “records published, project done.” It is “records published, providers verified, live messages aligned.” That is what moves the needle on inbox placement and protects your domain reputation over time.

Related reading: dkim vs spf and spf and dkim deliverability.

Run your first deliverability test with Mailora, then confirm SPF, DKIM, and DMARC are not only present on Cloudflare, but aligned in the messages your recipients actually get.

FAQs

Can I have multiple SPF records in Cloudflare?

No. You can have multiple TXT records at a hostname, but only one valid SPF policy that starts with v=spf1. Combine all authorized senders into that single record.

Should DKIM be a TXT record or a CNAME in Cloudflare?

Use whichever record type your mail provider specifies. Some providers use TXT public keys, others use CNAME delegation for the selector.

What DMARC policy should I start with on Cloudflare?

Usually p=none. It gives you reporting and visibility first, so you can confirm all legitimate mail streams align before tightening policy.

Why does DMARC fail when SPF and DKIM both pass?

Because DMARC requires alignment. SPF or DKIM can pass for a different domain than the visible From address, and DMARC will still fail.

Do I need separate SPF, DKIM, and DMARC records for subdomains?

Often, yes. If a subdomain sends mail independently, publish the records needed for that specific hostname and configure the sending platform to use that subdomain correctly.