DMARC policy not enabled: what it means
A checker has flagged your domain with DMARC policy not enabled, and the wording reads like something is broken. In most cases nothing is. It is a status, not a fault: your domain is being monitored rather than protected, and the way out is a rollout, not a repair.
DMARC policy not enabled means a DMARC record exists for your domain, but its p= tag is either none or missing — so nothing failing DMARC is blocked anywhere.
It is a warning, not an error. p=none is the correct first step; it only becomes a problem if you stay there.
Which of the three states are you actually in?
Three quite different situations get reported with the same shorthand, and each has a different first move. Match the line your checker printed against the second column.
| State | What a checker prints | What it means | First fix |
|---|---|---|---|
Nothing published at _dmarc | No DMARC record found at _dmarc.<domain> | You have no DMARC record at all. Receivers get no instructions from you and send you no reports. | Publish a record with p=none and a rua address. |
A record exists, but p= is missing or invalid | Missing or invalid policy tag — DMARC requires a valid p. Without a valid p, receivers fall back to monitoring at best — and ignore the record entirely if there is no usable rua. | The record is found, but the one mandatory instruction is absent or holds an invalid DMARC policy value. | Correct p= to none, quarantine or reject. |
A record exists with p=none | Policy not enabled. Monitoring only — nothing is blocked. Move toward quarantine, then reject. | Everything is working as published. Failing mail is counted and reported, and still delivered. | Nothing urgent. Start the climb described below. |
A missing DMARC policy tag is the only one of the three that is genuinely a mistake — a typo, a truncated paste, or a value like p=monitor that the standard does not define. The other two are simply early positions on a journey, and the third row is where the large majority of domains carrying this warning actually sit.
Is p=none dangerous? Only if you stay there
At p=none a forged message that fails DMARC is delivered exactly as it would have been before you published anything. The record blocks nothing today. What it buys you is visibility — and only if it also carries a rua address, because that is what makes reports flow.
The real risk is therefore not technical but psychological: a record in DNS and a tick on a dashboard feel like protection. They are not. Until you reach p=quarantine or p=reject, anyone can still put your domain in the From header and reach an inbox. If your reports already show sources failing DMARC, that is what is happening — and at p=none the verdict on those messages reads fail while delivery goes ahead anyway, a distinction covered in DMARC pass and fail, explained.
So p=none is right for a few weeks and wrong for a few years. It is the monitoring period that makes enforcement safe; once your reports are clean and you understand every sender, staying put stops being caution and becomes an unmade decision.
How to fix it without losing legitimate mail
Nothing below is urgent, and nothing below is optional either. Work through it in order — jumping straight to step four is how domains silently lose real mail from senders nobody remembered.
- Make sure reports are switched on. A policy without reporting tells you nothing about the effect of tightening it. Add a
ruaaddress to the record; RUA vs RUF: DMARC report types explains what arrives and why the aggregate stream is the one that matters. If you would rather not parse compressed XML by hand, point the reports at DMARCmetric instead of a mailbox. - Spend two to four weeks sorting your senders into "mine" and "not mine". Every service that sends as your domain — the newsletter platform, the invoicing tool, the helpdesk — has to pass SPF or DKIM aligned with your From domain, and out of the box most of them do not. Third-party senders and DMARC covers the two fixes that work for every provider.
- Move to
p=quarantineonce the reports run clean. Failing mail starts going to spam rather than the inbox, which is recoverable if you have missed something. The Policy advisor on your domain's dashboard marks where you are on the ramp and names the next step; the full playbook, with thepct=staging option, walks the whole climb rung by rung. - Finish at
p=reject. This is the rung where the warning disappears and forged mail is refused at the door. Give quarantine a few clean weeks first, then publish the change and confirm it is live with the free DMARC checker — a policy you meant to publish and a policy that resolves in public DNS are not always the same thing.
Leave the rua address in place after you reach reject. Enforcement produces no feedback of its own: if a provider rotates its DKIM keys or an SPF include: stops resolving, the affected mail is refused, and the aggregate reports are where that shows up — rather than in a complaint from whoever was waiting for the message.
Why different checkers word it differently
"DMARC policy not enabled" is not a standard error string. Nothing in the DMARC specification produces that text; it is a vendor label, popularised by one widely used tool and copied by many others. That is why the same domain can come back clean from one checker and flagged by another — the tools are not disagreeing about your record, they are grading it against different thresholds.
| Wording you may have seen | Where it comes from | What it is actually telling you |
|---|---|---|
| DMARC Policy Not Enabled | MxToolbox, and the many tools that mirror its labels | A record exists and p=none. Our checker prints "Policy not enabled." for the same state. |
| DMARC Quarantine Policy Not Enabled | The same family of tools, which grade each rung of the ladder separately | You are below p=quarantine — in practice, almost always because p=none. |
| DMARC Reject Policy Not Enabled | The same family of tools | You are below p=reject. It also appears at p=quarantine, where nothing is wrong and you are one step from done. |
| DMARC record not found | Generic checkers, and dig returning no output | Nothing is published at _dmarc. Our checker prints "No DMARC record found at _dmarc.<domain>". |
| Policy tag missing or invalid | Parser-based checkers | The record was found but p= is absent or unrecognised. Our checker opens that line with "Missing or invalid policy tag". |
Two consequences are worth holding on to. First, a warning that names quarantine or reject is a progress marker, not a defect report — it will keep appearing until you finish the climb, by design. Second, "record not found" and "policy not enabled" are genuinely different problems: one means there is nothing to read, the other means what is there says do nothing.
Frequently asked
Does it mean someone is spoofing my domain?
No. The message describes your DNS record, not your traffic. It is generated by reading _dmarc.yourdomain.com and nothing else, so it says the same thing for a quiet internal domain and for one under active attack. The only way to tell the two apart is aggregate report data — which is exactly what p=none plus a rua address is for. If reports are configured but nothing has arrived, work through the delivery checks before assuming your domain is uninteresting to attackers.
Will Gmail and Yahoo reject my mail?
No, but the record on its own does less for you than it looks. The bulk-sender requirement is a published DMARC record, and p=none satisfies it — rua is not required by either provider's rules. What both do also require is that your mail actually passes DMARC, with SPF or DKIM aligned to your visible From domain, and without a reporting address you have no way of knowing whether it does. So the record keeps you compliant on paper while leaving you blind to the requirement that is more likely to catch you out. The full checklist, including the 5,000-a-day threshold, is in Google and Yahoo DMARC requirements.
How long should I stay at p=none?
Long enough to see a full sending cycle, and no longer. Two to four weeks suits most domains: enough to capture weekly newsletters, month-end invoices and the quarterly mail nobody remembers until it fails. Larger organisations with many business units often need longer, simply because it takes longer to find every sender. The signal to move is evidential rather than calendar-based — every source in your reports identified, and every legitimate one passing and aligned. How to read a DMARC report shows where to look for that.
My root domain is fine, but a subdomain is flagged
Check for an sp= tag. Subdomains inherit your p= policy unless sp= overrides it, so p=reject; sp=none leaves every subdomain unprotected while the apex looks fully enforced — and a checker that falls back to the organisational domain will report the policy as not enabled for mail.example.com. The tag is easy to set during a rollout and then forget, because nothing about the apex record's own result changes when you do. See DMARC record tags explained for the tag and its default. The other common case is not a problem at all: if nothing is published at _dmarc.mail.example.com, the organisational domain's policy still applies, and a separate subdomain record is optional.