What does "DMARC policy not enabled" mean?

That your domain publishes a valid DMARC record whose policy is p=none. The record is found and parsed correctly; it simply asks receivers to report on failing mail rather than act on it. Scanners report this as a warning because nothing is being enforced, not because anything is misconfigured.

Is p=none a valid DMARC policy?

Yes. p=none is one of the three policies defined by the standard, alongside quarantine and reject, and it is the documented starting point. It turns on aggregate reporting so you can find every system sending as your domain before any of that mail is at risk of being blocked.

Does p=none satisfy the Gmail and Yahoo bulk sender requirements?

Yes. The requirements in force since February 2024 ask bulk senders to publish a DMARC record; they do not require enforcement. A record of v=DMARC1; p=none; rua=mailto:… meets that bar. What they do require separately is that your mail authenticates with SPF or DKIM, which is a different check from your DMARC policy.

How long should I stay on p=none?

Long enough to account for every legitimate sender in your aggregate reports, which is typically two to eight weeks depending on how many tools send as your domain. The exit condition is a steady 98–100% of your legitimate volume passing aligned for a couple of weeks, not a length of time.

Can I move from p=none straight to p=reject?

You can, and it is how domains break their own invoicing and support mail. Nothing at p=none tells receivers to drop messages, so a misaligned sender you have not noticed costs you nothing today and starts bouncing the moment you enforce. Move to quarantine first and read the reports.

Can I use pct= to roll out DMARC gradually?

No longer. RFC 9989 removed the pct tag because receivers applied it inconsistently, and an old record carrying pct= now has it ignored as an unknown tag. The ramp is your sender inventory rather than a percentage: fix sources until your legitimate volume passes aligned, then change policy in one step.

DMARC policy not enabled

A scanner has graded your domain and returned this warning, probably in amber or red. It reads like a misconfiguration and it is not one. Your DMARC record exists, it parses, and receivers are honouring it exactly as written — it says p=none, which asks them to report on mail that fails rather than act on it. "Not enabled" means not enforcing. It does not mean not installed.

Confirm what you actually publish before doing anything: the free DMARC record checker shows the record receivers see, the policy in force, and whether your reporting addresses are valid.

What the warning is measuring

Every scanner that grades email security — MXToolbox, mail-tester, the security questionnaire a customer sent you, the dashboard your MSP resells — checks the p= tag and scores it. Three values are possible, and only two of them change what a receiver does:

Policy	What the receiver does with failing mail	How scanners grade it
`p=none`	Delivers it, and sends you a report	Warning
`p=quarantine`	Sends it to spam	Pass
`p=reject`	Refuses it at the SMTP conversation	Pass

So a record like this one is complete, correct, and still flagged:

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

The distinction matters because the two situations have nothing in common. A domain with no DMARC record at all is publishing no policy and receiving no data. A domain at p=none is already collecting the evidence it needs to enforce safely. The warning tells you which stage you are at, not that you did something wrong.

What it never means: that your mail is failing authentication, that you are on a blocklist, or that spoofed mail is currently being delivered because of this setting. Those are separate questions, and p=none is the state in which you can answer them without risk.

Why p=none is the right place to start

Publishing DMARC is the only moment in email administration where you get to see the truth before you act on it. Nearly every domain that turns on reporting discovers senders nobody remembers authorising: an invoicing platform, a recruiting tool, a status-page service, a former employee's newsletter. Some of them are yours and none of them align.

At p=none that discovery costs nothing. Every one of those messages still arrives, and each one shows up in your aggregate reports with its source IP and its authentication result. At p=reject the same discovery arrives as your finance team asking why customers stopped receiving invoices.

This is why the standard defines p=none as a monitoring mode rather than treating it as a failure state. The scanner is right that it protects nobody. It is wrong to imply you should have skipped it.

When the warning actually needs action

Three situations turn it from informational into a real deadline:

A customer or insurer is asking. Security questionnaires and cyber-insurance renewals increasingly ask for enforcement specifically, and "we publish DMARC" does not answer a question about p=quarantine or better. This is the most common reason the warning suddenly matters to someone.
Your domain is being spoofed right now. If your reports show sustained volume from sources that are not you, p=none is letting it through. Enforcement is what stops it, and the urgency is real rather than procedural.
You have been on it for a year. Monitoring mode is a stage, not a destination. A domain that has collected reports for twelve months and never acted on them has all the cost of DMARC and none of the protection.

And one situation where it is not urgent, despite what you may have read: the Gmail and Yahoo bulk sender requirements in force since February 2024 ask you to publish a DMARC record, not to enforce one. p=none meets that bar. What those requirements do demand separately is that your mail authenticates with SPF or DKIM in the first place — a different check, and the one behind 550 5.7.26 bounces.

What has to be true before you enforce

One condition, and it is about your senders rather than your record: every legitimate source of mail for your domain passes SPF or DKIM aligned to it.

Alignment is the part that catches people, because a sender can authenticate perfectly well for its own domain and still fail DMARC for yours. Your aggregate reports are what tell you the difference — each source appears with its SPF and DKIM results and whether either lined up with the domain in your From header. If a source shows green checks but DMARC still fails, that is alignment rather than authentication, and it is fixed at the sending platform rather than in DNS.

Work down the list until the reports are boring. Expect two to eight weeks depending on how many tools send as you, and expect the last ten percent to be slower than the first ninety.

Moving off p=none, in order

Account for every sender in your reports. Anything you cannot identify is either something to fix or something to investigate — not something to enforce over.
Go to p=quarantine. The bar is a steady 98–100% of your legitimate volume passing aligned for a couple of weeks. Failing mail now goes to spam, which is recoverable: a missed message is in a folder rather than refused.
Watch for a few weeks. Forwarded mail produces a small, permanent tail of failures that is expected and not worth chasing — that is what ARC exists to address.
Go to p=reject. Your domain is now closed to spoofing at every mainstream provider.
Set a subdomain policy. sp=reject covers subdomains you do send from; np=reject, added in the 2026 revision, covers ones that do not exist and are therefore pure spoofing surface. Both are worth setting explicitly rather than inheriting.

There is no partial setting between these steps. pct= used to offer one and RFC 9989 removed it, because receivers applied it inconsistently for any value other than 0 or 100. If your record still carries pct=, it is being ignored as an unknown tag — delete it. The ramp is your sender inventory, not a percentage.

The full tag reference, and what each policy does to a message in practice, is on DMARC policies: none, quarantine, reject.

After you change it

Re-run the DMARC checker and confirm the policy receivers see is the one you published — a record edited at the wrong host, or cached at an old TTL, is a common reason a change appears not to have taken. Then keep reading the reports. Policy is not a setting you finish: new tools get adopted, DKIM keys expire, someone edits a record for an unrelated reason, and DNS drift quietly undoes work that was correct last quarter. The domains that get burned after enforcing are the ones that stopped looking.

Free checks: DMARC checker SPF checker DKIM checker Report analyzer