Add a DMARC Record on Cloudflare

Cloudflare’s DNS editor is straightforward once you know two things: the Name field takes a relative label and Cloudflare appends the zone, and TXT records are never proxied so there is no orange cloud to worry about. Nearly every failed DMARC publish on Cloudflare comes from getting the first of those wrong.

The four fields

That is the whole thing. Save, and the record is live at Cloudflare’s authoritative nameservers within seconds — Cloudflare does not batch zone updates.

Why is the Name field just "_dmarc"?

Cloudflare’s editor is zone-relative. Whatever you type in Name is treated as a label under the zone unless it is already fully qualified in a way Cloudflare recognises. The UI shows you the resulting full name once the record is saved, so check it in the record list: it should read _dmarc.example.com, not _dmarc.example.com.example.com.

The double-append mistake is silent — the record saves happily, and dig on the correct name returns nothing while the checker keeps saying the record is missing. If you see that, look for a stray record with the doubled name and delete it.

Does the proxy setting matter?

No. The orange-cloud proxy applies only to record types that carry an address a browser might connect to — A, AAAA, and CNAME. TXT records have no proxy toggle in the Cloudflare UI at all, so there is nothing to get wrong here.

This trips people up because the advice "make sure it is grey-clouded" is genuinely correct for the DKIM CNAMEs that often get published in the same session — those *do* have a proxy toggle, and proxying selector1._domainkey would break DKIM. For DMARC, and for any TXT record, the question does not arise. Related: Add a TXT record on Cloudflare covers the general TXT case, and Microsoft 365 DKIM setup covers the CNAME side.

What value should I publish first?

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

p=none asks receivers to take no action on failing mail and just send you reports. It satisfies every "DMARC record not found" check without any risk to delivery. Do not publish p=quarantine or p=reject on day one — see DMARC p=none vs quarantine vs reject for the staged rollout, and DMARC record not found for what each tag does.

If you never send mail from subdomains, add sp=reject alongside p=none. It blocks spoofing of anything.example.com immediately at no risk, while the root domain stays in monitoring:

v=DMARC1; p=none; sp=reject; rua=mailto:[email protected]

Verifying with dig

Do not trust the dashboard preview — query the record the way a receiving mail server would. Three checks, escalating in authority:

# 1. Your default resolver
dig +short TXT _dmarc.example.com

# 2. A public resolver, bypassing any local cache
dig @1.1.1.1 +short TXT _dmarc.example.com

# 3. Straight from Cloudflare's authoritative nameservers for the zone
dig @$(dig +short NS example.com | head -1) +short TXT _dmarc.example.com

A correct result is exactly one line beginning "v=DMARC1;. Here is a real one for comparison:

dig +short TXT _dmarc.cloudflare.com
"v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; pct=100; rua=mailto:..."

If step 3 returns the record and steps 1 and 2 do not, you are waiting out negative caching. A resolver that previously asked for _dmarc.example.com and got NXDOMAIN remembers that for the minimum TTL in the zone’s SOA record, typically 5 to 60 minutes — the TTL you set on the new record has no effect on that. Check the SOA with the SOA lookup if you want to know the exact wait.

To watch the record appear from resolvers around the world rather than just yours, use the DNS propagation checker, or compare four major public resolvers side by side with DNS compare. To see every TXT record on the domain in one view — SPF, verification tokens, and DMARC together — use the TXT record lookup.

Editing the record later

A DMARC rollout means changing this record several times — p=none to p=quarantine; pct=10, then 50, then 100, then p=reject. Always edit the existing record rather than adding a new one. Cloudflare will happily let you create a second TXT record at _dmarc, and the result is worse than having none at all: RFC 7489 tells receivers to discard the policy entirely when more than one v=DMARC1 record is present, so a domain that was at p=reject silently drops to unprotected.

Before every change, confirm you are looking at one record and only one:

dig +short TXT _dmarc.example.com | wc -l
1

If that returns 2 or more, delete the extras in the dashboard before doing anything else. Note that this counts *all* TXT records at _dmarc, so a stray verification token published at that name would also show up — anything at _dmarc that is not your policy record should be removed.

Cloudflare-specific gotchas

• The zone must actually be on Cloudflare. If your registrar still points at the old nameservers, editing the Cloudflare zone changes nothing that resolvers can see. Confirm with the NS lookup — the answer should be two *.ns.cloudflare.com names.
• Cloudflare Email Routing may add its own records, but it does not add DMARC. Enabling email routing does not publish a policy for you.
• Cloudflare’s DMARC Management feature can create the record and provide a reporting endpoint. If you use it, do not also hand-create a record — two v=DMARC1 TXT records at _dmarc invalidate the policy entirely.
• Do not wrap the content in quotes. Cloudflare adds the quoting at the zone level. Typing "v=DMARC1; p=none" yields a record whose value literally contains quote characters.
• Partial (CNAME) setup zones behave differently — records you add in Cloudflare are not authoritative unless the parent zone delegates that name. Verify with dig against the actual authoritative servers, per step 3 above.
• DNSSEC is fine. A signed Cloudflare zone serves TXT records normally; if resolution is failing generally, check the chain with the DNSSEC checker.