DMARC Policy Not Enabled Cloudflare

What does "DMARC policy not enabled" mean?

DMARC (Domain-based Message Authentication, Reporting, and Conformance, defined in RFC 7489) is published as a DNS TXT record at the special host _dmarc.yourdomain.com. The record's p= tag tells receiving mail servers what to do with messages that fail authentication (SPF/DKIM alignment).

A scanner reports "DMARC policy not enabled" in one of two situations:

• No DMARC record exists at _dmarc.yourdomain.com (or it's malformed and can't be parsed). Receivers fall back to treating your domain as having no policy at all.
• A record exists but p=none. This is monitoring mode. Per RFC 7489 §6.3, p=none requests "no specific action be taken" — the receiver collects data and sends you reports but still delivers spoofed mail to the inbox. DMARC is published, but enforcement is not enabled.

So the warning is not always "you have nothing." Often it specifically means you're stuck at p=none and have never advanced to an enforcing policy (quarantine or reject).

How do I fix "DMARC policy not enabled" in Cloudflare?

Add or update the _dmarc TXT record in your Cloudflare DNS. This only works if your domain's DNS is hosted on Cloudflare.

1. Log in to the Cloudflare dashboard and select the domain.
2. Go to DNS → Records.
3. Click Add record.
4. Type: TXT.
5. Name: _dmarc — enter it exactly, with no trailing dot and no domain suffix (Cloudflare appends the zone automatically).
6. Content: your policy string, e.g.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

7. TTL: leave as Auto.
8. Click Save. Cloudflare propagates the change across its anycast network within seconds.

If you only need a starting record, the steps above clear the "not enabled" warning. But to actually protect the domain from spoofing, you must move past p=none.

How do I move from p=none to enforcement?

p=none exists so you can deploy DMARC safely and read the aggregate (rua) reports without breaking legitimate mail. The recommended ramp:

1. Start at p=none with a rua reporting address and let reports accumulate.
2. Audit every sending source in those reports — your ESP, Courier, marketing tools, ticketing systems — and fix SPF and/or DKIM alignment for each so they pass DMARC.
3. Tighten to p=quarantine, optionally ramping with pct (e.g. pct=25) so only a fraction of failing mail is quarantined while you watch for collateral damage.
4. Set p=reject once all legitimate mail authenticates. This is the strongest enforcement state and the one security scanners expect to clear a "policy not enabled" warning.

An enforcing record looks like:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100

DMARC tag reference (RFC 7489)

• v=DMARC1 — version; must be the first tag.
• p= — policy: none (monitor, no action), quarantine (treat as suspicious / send to spam), or reject (block at SMTP time).
• rua= — mailto: address for aggregate reports. Recommended.
• ruf= — address for failure/forensic reports (sparsely supported).
• sp= — policy for subdomains; defaults to the p= value if omitted.
• pct= — percentage of failing mail the policy applies to (0–100, default 100).
• adkim / aspf — alignment mode, r (relaxed, default) or s (strict).

A note on Cloudflare DMARC Management

Cloudflare offers a built-in Email → DMARC Management feature that can create the _dmarc record and visualize aggregate reports by adding a Cloudflare rua address. Per Cloudflare's docs, DMARC Management is available to all Cloudflare customers with Cloudflare DNS, but the enable flow works only on apex domains (e.g. example.com, not blog.example.com). You can use it as an alternative to the manual TXT record above, but you still control the p= policy yourself.

Why this matters for sending mail

A domain stuck at p=none is functionally unprotected against spoofing. Note what bulk-sender programs actually require: Gmail and Yahoo (and Microsoft's 2026 rules) mandate only that high-volume senders publish a DMARC record with a minimum policy of p=none — alongside aligned SPF/DKIM, a one-click unsubscribe header, and low spam rates. Moving to p=quarantine or p=reject is strongly recommended for spoofing protection but is not itself the bulk-sender threshold. If you send transactional or notification mail (for example through Courier), publish DMARC and advance toward enforcement on your sending domain after confirming SPF and DKIM are aligned, so legitimate messages keep delivering while spoofed mail is rejected.