No. It is the only way to get aggregate reports, which are the entire basis for a safe rollout. It also publishes a reporting address that receivers use, and some filtering systems treat a valid DMARC record as a mild positive signal. What it does not do is stop anyone spoofing your domain.

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

Their published requirements ask bulk senders to have a DMARC record; a record at p=none meets that specific item. The alignment, PTR, one-click unsubscribe, and spam-rate requirements are separate and are not waived by any policy value. Check each provider's current sender guidelines, since thresholds and details have changed since the programs launched.

How long should I stay at p=none?

Long enough that a month of aggregate reports contains no source you cannot explain. Four to eight weeks is typical. Rushing past this is the single most common cause of a DMARC rollout that has to be reverted.

Can I skip straight to p=reject if I only use one mail provider?

It is lower risk than for most domains, but still publish p=none with rua for two to three weeks first. Reports routinely surface a monitoring system, a scan-to-email device, or a legacy web form that nobody remembered was sending as the domain.

My scanner says "not enabled" but my mail is authenticating fine. Do I need to act?

Not urgently. Authentication working and enforcement being on are different things. Use the time to read reports and fix alignment for every sender, then raise the policy on your own schedule rather than because a badge turned amber.

Does pct= affect whether a scanner calls the policy enabled?

Sometimes. A record with p=reject; pct=10 applies reject to a sample of failing mail and quarantine-or-nothing to the rest, and stricter scanners flag anything below pct=100 as partially enforced. BIMI validation in particular expects a full-strength policy.

"DMARC Policy Not Enabled" — What It Means

This is one of the most misread warnings in email diagnostics. It is not a syntax error, not a DNS failure, and not something you need to fix today. It means a scanner found a perfectly valid DMARC record whose policy tag is p=none, and is pointing out that none asks receivers to do nothing.

dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]"
#             ^^^^^^ this is what triggers the warning

A record that scans as "policy not enabled"

DMARC Checker

Policy, alignment, and why Gmail may reject you

What does "enabled" mean to a scanner?

Different tools draw the line in different places, which is why the same domain can pass one checker and fail another. There is no standard definition of "enabled" in RFC 7489 — the spec only defines the three policy values.

Tool category	Usually treats "enabled" as	Typical wording
Basic record checkers	Any valid `v=DMARC1` record	"DMARC found"
Deliverability scanners	`p=quarantine` or `p=reject`	"DMARC policy not enabled"
Security scorecards / vendor risk tools	`p=reject`, sometimes with `pct=100`	"DMARC not enforced"
BIMI validators	`p=quarantine` with `pct=100`, or `p=reject`	"Policy insufficient for BIMI"
Bulk-sender compliance checks	Presence of any record, including `p=none`	"DMARC present"

That last row matters. The bulk-sender requirements published by Google, Yahoo, and Microsoft ask senders above their volume thresholds to publish a DMARC record; a record at p=none satisfies that specific requirement. The rest of those programs — SPF and DKIM authentication with alignment to the From: domain, valid forward and reverse DNS on sending IPs, one-click unsubscribe on bulk marketing mail, and keeping spam complaint rates low — are separate obligations that p=reject does not substitute for. Check your provider’s current sender guidelines for the exact thresholds, which have changed over time.

If a compliance checklist demands "DMARC enabled", ask which policy value it needs. Many internal security questionnaires mean p=reject, while mailbox-provider requirements are satisfied by any published record.

Why is p=none the default advice, then?

Because p=none is the only policy where you can be wrong without consequences. DMARC does not evaluate SPF and DKIM in isolation — it requires alignment: the domain that passed SPF (from the Return-Path/envelope sender) or the domain in the DKIM d= tag must match the domain in the visible From: header.

Plenty of legitimate senders pass SPF and DKIM for *their own* domain while sending From: your domain. A transactional provider signing with d=sendgrid.net and bouncing to bounces.sendgrid.net produces a DMARC failure for From: [email protected] even though both mechanisms technically passed. At p=none that failure is a line in a report. At p=reject it is a bounced invoice.

A CRM or helpdesk sending "on behalf of" your domain without a custom signing domain configured.
A billing or ERP system relaying through a server that predates your SPF record.
Departmental mail from a marketing tool nobody told IT about.
Mailing lists that rewrite the body and break DKIM — see body hash did not verify.
Automated forwarding that breaks SPF, leaving DKIM as the only surviving mechanism.

The aggregate reports you get from rua= are how you find all of these. Every participating receiver sends a daily XML summary naming the source IPs, the SPF and DKIM results, the alignment outcome, and the message counts. That is the inventory you cannot build any other way.

When should I move off p=none?

Move when the reports stop surprising you — not on a calendar. Concretely, you are ready when all three of these are true:

You can name every source IP or provider appearing in your aggregate reports with meaningful volume.
Every legitimate source shows an aligned SPF pass, an aligned DKIM pass, or both — in the reports, not just in a test message you sent yourself.
The residual failing volume is either spoofing you are happy to have blocked, or forwarding you have accepted you cannot fix.

For most organizations that is four to eight weeks of monitoring. A domain with one mail provider and no third-party senders can be much faster. A domain that has been around for fifteen years and has acquisitions in its history can take a quarter. The full staged plan, including the pct= ramp, is in p=none vs quarantine vs reject.

DMARC Record Generator

Create a DMARC record with a safe rollout policy

How do I check whether my senders are aligned?

Aggregate reports are the authoritative source, but you can check a single message immediately. Send a message from each sending system to a mailbox you control, then read the Authentication-Results header:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=s1 header.b=Ab1cD2eF;
       spf=pass (google.com: domain of [email protected] designates
            198.51.100.7 as permitted sender) [email protected];
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Both mechanisms pass — for the vendor's domain, not yours. DMARC still fails.

This is the failure mode that catches people. header.from=example.com is the only domain DMARC cares about. smtp.mailfrom is on mail.esp-vendor.net, so the SPF pass is not aligned. The DKIM signature is d=esp-vendor.net (shown as [email protected]), so that pass is not aligned either. Two green checkmarks, one dmarc=fail. The fix is to configure a custom signing domain and a custom bounce domain at the vendor so at least one mechanism lands on example.com. Paste real headers into the email header analyzer to have this parsed for you.

A correctly configured sender looks like this instead — the DKIM d= is your domain, so DMARC passes on DKIM alignment even though SPF is still on the vendor's bounce domain:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=s1 header.b=Ab1cD2eF;
       spf=pass [email protected];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Aligned DKIM carries DMARC on its own

A dmarc=fail line while you are at p=none is harmless today and fatal at p=reject. Treat every one you see as a work item before you raise the policy.

What to fix before enforcing

Confirm SPF is a single record and under the 10-lookup limit with the SPF checker — a PermError makes SPF unusable for alignment. See SPF PermError.
Confirm DKIM signing is on for every sending system, and that each signs with d= on your domain, not the provider’s. The DKIM checker will discover the selector; how to find your DKIM selector covers the manual methods.
For Microsoft 365 tenants, DKIM signing is off by default until both selector CNAMEs are published — see Microsoft 365 DKIM setup.
Set a custom return-path / bounce domain at each ESP so SPF aligns too. Two aligned mechanisms survive forwarding better than one.
Run the full picture with the deliverability test, and check PTR on your sending IPs with reverse DNS.

One more thing worth knowing: p=none on the organizational domain leaves subdomains at none too. If you never send from subdomains, publishing sp=reject alongside p=none blocks a common spoofing pattern ([email protected]) while you are still monitoring the root domain. It is the one piece of enforcement that carries almost no risk.

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

Monitor the root domain, but reject spoofed subdomains immediately