Cloudflare hosts your DNS, so all three email authentication records - SPF, DKIM, and DMARC - are plain TXT records you add under the DNS tab. The whole job is three records, and the only real traps are the orange-cloud proxy toggle (it must be off for these), the way Cloudflare auto-appends your domain to the name field, and knowing which values your email provider actually gives you. This guide gives you the exact clicks and paste-ready examples for each record.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The short version: SPF lists who can send for your domain, DKIM cryptographically signs your mail, and DMARC tells receivers what to do when a message fails both. You need all three to pass Gmail and Yahoo sender requirements and to stop spoofing. Cloudflare makes this fast once you know where each value comes from.
Before you start: gather your provider values
You cannot write these records from memory. Two of the three depend entirely on which service sends your mail (Google Workspace, Microsoft 365, an ESP like Mailchimp or SendGrid, or your own server).
- SPF: your provider publishes an
include:mechanism, for exampleinclude:_spf.google.comfor Google Workspace orinclude:spf.protection.outlook.comfor Microsoft 365. - DKIM: your provider generates a public key and tells you the exact host name (the selector) and value. This is the one part you must copy from the provider console. Do not guess selectors.
- DMARC: you write this one yourself. It does not depend on the provider.
If you are not sure Cloudflare is even your DNS host, check where your nameservers point first. Our guide on how to find your DNS host walks through that. Once your domain shows "Active" in Cloudflare with Cloudflare nameservers, you are in the right place.
The two traps that break Cloudflare setups
Before the steps, learn the two mistakes that cause most failed Cloudflare records. Both are specific to how the Cloudflare dashboard behaves.
Trap 1: TXT records must be gray-cloud "DNS only"
The orange cloud icon means Cloudflare proxies traffic through its network. That is correct for A and CNAME records pointing at your website, but it is meaningless for TXT records - and if you ever add DKIM as a CNAME (some providers hand you a CNAME instead of a TXT), that CNAME must be gray cloud, "DNS only". A proxied (orange) DKIM CNAME will not resolve to your provider's key and signing silently fails.
For the SPF, DKIM, and DMARC TXT records in this guide, Cloudflare does not even show a proxy toggle on TXT type, so you are safe. The trap bites people who publish DKIM via CNAME. Remember: authentication records are always DNS only.
Trap 2: Cloudflare auto-appends your domain to the Name field
This is the single most common Cloudflare error. When you type a name, Cloudflare automatically adds your domain to the end. So for a DMARC record you enter _dmarc, not _dmarc.yourdomain.com. If you type the full hostname, Cloudflare creates _dmarc.yourdomain.com.yourdomain.com, which no receiver will ever query.
The rule for every record below:
- For the root domain (SPF), enter
@in the Name field. - For DMARC, enter
_dmarc. - For DKIM, enter only the selector part your provider gave you, for example
google._domainkey, notgoogle._domainkey.yourdomain.com.
After you save, Cloudflare shows the full name in the record list so you can confirm it expanded correctly.
Step 1: Add the SPF record
SPF is a single TXT record on your root domain. In the Cloudflare dashboard, pick your domain, open DNS > Records, and click Add record.
- Type: TXT
- Name:
@ - Content: your SPF string
A Google Workspace example looks like this:
v=spf1 include:_spf.google.com ~all
A domain that sends through Microsoft 365 and one ESP:
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all
Three rules that matter more than the provider name:
- One SPF record per domain. If you already have a
v=spf1TXT record, edit it and add the newinclude:. Never publish two separate SPF records - that is a permanent error. - End with
~all(softfail) or-all(hardfail), never+all. A trailing+allauthorizes the entire internet to send as you. See why in why +all is dangerous in an SPF record. - Stay under 10 DNS lookups. Each
include:counts. Too many nested includes triggers PermError and SPF stops evaluating. If you sit near the limit, read fix SPF too many DNS lookups.
Click Save. SPF is done.
Step 2: Add the DKIM record
DKIM is where you must use the exact values from your provider, because the record contains a public key that is paired with a private key your provider holds. Copy, do not type.
Most providers give you either a TXT record or a CNAME.
If your provider gives a TXT record (common with Google Workspace and many ESPs):
- Type: TXT
- Name: the selector, for example
selector1._domainkeyors1._domainkey - Content: the long
v=DKIM1; k=rsa; p=...string exactly as provided
A DKIM value looks like this (yours will be much longer):
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
If your provider gives a CNAME (common with Microsoft 365, Amazon SES, and others):
- Type: CNAME
- Name: the selector, for example
selector1._domainkey - Target: the host your provider specifies, for example
dkim.provider.com - Proxy status: gray cloud, DNS only (this is Trap 1 - a proxied CNAME breaks DKIM)
Whether TXT or CNAME is better and why some providers prefer one is covered in DKIM CNAME vs TXT record. If you send from more than one platform, each gets its own selector; see multiple DKIM selectors on one domain.
Save the record. DKIM keys can take time to propagate, so if verification in your provider console fails on the first try, wait and retry rather than editing the value.
Step 3: Add the DMARC record
DMARC is the record you write yourself, and it is the same shape no matter who sends your mail. Add another TXT record.
- Type: TXT
- Name:
_dmarc(Trap 2 - just_dmarc, Cloudflare adds the rest) - Content: your DMARC policy
Start in monitoring mode so you collect data without affecting delivery:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Tag by tag:
p=nonemeans "do not act, just report". It is the safe starting point. It does not protect you yet - it watches. The goal is to move top=quarantineand thenp=reject, which is the setting that actually blocks spoofed mail. Plan that path with how to move DMARC from none to reject.rua=mailto:...is where aggregate reports are sent. Use a real inbox or a mailbox you monitor. These XML reports show you every source sending as your domain.- Difference between the policies is explained in DMARC policy: none vs quarantine vs reject.
Save it. You now have all three records live.
The Email > DMARC Management wizard vs manual records
Cloudflare added an Email > DMARC Management panel that can publish a DMARC record for you and, in some plans, collect and summarize the aggregate reports Cloudflare's own address receives. It writes a normal _dmarc TXT record behind the scenes, so it does the same job as Step 3.
Two things to know. First, do not run both - if the wizard publishes a _dmarc record and you also add one manually, you end up with a conflict. Pick one method. Second, the wizard does not create your SPF or DKIM records; those are still Steps 1 and 2. Use the wizard if you want Cloudflare to handle DMARC reporting for you, or write the record by hand if you plan to send reports to your own address or a third-party analyzer.
Step 4: Confirm authentication actually passes
Publishing a record is not the same as passing. A typo in an SPF include, a DKIM key that did not propagate, or a _dmarc.yourdomain.com.yourdomain.com name mistake all look fine in the dashboard but fail at the receiver.
Run your domain through the free spfwise checker. It queries all three records live, confirms SPF resolves inside the 10-lookup limit, checks that DKIM is published for your selector, and reads your DMARC policy back to you with a grade. If something is off, it tells you which record and what to change. That is the difference between "I added the records" and "authentication passes".
For the wider picture of what each record does and how they work together, SPF, DKIM, and DMARC explained is the primer, and if your goal is specifically to meet inbox provider rules, see Google and Yahoo sender requirements.
Frequently asked questions
Do I enter the full hostname or just _dmarc in Cloudflare?
Just _dmarc. Cloudflare automatically appends your domain to whatever you type in the Name field. If you enter _dmarc.yourdomain.com you create _dmarc.yourdomain.com.yourdomain.com, which no mail receiver will ever query. The same rule applies to SPF (use @) and DKIM (use only the selector like google._domainkey).
Should the SPF and DKIM records be orange cloud or gray cloud?
Gray cloud, DNS only. The orange proxy applies to web traffic on A and CNAME records, not to authentication records. TXT records have no proxy toggle at all. The one place this bites you is a DKIM record published as a CNAME - if it is orange (proxied), it will not resolve to your provider's key and signing fails. Always keep DKIM CNAMEs on DNS only.
How long until Cloudflare records work?
Cloudflare applies DNS changes to its network within seconds, and because it uses a low default TTL, most changes are visible to receivers in a few minutes. DKIM verification in your provider console can occasionally lag longer, so if it fails on the first check, wait and retry instead of editing the key value.
Can I use Cloudflare's DMARC Management wizard instead of writing the record?
Yes. The Email > DMARC Management panel publishes a standard _dmarc TXT record and, on supported plans, summarizes aggregate reports for you. Just do not also add a manual _dmarc record, or the two will conflict. The wizard only handles DMARC - you still add SPF and DKIM yourself.