Is p=none good enough?

No, not as a destination. The p=none policy is valuable as a starting point because it generates aggregate reports that show you every source sending mail under your domain, but it provides zero protection against spoofing. At p=none, an attacker can forge your exact domain in the From header, fail every authentication check, and receiving servers will still deliver the message because you told them to. It satisfies the minimum bar that Google and Yahoo set for bulk senders, but minimum is not the same as secure. Treat p=none as a temporary observation phase — typically two to four weeks — while you confirm your legitimate senders pass. Then move to p=quarantine and ultimately p=reject, which are the policies that genuinely block impersonation.

How do I change my DMARC policy to quarantine or reject?

Edit the single TXT record at the _dmarc hostname for your domain and change the p= tag. To quarantine, set the value to v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com. To reject, change p=quarantine to p=reject. Keep the rua address so you keep receiving aggregate reports. For a gentle rollout, add a pct tag — for example pct=25 — so the policy applies to only a quarter of failing mail at first, then raise it toward 100 as the reports stay clean. Save the record, wait for DNS to propagate, then verify with dig +short TXT _dmarc.yourdomain.com. Make sure there is only one DMARC record published; multiple records cancel each other out and leave you with no valid policy.

Will enforcing DMARC block my real email?

It can, but only if you enforce before your legitimate senders are properly aligned — and that is entirely avoidable. Every service that sends mail using your domain, such as your CRM, invoicing system, marketing platform, or help desk, must pass SPF or DKIM alignment before you move to p=quarantine or p=reject. The safe path is to sit at p=none with an rua reporting address for a few weeks, read the aggregate reports to build a complete inventory of your sending sources, and fix any that are failing. Only once every real source passes cleanly should you raise the policy. Done in that order, enforcing DMARC blocks spoofers while leaving your genuine mail untouched.

Fix "DMARC Policy Not Enabled" — Enable Quarantine or Reject

A scanner result that reads DMARC policy not enabled is one of the most common findings on otherwise healthy domains. It does not mean your email is broken today.

It means your domain is missing the one piece of email authentication that actually does something: an enforced policy that tells receiving mail servers what to do with messages that fail your checks. Without it, anyone can keep impersonating your domain and your real mail can still be flagged as suspicious.

For the site owner (plain English)

This finding means your domain is missing the one setting that actually blocks people from forging your name in email. It is not urgent in the sense that nothing breaks today, but it is worth doing, because right now anyone can send email that looks like it came from you. The fix is a single small text record in your DNS, at a host called _dmarc. Start it in a harmless “watch only” mode (p=none) so you can see who sends mail as your domain, then, after a week or two, change one word to switch on protection — quarantine first, then reject. Log in to your DNS provider, add or edit that one record, and you are done. No developer needed.

What does "DMARC policy not enabled" mean?

DMARC (Domain-based Message Authentication, Reporting & Conformance), defined in RFC 7489, is a TXT record published at the special hostname _dmarc.yourdomain.com. It ties together your existing SPF and DKIM records and tells receivers two things: how to judge whether a message genuinely came from you, and what to do with messages that fail that judgement. That second part — the instruction — is the p= tag, the "policy".

The warning fires in one of two situations, and they look the same from the outside:

No DMARC record at all. There is no TXT record at _dmarc.yourdomain.com, so receivers have no policy to follow. They fall back to their own heuristics, which usually means impersonation attempts are not actively rejected.
A record exists, but the policy is p=none. This is the subtle one. You have a valid DMARC record, the syntax is correct, and a quick check might even say "DMARC found". But p=none is a monitoring-only policy. It asks receivers to send you reports about who is sending mail as your domain — and then to deliver everything anyway, including outright spoofs.

So "policy not enabled" is really shorthand for: you have no enforced policy. Either nothing is published, or what is published is set to observe rather than to protect. A scanner cannot read your intent; it can only see that mail failing authentication will not be quarantined or rejected, which is the part that matters for security.

Why does it matter?

At p=none, your domain offers essentially zero protection against being spoofed. An attacker can craft an email with your exact domain in the From: header, send it to your customers or staff, and even when it fails SPF and DKIM, receiving servers have been told to deliver it. That is exactly the gap phishing and business-email-compromise campaigns rely on.

There is also a deliverability dimension that has become hard to ignore. Since early 2024, both Google and Yahoo require bulk senders to publish a DMARC record with a policy of at least p=none, alongside aligned SPF and DKIM.

The baseline is low on purpose, but the direction of travel is clear: mailbox providers increasingly reward enforced authentication and apply more scrutiny to domains that have none. A domain stuck at monitoring-only is both spoofable and on the wrong side of that trend.

Put plainly: p=none tells you who is sending as you, but it protects no one. It is a starting line, not a finish line.

How to fix it

Fixing this finding is a two-stage job. First publish (or correct) the DMARC record. Then walk the policy up a controlled ramp — none → quarantine → reject — using aggregate reports to confirm your legitimate mail keeps passing at each step.

1. Publish or edit the _dmarc TXT record

DMARC lives in a single DNS TXT record. The hostname is always _dmarc (your DNS provider will append your domain). If you are starting from scratch, publish a monitoring record first so you can see your mail streams before you change anything:

Host:  _dmarc.yourdomain.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

The tags do the following: v=DMARC1 identifies the record version (required, always first); p=none is the policy; and rua=mailto: is the address that will receive the daily aggregate (XML) reports. Those reports are the whole point of this first stage — they list every source sending mail under your domain and whether each one passed SPF and DKIM alignment. fo=1 requests failure reporting when available.

2. Read the reports and fix your sending sources

Leave the record at p=none for a couple of weeks and review the rua reports. Aggregate XML is hard to read by eye, so most teams pipe it into a free or paid DMARC dashboard. The goal is a complete inventory: your mail server, your marketing platform, your CRM, your invoicing or e-commerce system, your help desk — every legitimate source — all passing DMARC alignment. Anything that is yours but failing gets its SPF or DKIM fixed before you enforce.

3. Move to quarantine, then reject

Once your real sources pass cleanly, raise the policy. A safe intermediate step is p=quarantine, which sends failing mail to spam rather than the inbox. You can ease into it with the pct tag, which applies the policy to only a percentage of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1

Watch the reports, raise pct toward 100, then graduate to full enforcement. The end state — the configuration that clears the "policy not enabled" finding for good — is:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1

At p=reject, mail that fails DMARC is bounced outright. Spoofed messages using your domain never reach a single inbox. Keep the rua address in place permanently so you keep getting visibility into any new sender or regression. Note that pct applies to quarantine and reject — at p=none it has no protective effect.

The most damaging mistake with DMARC is jumping straight to p=reject before you have read your aggregate reports. If a legitimate sender you forgot about — an old CRM, an invoicing tool, a marketing platform sending on your behalf — is not yet aligned, enforcement will silently reject that mail. The bounces are easy to miss because they happen at the receiver. Always sit at p=none with a working rua first, confirm every real source passes, and only then enforce.

How do I verify the fix?

DNS changes can take anywhere from a few minutes to a few hours to propagate. Once they have, confirm the record resolves and reads the way you intended. You can query it directly from a terminal:

dig +short TXT _dmarc.yourdomain.com

You should see exactly one v=DMARC1 record with your chosen p= value. Two things to double-check: there must be only one DMARC record (multiple records invalidate each other), and the policy should now read quarantine or reject rather than none. Keep watching your aggregate reports for a couple of weeks after each policy change to catch any source you missed.

Confirm your domain publishes an enforced DMARC policy and your legitimate mail still passes.

Check your DMARC policy →

Learn more

For the full picture of how SPF, DKIM, and DMARC fit together, read our pillar guide on email authentication. If your DMARC is already enforced but mail is still failing checks, see how to fix DMARC failures. For provider-specific setup, follow the Google Workspace or Microsoft 365 DMARC guide.

How to Fix "DMARC Policy Not Enabled" (Quarantine/Reject Not Enabled)