How to Set Up SPF, DKIM and DMARC on Cloudflare DNS

First, understand what Cloudflare is doing here

Cloudflare is your DNS host. DNS is the system that answers questions about your domain, such as which server handles your mail. Cloudflare publishes the answers. It does not send your email.

That distinction matters because it determines where each piece comes from. SPF and DMARC are records you write yourself and paste into Cloudflare. DKIM is different. The DKIM key is generated by whoever actually sends your mail, which is usually Google Workspace, Microsoft 365, or a marketing platform. Cloudflare only publishes it.

There is one exception. Cloudflare now runs its own sending product called Email Service, which does generate DKIM keys. Almost nobody reading this is using it. If you send from Gmail or Outlook, your key comes from there, not from Cloudflare.

Where the records actually live

Log in to the Cloudflare dashboard. Select your account, then select the domain you want. In the left sidebar, open DNS, then Records. The page is titled DNS Records and the table on it is the full list of everything Cloudflare is publishing for your domain.

Select Add record. A row opens with a Type dropdown. Choose TXT. You now get three fields that matter: Name, Content, and TTL.

There is no proxy toggle on a TXT record. Cloudflare only shows the orange and grey cloud for A, AAAA and CNAME records, because those are the only types it can put behind its network. If you are looking for the cloud icon on your DMARC record and cannot find it, nothing is wrong. TXT records are always served directly.

The Name field trap

This is the single most common silent failure on Cloudflare, and it is worth slowing down for.

Cloudflare appends your domain to whatever you type in the Name field. So for a DMARC record you type only:

_dmarc

You do not type _dmarc.yourdomain.com. If you paste the full hostname from a guide or a vendor email, you can end up publishing a record at _dmarc.yourdomain.com.yourdomain.com. Nothing errors. The record saves. It looks fine in the table at a glance. But no mail server will ever find it, and a doubled record behaves exactly like having no record at all.

For a record on the domain itself, such as SPF, type an @ symbol in the Name field. Cloudflare converts @ to your root domain on save.

The fix is not to be careful. The fix is to read the record back. After you save, look at the Name column in the Records table. It shows the complete hostname Cloudflare published. Confirm it reads _dmarc.yourdomain.com and not something with your domain in it twice.

The exact records to add

Three records, all of Type TXT. Values below are examples. Yours will differ.

• SPF. The Name is @ and the Content is v=spf1 include:_spf.google.com ~all, with the include swapped for whatever your mail provider tells you. You may only have one SPF record on a domain. If one already exists in the table, edit it rather than adding a second. Two SPF records is a hard failure, not a warning.
• DKIM. The Name is the selector your provider gave you followed by ._domainkey, which for Google Workspace is usually google._domainkey. The Content is the long v=DKIM1; k=rsa; p=... string from your provider.
• DMARC. The Name is _dmarc and the Content is v=DMARC1; p=none; rua=mailto:reports@yourdomain.com, using an address you actually read. Start at p=none. That means monitor only and changes nothing about how your mail is delivered. It exists so you can collect data before you enforce anything.

TXT quoting and the validation error that is not your fault

Cloudflare handles quotes in a way that surprises people. If you paste TXT content with no double quotes at all, Cloudflare adds them for you on save. That is fine and expected.

The problem is partial quoting. If your pasted value has quotes around some parts but not others, which happens constantly when copying from a vendor's help page or a PDF, Cloudflare's field validation rejects it. You get an error on a record that is technically valid DNS.

The reliable approach is to strip every double quote out of the value before pasting, then let Cloudflare add its own. Paste into a plain text editor first if you need to see what is really in the string.

Long DKIM keys are the other case. A 2048-bit key exceeds the 255 character limit that a single DNS text string allows, so it has to be published as multiple quoted strings joined together. Cloudflare handles this, but a partially quoted paste of a long key is where most DKIM failures on Cloudflare start. Cloudflare caps a single record at 4,096 bytes, and all records sharing the same name and type at 8,192 characters combined.

CNAME flattening will break some DKIM setups

This one is specific to Cloudflare and catches experienced people.

Cloudflare has a feature called CNAME flattening. A CNAME record points one hostname at another. Flattening resolves that pointer and publishes the final IP address instead of the pointer itself. It exists to solve a real problem at the root of a domain.

Some mail providers give you DKIM as a CNAME rather than a TXT record. Flattening converts it, the lookup no longer returns what the provider expects, and DKIM fails validation for reasons that are invisible from the record list. If your provider handed you a CNAME for DKIM or for autodiscover, turn CNAME flattening off. The setting is under DNS, then Settings.

TTL and how long changes take

TTL means time to live. It tells other servers how long to cache your record before checking again.

Cloudflare's Auto setting is 300 seconds, which is five minutes. For an unproxied record you can set it manually between roughly 30 to 60 seconds at the low end, depending on your account tier, and one day at the high end.

Leave it on Auto. Five minutes is short enough that mistakes are cheap to fix, and email authentication records do not benefit from aggressive caching.

In practice, Cloudflare publishes changes at its edge almost immediately. Cloudflare's own documentation says changes usually complete in five to fifteen minutes for domains on Cloudflare DNS, with up to 24 hours as the outer bound. The delay you experience is other people's caches, not Cloudflare's.

Letting someone help without handing over your password

Cloudflare has proper delegated access, and it is one of the better implementations. You never need to share a login.

You must be a Super Administrator on the account to do this. Go to Manage Account, then Members. Select Invite. Enter the person's email address. Under Scope, you can restrict the invitation to a single domain rather than the whole account. Under Roles, choose the DNS role for account-wide DNS editing, or Domain DNS to limit it to DNS settings on specific domains. Select Continue to summary, review it, then select Invite.

Check the Roles list on your own account rather than assuming. Cloudflare exposes different sets of roles depending on the account, and if you only see Administrator and Super Administrator, that is what your plan gives you.

When the work is finished, remove the member from the same Members page. Access ends immediately. No password was ever exchanged, and nothing needs to be rotated afterwards.

We ask for this kind of scoped invitation, or we walk you through it on a call while you drive. We do not accept passwords, government identification, or card numbers under any circumstances.

How to verify it actually worked

Do not trust the green tick or the record showing up in the table. The table proves Cloudflare saved something. It does not prove the world can see the right thing.

Query it from outside. On macOS or Linux, open a terminal and run:

dig _dmarc.yourdomain.com TXT +short

On Windows, use nslookup -type=TXT _dmarc.yourdomain.com instead.

Read the output carefully. You are checking that the name is not doubled, that only one SPF record comes back, that the DKIM key is complete rather than truncated, and that the quoting looks sane. If dig returns nothing, the record is not live regardless of what the dashboard shows.

The real test comes after that. Send a message to an address on a different provider and inspect the received headers for SPF, DKIM and DMARC results. Records that look correct can still fail alignment, which is the requirement that the domain in your visible From address matches the domain that SPF or DKIM authenticated.

Cloudflare DMARC Management, which is free and useful

DMARC reports arrive as compressed XML attachments. They are close to unreadable by hand.

Cloudflare includes a free report reader on every plan. Go to Email, then DMARC Management, and select Enable DMARC Management. It requires that your domain is on Cloudflare DNS. It shows you every source sending mail as your domain and whether each one passes SPF, DKIM and DMARC.

One limitation worth knowing before you rely on it. DMARC Management only works on apex domains. That means yourdomain.com works and blog.yourdomain.com does not.

What Cloudflare cannot do

Cloudflare cannot send email on your behalf in any normal configuration, and that has consequences people discover late.

Cloudflare Email Routing is the free feature that forwards mail at your domain to a personal inbox. It is receive only. Cloudflare's documentation is explicit that it does not support sending or replying from your domain. When you reply to a forwarded message, the reply goes out from your destination address, so a customer emailing hello@yourdomain.com gets an answer from a gmail.com address.

This is the part that matters for brand verification. BIMI is the standard that puts your logo next to your messages in Gmail. It requires DMARC at enforcement and mail that is genuinely signed and aligned to your domain. Email Routing cannot produce that, because it never sends anything as you. Cloudflare will happily host the BIMI TXT record at default._bimi, since that is just DNS. It cannot give you the sending infrastructure the record depends on, and it does not issue the Verified Mark Certificate that Gmail requires for the checkmark. Those come from a small number of certificate authorities and require a registered trademark.

Two smaller notes. Enabling Email Routing puts Cloudflare in control of your MX records, which conflicts with an external mail provider. Turn it off if you use Google Workspace or Microsoft 365. And Cloudflare does not forward non-delivery reports, so a sender whose message fails will not be told.

You can do all of this yourself

Genuinely. Adding three TXT records in Cloudflare takes about fifteen minutes, and Cloudflare's interface is one of the clearest there is. If you got this far and it makes sense, go do it. Nobody needs to be paid for that.

Where it stops being simple is afterwards. Reading DMARC reports and identifying every legitimate sender takes weeks of watching. Moving from p=none to enforcement without silently blocking your own invoices or your booking system requires knowing what you are looking at. Alignment failures on a sender that appears to pass are their own category of problem.

Working with us

We handle email authentication as part of business verification work at Verified Everywhere. If you would rather not spend a month reading XML, we will take a scoped Cloudflare invitation, do the setup, watch the reports, and move you to enforcement when the data says it is safe. We never take passwords, identification documents, or payment details, and we will not tell you in advance what any provider will decide. If your setup is already fine, we will say so.