"DMARC policy not enabled": what the warning means and how to clear it

"DMARC Quarantine/Reject policy not enabled." If a domain checker, a security scanner or a deliverability audit just handed you that line, the first thing to know is what it is not saying. It is not saying your domain lacks a DMARC record. It is saying your record exists and its policy is p=none — the monitoring setting — so receivers check your mail against DMARC and then take no action on failures. The alarm system is installed and wired. It just isn't set to do anything.

Whether that's a problem depends on where you are in a process this warning is really a progress marker for. Here's how to read it, and how to move to a policy that actually enforces.

What the warning is literally detecting

A DMARC record is a TXT entry at _dmarc.yourdomain.com, and its p= tag tells receiving servers what to do with mail that claims to be from your domain but fails authentication checks:

• p=none — deliver normally, just report it
• p=quarantine — treat it with suspicion, typically spam-foldering
• p=reject — refuse it outright

Tools that emit "policy not enabled" are flagging the first value. Run your domain through the DMARC checker and you'll see the parsed record; if it reads p=none, that's the whole finding. Anyone on the internet can send mail with your domain in the From address, fail your authentication, and still be delivered — because your published policy asks receivers to allow exactly that.

The tag-by-tag anatomy of the record, including sp= for subdomains and the t=y testing flag that replaced the old pct= rollout dial, is covered in our guide to what a DMARC policy is.

Why p=none exists at all

If none enforces nothing, why is it a legal value? Because DMARC was designed to be deployed safely on domains with years of accumulated, undocumented mail flows — and turning on enforcement blind is how you block your own invoices.

p=none switches on the reporting machinery. With a rua address in your record, receivers send you daily aggregate reports listing every source that sent mail as your domain and whether it passed SPF and DKIM with alignment. That visibility is the entire point of the monitoring phase: it's how you find the CRM nobody remembered signs its mail with the wrong domain, before a reject policy starts bouncing it. Reading those XML reports is its own skill — we cover it in DMARC reports explained.

So the honest reading of the warning: p=none is the correct policy for a domain in its first weeks of DMARC deployment, and a finding worth fixing on a domain that has been parked at none for years. Surveys of DMARC adoption consistently show a large share of published records sitting permanently at p=none — monitoring forever, enforcing never. That's the situation the warning exists to poke at.

Does p=none hurt your deliverability?

Two separate questions hide in there.

Compliance: Google's bulk sender requirements ask senders of 5,000+ daily messages to Gmail for a published DMARC policy — and per Google's own documentation, p=none satisfies the requirement. Yahoo's rules are equivalent. You will not fail the Gmail sender requirements on policy strength alone, and a checker warning is not a provider penalty.

Protection: here none genuinely does less. An enforcing policy means spoofed mail claiming your domain gets junked or refused instead of delivered — which protects your recipients from phishing and, over time, protects your domain reputation from being shaped by mail you never sent. Enforcement is also a prerequisite for BIMI, if displaying your logo in supporting inboxes matters to you.

So the warning marks a real gap, but the gap is security posture first and deliverability second. Treat it as a project, not an emergency.

The fix: a staged move to enforcement

Flipping p=none to p=reject in one edit is the tempting fix and the wrong one. The safe path is the same one we lay out end-to-end in how to set up DMARC:

1. Confirm reporting is on. Your record needs a rua tag with a working mailbox. No reports, no visibility, no safe way forward.
2. Inventory your senders. From a few weeks of aggregate reports, list every legitimate source — marketing platform, transactional service, helpdesk, billing system.
3. Fix alignment source by source. Each sender must pass SPF or DKIM with a domain that aligns with your From domain. In practice that usually means turning on custom-domain DKIM signing in each platform. DKIM alignment is the version that survives forwarding; make it your primary.
4. Step to p=quarantine, optionally rehearsed first in testing mode: under RFC 9989, the May 2026 DMARC standard, p=quarantine; t=y asks receivers to apply the next level down. Receivers still on the older RFC 7489 rules read a percentage instead (pct=25 applies the policy to a quarter of failing mail), so a transition-era record can carry both. Watch the reports for legitimate sources getting caught.
5. Finish at p=reject once reports show your real mail passing cleanly and failures reduced to traffic you don't recognize as yours.

The DMARC generator builds each of these record variants correctly, and the DMARC checker verifies what's actually published after your DNS edit propagates.

Two details trip people at this stage. Subdomains inherit your organizational policy unless you set sp= separately — so a p=reject on the root also governs mail.yourdomain.com, and any subdomain sender you forgot becomes a casualty; the reports will show it if you look. And after you publish the change, scanners may keep showing the old warning for a while: DNS caching honors your record's TTL, so re-check after it expires before assuming the edit failed.

How long should the whole ladder take? For a domain with a handful of sending services, a few weeks at none and a few more at quarantine is typical; sprawling organizations take months. The failure mode to avoid isn't slowness — it's parking at a rung and never climbing again.

If the warning surprised you

A special case worth naming: sometimes this warning is the first time anyone in the organization learns the domain has a DMARC record at all. A predecessor published p=none years ago, reports go to a dead mailbox, and nothing was ever done. That domain is running step zero of a five-step process with the clock stopped. Re-point rua at a live address, let fresh reports accumulate, and run the ladder above — the record's age doesn't advance it.

Related guides

• DMARC checker — parse the record you're actually publishing right now
• DMARC generator — build the none, quarantine and reject variants without syntax errors
• How to set up DMARC — the full walkthrough from first record to enforcement
• DMARC reports — reading the aggregate XML that makes enforcement safe
• What a DMARC policy is — p=, sp=, np=, t= and what each value commits you to
• Why DMARC fails — diagnosing failures the reports surface

About this guide

Written by InboxRatio Editorial. Provider requirements cited here are taken from Google's and Yahoo's published sender documentation, and policy recommendations follow the staged deployment model DMARC's own specification anticipates (RFC 9989, which replaced RFC 7489 in May 2026). No vendor sponsorship influences this guide.

Methodology

InboxRatio's platform tests send from domains with enforcing DMARC policies, because authentication posture is part of the controlled setup our placement comparisons depend on. The protocol is documented in how we test; source rules are in sources.

Last updated

10 September 2026. Provider requirement details reviewed quarterly against current Google and Yahoo documentation.

Frequently asked questions

Is "DMARC policy not enabled" the same as having no DMARC? No. No record at all means receivers have nothing to check against — and does fail Google's bulk-sender requirement. "Not enabled" means a record exists with p=none: checks run, reports flow, but failing mail is still delivered.

Is p=none bad for deliverability? Not directly — providers accept p=none as a published policy, and your legitimate mail is evaluated on its own authentication either way. The cost is protective: spoofed mail using your domain still gets delivered, and whatever it does reflects on your name.

Can I just switch straight to p=reject? You can, and domains that send no legitimate mail (parked domains) should. For a sending domain it's a gamble: any service signing or routing mail out of alignment starts failing hard. Weeks of monitoring at none, then quarantine, is the boring path that never bounces your own invoices.

How do I check what my current DMARC policy is? Look up the TXT record at _dmarc.yourdomain.com, or run the domain through the DMARC checker, which parses the policy and flags common syntax mistakes at the same time.

What does pct= do during rollout? Under the original RFC 7489, pct=25 asked receivers to apply your stated policy to roughly a quarter of failing messages and treat the rest one level softer. RFC 9989 removed the tag in May 2026 and replaced it with t=y, which applies the next lower policy to all failing mail while you test. Either one is a dimmer for the move to quarantine or reject: useful mid-rollout, pointless as a permanent state.

Will enforcing DMARC stop all spoofing of my domain? It stops direct-domain spoofing at receivers that honor DMARC — major providers do. It does not stop lookalike domains or display- name tricks, which don't involve your domain at all. Enforcement closes the door you own; it can't close doors that merely resemble it.

The warning, decoded: your monitoring phase has no end date on it. Give it one — pull up your record in the DMARC checker, check whether reports are flowing somewhere alive, and schedule the step to quarantine.