How to set up SPF, DKIM and DMARC on Cloudflare

Cloudflare doesn't host your email — it hosts your DNS. So it's where you publish the three records, but the values come from your mail service (Google Workspace, Microsoft 365, your web host, your campaign tool). Everything happens on the DNS Records page. Budget 10 minutes, and here's the pleasant surprise: most changes are live in 5 to 15 minutes, where most registrars quote 24 to 48 hours.

These three settings let receiving mail servers check that a message claiming to be from you really is from you. They do not guarantee your email reaches the inbox — your content and your sending reputation matter at least as much — but without them, anyone can send email in your name.

The Cloudflare-specific trap is somewhere else entirely: it isn't the records, it's the orange cloud. One wrongly proxied record and your mail stops arriving, with nothing to do with SPF or DKIM. More on that below.

What we don't do: we never touch your DNS zone. This guide tells you what to type and where. You're the one who saves it, in your own account, with your own credentials.

The records to copy and paste

1. SPF — who is allowed to send as you

What you must replace: WHATEVER-YOUR-SERVICE-GIVES-YOU with the value your mail service published. Cloudflare has no SPF value of its own — unless you use its own mail routing product (see below).

If you have several senders, they all go in one line:

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all

⚠️ Two rules Cloudflare states plainly in its own docs:

• One SPF record per domain. Two v=spf1 records means broken SPF, not doubled SPF.
• Ten DNS lookups maximum. Every include:, a, mx or redirect consumes at least one, and include: values often contain more. Past 10, the check returns an error (permerror) and your SPF fails entirely — not partly, entirely.

⚠️ If you enable Email Routing, Cloudflare publishes an SPF record on your root domain itself (v=spf1 include:_spf.mx.cloudflare.net ~all). If you already had an SPF line for your mailbox provider, you now have two — which is exactly the conflict described above. Check, and merge into one line.

2. DKIM — the signature on your messages

Cloudflare doesn't generate a DKIM key (except for its own sending service). Your mail service does, and the format changes from one to the next:

You copy exactly what your service shows you: the key belongs to your domain, it can't be guessed, and it must never be copied from a tutorial.

Three things to know before you paste your key:

a) The quote mark in the middle of the value is normal. A 2048-bit DKIM key runs past 255 characters. The DNS protocol then requires it to be split into quoted chunks — so you'll see something like "first part" "second part". It isn't an error, it isn't a Cloudflare quirk (every provider does it; Cloudflare just has the decency to show you), and the checking server reassembles the pieces. Don't delete the quotes by hand.

b) A CNAME-based DKIM record is created proxied by default — and that's trap number one. Cloudflare's own rule: only A, AAAA and CNAME records can be proxied, and "Proxying is on by default". A TXT record (_dmarc, SPF, a TXT-based DKIM) can never be proxied — the question doesn't arise. But a CNAME DKIM record (selector1._domainkey, s1._domainkey…) comes into the world with an orange cloud, and your mail service can no longer find its key. Switch it to DNS only (grey) the moment you create it. Cloudflare has an entire troubleshooting page dedicated to this exact case.

c) A CNAME-based DKIM record can also be broken by CNAME flattening. If that option is on, Cloudflare turns the CNAME into an A record — and your mail service can no longer find its key. If a CNAME DKIM record stubbornly refuses to validate even with a grey cloud, that's the next thing to check.

3. DMARC — the instruction you give to inboxes

What you must replace: YOU@YOUR-DOMAIN.com with an address you actually read. That's where your reports land.

Why p=none and not p=reject straight away: p=none means "watch and tell me" — nobody gets blocked, and you receive the reports. You watch for two to four weeks, confirm every legitimate sender is recognised, and only then tighten one notch to p=quarantine, then p=reject.

⚠️ If you use Cloudflare's own sending product ("Email Sending"), know that it publishes a _dmarc record itself — at p=reject. A strict policy you didn't choose, published before you've read a single report. If other services also send as your domain, make sure they pass DMARC before leaving that p=reject in place — otherwise replace it with the p=none value above and tighten in steps.

The click path in the Cloudflare dashboard

Adding a DNS record

1. Sign in to the Cloudflare dashboard, select your account, then your domain.
2. Go to the DNS Records page.
3. Select Add record.
4. Choose the Type (TXT or CNAME).
5. Fill in Name and the value field — its label changes with the type: Content for TXT, Target for CNAME, Mail server for MX.
6. For A, AAAA and CNAME records, check the Proxy status — see the warning below.
7. Leave TTL on Auto, then Save.

The Name field wants the relative name. For your root domain, type @ — Cloudflare's docs say it outright: "to create a zone apex record, use @ for the record Name". For DMARC, type _dmarc and nothing else. Leading underscores are perfectly valid in DNS — Cloudflare says so itself: "Underscores are valid in DNS and commonly used for service records."

⚠️ Proxying is on by default. Cloudflare's own wording: "proxying is on by default when you onboard a domain via the dashboard." Only A, AAAA and CNAME records can be proxied — TXT and MX records are always DNS-only, so your SPF and DMARC records are safe. Any CNAME you add for email, though — and that includes every ._domainkey DKIM record — needs its cloud switched to grey (DNS only), or the outside world sees a Cloudflare IP instead of your provider's hostname, and validation fails.

Cloudflare's free DMARC tool

Cloudflare offers DMARC Management, which in its own words "helps you track every source that is sending emails from your domain and review DMARC reports for each source". It's available on all plans, and requires your DNS to be on Cloudflare.

1. Dashboard → select your account and your domain.
2. Email → DMARC Management.
3. Enable DMARC Management.

What it does: if you have no DMARC record yet, it offers to create one. If you already have one, it adds a second rua address, at Cloudflare, so it receives a copy of your reports. Your own address stays in place. For each record it analyses (SPF, DKIM, DMARC), it reports a status of passed or failed — two states, not three; the warning about the 10-lookup SPF limit is a separate signal.

Two limits to know: it only works on the root domain (not on a subdomain like blog.yourdomain.com), and you should allow up to 24 hours for the first report.

We'll say this plainly: if all you want is to see DMARC reports arrive, this tool is enough and it's free. What it doesn't do is tell you in plain language what those reports mean, warn you when a new service starts sending in your name, or walk you to p=reject without breaking anything. That's where we come in.

We never touch your DNS zone. You stay in control of your own domain: we tell you what to type and where, and we tell you afterwards whether it worked.

The 3 mistakes we see most often on Cloudflare

1. An orange cloud on whatever your MX record points at

This is the Cloudflare mistake, and it has nothing to do with SPF or DKIM. The Cloudflare proxy — the orange cloud — routes web traffic through Cloudflare's servers. It can't carry email protocols (SMTP, IMAP, POP3). Your MX record itself is always DNS-only; Cloudflare doesn't proxy those, or TXT records. But the hostname it points at, typically mail.yourdomain.com, is often an A record somebody proxied without thinking.

How you spot it: you stop receiving anything, or your mail client can't connect to the server any more. In the DNS list, the A record for mail shows an orange cloud instead of a grey one.

The fix: click the cloud to switch it back to DNS only (grey). Check every hostname your mail setup uses the same way: the outgoing server, the incoming server, autodiscover — and your CNAME DKIM records (…._domainkey), which are proxied by default at creation.

2. Two SPF records, or more than 10 DNS lookups

This happens the moment you plug in one more tool: you add a second v=spf1 line instead of extending the one you have. A frequent Cloudflare-specific variant: you enable Email Routing, which publishes its own SPF on the root domain, while you're already sending through Google Workspace.

How you spot it: a scan reports "multiple SPF records", or your reports show SPF in permerror while the line looks correct. Some recipients accept you, others don't, with no obvious pattern.

The fix: one line, all the include: values inside it. If you're over 10 lookups, remove the services you no longer use — that's almost always where the excess is.

3. Turning on Email Routing while keeping another mail provider

Email Routing (now found under Compute > Email Service) forwards incoming mail to another address. Turning it on makes Cloudflare publish its own MX records and SPF, which conflict with your mailbox provider's. The records it publishes are also locked ("Locked" status) and can't be edited from the DNS Records page until you unlock them.

How you spot it: your email used to arrive in Google Workspace or Microsoft 365, and since yesterday it doesn't — or it arrives twice, forwarded. Your MX records show route1.mx.cloudflare.net where you expected your provider's.

The fix: pick one. Email Routing is for forwarding mail on a domain you don't host mailboxes for. If you have real mailboxes at a provider, turn it off, or unlock the records and restore your provider's MX (Compute > Email Service > Email Routing > your domain > Settings > the DNS records section > Unlock).

How long before it takes effect

• At Cloudflare: the official wording is careful — changes "can take up to 24 hours to propagate globally, but usually complete within 5-15 minutes". Cloudflare even adds: "It may take longer than 5 minutes for you to actually experience record changes." Fast, but not instant.
• But the old value can stay cached for as long as the TTL you had set before the change. If your previous record had a one-day TTL, some resolvers will take a day to see the change. That's not a contradiction, that's caching.
• For your mail service's "verify" button: wait 15 minutes before clicking, and try again later if it fails.
• For DMARC reports: the first ones arrive 24 to 72 hours after you publish, then roughly once a day.

One note on TTL: proxied records are forced to Auto (300 seconds) and can't be changed. DNS-only records accept anything from 60 seconds to 1 day.

Next steps

• Set up HubSpot email sending domain on Cloudflare
• How to set up SPF, DKIM and DMARC on GoDaddy
• How to set up SPF, DKIM and DMARC on Namecheap
• How to move your DMARC policy to p=reject safely
• My emails go to spam even though SPF, DKIM and DMARC pass