How to Set Up DMARC in Cloudflare

First, get SPF and DKIM right

DMARC isn't a standalone thing you switch on. It sits on top of SPF and DKIM and decides what happens when they fail, so if those two aren't in order, DMARC either does nothing or does damage. Before touching the DMARC record, confirm both are working.

SPF is a TXT record listing which servers may send mail for your domain (for example v=spf1 include:_spf.google.com ~all). DKIM adds a cryptographic signature to every message, verified against a public key you publish in DNS. DMARC then checks alignment: it passes when SPF or DKIM not only succeeds but does so for a domain that matches the From address the recipient sees. Get the relationship straight before you enforce anything, and if you need a refresher our SPF, DKIM and DMARC guide walks through each one.

Add the DMARC record in Cloudflare

In the Cloudflare dashboard, select your domain, open DNS, then Records, and click Add record. DMARC is a TXT record with a specific, fixed name.

Set Type to TXT. Set Name to _dmarc (Cloudflare automatically appends your domain, giving _dmarc.example.com; do not type the full domain yourself or you'll create _dmarc.example.com.example.com). Set Content to your starting policy, and leave TTL on Auto. A safe first record looks like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1. Save it. That's the entire DNS step.

Cloudflare also ships a guided DMARC Management tool under Email that can create this record for you and even receive the reports on your behalf, useful if you don't want to stand up your own reporting mailbox. Either path produces the same underlying TXT record.

Understand each tag you just published

The record is compact but every tag earns its place. v=DMARC1 declares the version and must come first. p=none is the policy: none means monitor only, take no action, just report. rua=mailto:... is where aggregate XML reports are sent daily by receiving providers, and it's the single most valuable part of the whole setup. fo=1 asks for failure samples when any authentication mechanism fails.

You'll also see optional tags. sp= sets a separate policy for subdomains. pct= applies the policy to only a percentage of mail, handy for a gradual rollout. adkim= and aspf= control whether alignment is strict or relaxed; relaxed (the default) is almost always what you want. Start minimal. You can layer these in once reports tell you what your mail actually looks like.

• v=DMARC1, version, required, must be first
• p=none, monitor only; escalate to quarantine, then reject
• rua=mailto:, daily aggregate reports (the whole point of p=none)
• sp=, separate policy for subdomains
• pct=, apply policy to a percentage of mail during rollout

Read the reports before you enforce

Here's the step everyone wants to skip and shouldn't. With p=none live, receiving servers start mailing you aggregate reports: XML files summarizing who sent mail using your domain, from which IPs, and whether SPF and DKIM aligned. Raw XML is unpleasant to read by hand, so either feed it to a DMARC report parser or let a monitoring service digest it for you.

What you're hunting for is legitimate mail that fails alignment. Your marketing platform, your invoicing tool, your helpdesk, your CRM, any of these might send on your behalf without proper SPF or DKIM. Every one of those needs fixing before you enforce, or enforcement will bin real mail. Give it two to four weeks so weekly and monthly senders show up in the data.

Move to quarantine, then reject

Once reports show your legitimate sources all aligning cleanly, tighten the policy by editing the same TXT record in Cloudflare. Go to p=quarantine first, which sends failing mail to spam rather than the inbox. Optionally ramp with pct=25, then 50, then 100, watching reports at each step. When quarantine has run clean for a couple of weeks, move to p=reject, the end goal, where forged mail is refused outright at the server.

Reject is what actually stops criminals from spoofing your domain in phishing attacks, so it's worth reaching, but only after the data says it's safe. Rushing from none to reject in one afternoon is the single most common way teams break their own email. The full escalation path is covered in our DMARC p=reject rollout guide.

Cloudflare-specific gotchas

A few things trip people up specifically in Cloudflare. Don't type the full domain in the Name field; _dmarc alone is correct. Make sure no old DMARC record already exists (a duplicate _dmarc TXT is invalid and receivers may ignore both). If you use Cloudflare Email Routing, its own outbound-forwarding behavior can affect SPF alignment for forwarded mail, so watch reports for forwarding IPs. And remember the DMARC record governs the domain in the From header, so a subdomain that sends mail may need its own _dmarc record or coverage via the sp= tag.

None of these are hard, but each produces a confusing report or a silent failure if missed. When the aggregate data is clean across every legitimate sender, your setup is done and your domain is protected.