Skip to content
DMARC Done
Fix my DMARC
Free checkHow it worksPricingGuidesBlogLog in

dmarc

DMARC policy not enabled: what it means and how to fix it safely

Scanners say "DMARC policy not enabled" when your record is set to p=none. Here is why p=none is not protection and how to move past it without losing email.

DMARC Done team · 5 October 2026 · 6 min read

You ran your domain through MXToolbox or a security scanner and got the warning “DMARC Policy Not Enabled”. Your domain does have a DMARC record. The warning is about what that record tells receivers to do, which right now is nothing.

This post explains what the warning means, why p=none does not protect you, and how to move to a real policy without blocking your own email.

What the warning means

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain.com. Its most important part is the policy tag, p=, which has three possible values. They are defined in RFC 9989, the current DMARC standard, which replaced the original RFC 7489 in May 2026:

  • p=none: the domain owner expresses no preference. RFC 7489 put it as requesting “no specific action” on mail that fails.
  • p=quarantine: mail that fails should be treated as suspicious, usually by putting it in the spam or junk folder.
  • p=reject: mail that fails should be refused.

“DMARC policy not enabled” means your record says p=none. MXToolbox’s own explanation is that the record “is not currently protected against phishing and spoofing threats”, and that the fix is to “set a Quarantine or Reject policy on the domain’s DMARC record.” In the same breath, it advises not to do that “until you have evaluated your DMARC reports”. Both parts are right, and the rest of this post is about doing them in that order.

Why p=none is not protection

DMARC exists to stop other people from sending email that pretends to come from your domain. With p=none, you have told every receiving server that you do not want anything done about those messages.

Here is what that looks like in practice at Microsoft 365, based on Microsoft’s own documentation of how it treats inbound mail that fails DMARC:

Sender’s policy What Microsoft 365 does with mail that fails DMARC
p=none No DMARC-specific action. Other filtering still applies.
p=quarantine Delivers it to the Junk Email folder (the admin can choose quarantine instead).
p=reject Rejects it during delivery.

That table assumes the receiving organization keeps Microsoft’s “Honor DMARC record policy” setting on, which Microsoft recommends.

So with p=none, a fake invoice sent “from” your domain to your customer is judged only by the receiver’s general spam filters. Those filters may catch it. They may not. Your DMARC record is not helping either way.

Microsoft’s guidance is direct about where you should end up: “The goal is to get to a p=reject DMARC policy for all of your custom domains and subdomains.”

So why does anyone use p=none?

Because it is the right first step, as long as it is not the last one. p=none is monitoring mode. Microsoft describes it as the value you use “for testing and tuning of the DMARC policy.”

While your record is at p=none and includes a reporting address (rua=), receivers such as Gmail and Outlook send you daily aggregate reports. Each report lists the servers that sent mail using your domain, how many messages each sent, and whether they passed SPF and DKIM. That is how you find every legitimate service before you switch on enforcement.

It also meets the minimum for bulk senders: Google’s sender guidelines, which apply to senders of more than 5,000 messages a day to Gmail accounts, say the DMARC policy “can be set to none.”

The problem is that many domains publish p=none and never come back. There is no reporting address, or the reports land in a mailbox nobody reads. The scanner warning is a reminder that the job is half done.

Plain-English takeaway: p=none means “watch, but do nothing”. It is a good starting point for collecting reports and a poor place to stay. Protection starts at p=quarantine and is complete at p=reject.

Why not just switch to p=reject today?

Because you might block your own email. Most small businesses send mail from more places than they think:

  • the mailbox provider (Microsoft 365, Google Workspace, Zoho)
  • a newsletter or marketing tool
  • an invoicing or accounting system
  • a CRM or helpdesk
  • website contact forms and online shop notifications

Each of these has to pass DMARC on its own. A message passes DMARC when SPF or DKIM passes and the domain they checked matches the domain in the From address. This matching is called alignment. A service can pass SPF for its own domain and still fail DMARC for yours, because the domains do not match.

If you switch to p=reject before every one of those services is aligned, receivers that honor DMARC will start refusing your invoices or password resets.

How to fix it safely

1. Make sure reports are arriving

Check that your DMARC record has a rua=mailto: address and that the mailbox exists. A safe starter record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

If you have no reporting address at all, add one and wait for reports before going further. If you have no DMARC record yet, see no DMARC record found.

2. List every service that sends as you

Read the reports for at least two weeks. Group the sending servers by service. Anything you recognize goes on the “ours” list. Anything you do not recognize is either a forgotten tool or someone spoofing you.

3. Make each legitimate service pass with your domain

For each service on the “ours” list:

  • Turn on DKIM signing with your own domain. Most providers call this custom DKIM or domain authentication. DKIM survives forwarding better than SPF, so it is the more reliable of the two.
  • Add the service to SPF only if it uses your domain as its bounce address, and keep the SPF record under its limit of 10 DNS lookups. Our post on SPF lookup limits explains how to count.

4. Move to p=quarantine and watch

When your legitimate mail passes consistently, change p=none to p=quarantine. Keep reading reports. If a forgotten service appears and fails, its mail now lands in spam rather than bouncing, which gives you time to fix it.

Older guides, including Microsoft’s, suggest raising enforcement gradually with the pct tag (for example 10, 25, 50, 75, then 100 percent). The current DMARC standard has dropped pct. Our post on quarantine vs reject explains what replaced it and how long to wait at each stage.

5. Move to p=reject

When quarantine has run cleanly, change the policy to p=reject. Keep the reporting address in the record. Reports are how you notice when someone adds a new tool next year without telling you.

Do not forget your other domains

If you own domains that never send email, such as old brand names or typo domains, you can skip monitoring for those. Microsoft recommends this DMARC record for parked domains:

v=DMARC1; p=reject;

Pair it with an SPF record of v=spf1 -all, which says no server may send mail for that domain.

Check where you stand

Run the free checker at /check?d=yourdomain.com. It shows your current DMARC policy, whether reports are configured, and the SPF and DKIM status that decides whether enforcement is safe.

If you would rather hand the whole move over, we take a domain from p=none to p=reject for a one-time fee, read every report for you, and refund you in full if the domain is not at p=reject within 60 days. See pricing.

Sources

See where your domain stands in 10 seconds

Free. No signup. We do not store the domains you check.