DMARC Policy Not Enabled: What the Warning Means and How to Fix It

A scanner flags your domain with "DMARC quarantine/reject policy not enabled" and the wording suggests something is missing. Usually nothing is missing. You have a DMARC record, it published correctly, and it is set to p=none, which tells receiving servers to take no action on messages that fail authentication. The record exists and does nothing, which is exactly what p=none is for.

Whether that is a problem depends on how long it has been that way and what you are sending.

What the warning is reading

DMARC is a policy layered on top of SPF and DKIM. It does two things: it tells receiving mail servers what to do with messages that fail authentication, and it asks them to send you reports about it.

The p= tag carries the instruction, and it has three values.

p=noneMonitor

• No action taken on failing mail
• Reports still arrive
• Spoofed mail reaches inboxes unchanged
• The correct starting position

p=quarantineEnforce, softly

• Failing mail is routed to spam
• Legitimate senders you missed become visible fast
• Reversible without much damage
• The usual second step

p=rejectEnforce, fully

• Failing mail is blocked outright
• Strongest protection against spoofing of your domain
• Any sender you forgot is now silently failing
• The destination

The scanner is telling you that you are in column one. That is a finding, not a fault. Publishing p=none first is what the specification and every major mailbox provider recommend, because it lets you discover which legitimate services send on your behalf before you start blocking things.

The failure mode is not starting at p=none. It is staying there for two years because nobody scheduled the next step.

How DMARC actually decides

The part that trips people up is that DMARC does not require both SPF and DKIM to pass. It requires either one to pass and to align.

1. Step 1Check SPF

   Did the sending IP pass SPF, and does the MAIL FROM domain align with the From domain?

2. Step 2Check DKIM

   Did the signature validate, and does the signing domain align with the From domain?

3. Step 3Pass if either aligned

   One aligned pass is enough. DMARC does not need both.

4. Step 4Apply the policy

   Only if both fail does the p= value decide what happens to the message.

Alignment is the word doing the work. A message can pass SPF outright and still fail DMARC, because the domain that passed SPF is not the domain in the visible From header. This is the standard behaviour of many third-party senders: they send from their own infrastructure with their own return path, so SPF passes for their domain and aligns with nothing you own. DKIM signing with your domain is what fixes that, which is why every sending platform asks you to publish DKIM records.

What changed in 2026

If you are reading older guidance, some of it is now out of date. The IETF published an updated DMARC specification on 20 May 2026: RFC 9989 (core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). Together they obsolete RFC 7489, the original DMARC specification, and RFC 9091.

Three changes matter for anyone doing a rollout now.

The pct tag is historic. The classic advice was to enforce gradually by percentage, publishing p=quarantine; pct=25 and stepping upward. pct= is deprecated in the new specification, along with rf= and ri=. Receivers ignore deprecated tags rather than rejecting the record, so an existing record with pct= keeps working, but you should not build a new rollout plan around it.

np= is new. It sets a policy for non-existent subdomains, which is the surface attackers use most often when spoofing a domain that has enforcement on the main name. It is worth publishing.

SPF evaluation narrowed. DMARC now uses only the MAIL FROM address, with no fallback to the HELO identifier. If any of your mail was passing DMARC via HELO, it is not any more.

The sp= subdomain policy tag and the adkim= and aspf= alignment tags keep their previous meanings, so those parts of an existing record are unaffected.

Should you enforce at all

For cold outbound specifically, the answer is more nuanced than security scanners imply. Enforcement protects your domain from being spoofed by other people. It does not, by itself, improve your own deliverability, because your own mail should be passing DMARC either way.

What enforcement does buy you with mailbox providers is a signal that the domain is properly administered. And what p=none costs you is that anyone can send mail claiming to be your domain and receiving servers will deliver it.

Google's bulk sender requirements are the concrete threshold. If you send 5,000 or more messages a day to Gmail, you must have SPF, DKIM and DMARC in place. Notably, Google states that the DMARC enforcement policy can be set to none, so p=none satisfies the requirement as written. The same guidance requires keeping spam rates in Postmaster Tools below 0.30% and supporting one-click unsubscribe on marketing and subscription messages.

So the compliance bar is a published record, not enforcement. Enforcement is the security decision layered on top.

Getting from none to enforcement

The sequence is the same for everyone and the only real variable is how long you spend in each stage.

1. Week 0Publish p=none with reporting

   Include a rua address so aggregate reports have somewhere to go. Without rua, the monitoring stage collects nothing.

2. Weeks 1 to 4Read the reports

   Enumerate every source sending as your domain. Expect to find services nobody remembers authorising.

3. Weeks 4 to 8Fix alignment

   Add DKIM signing for every legitimate sender. Retire the ones you cannot authenticate.

4. Week 8Move to quarantine

   Watch reports closely for a fortnight. Anything you missed appears here rather than bouncing.

5. Week 10 onwardMove to reject

   Add np= for non-existent subdomains and sp= if subdomains need their own policy.

The stage worth protecting is the reading stage. Aggregate reports are XML, they arrive daily from every major receiver, and reading them by hand is unpleasant enough that people skip it and enforce blind. Enforcing blind is how a payroll provider or an old marketing tool starts silently failing three weeks later. Either use a report parser or budget real time for it.

Ready to enforce?

• ✓Yes: A rua address is published and reports are actually arriving
• ✓Yes: Every legitimate sending source has been identified in the reports
• ✓Yes: Each of those sources signs with DKIM aligned to your domain
• ✓Yes: Someone owns the reports after enforcement, not just before
• ✓Yes: Your SPF record resolves within the 10-lookup limit
• ✕No: You are building the plan around pct= stepping
• ~Depends: Subdomains need a policy different from the parent domain

Reading an aggregate report without a parser

The reports arriving at your rua address are gzipped XML, one per receiver per day. They contain no message content, which is worth knowing before you worry about privacy: an aggregate report is counts and authentication results, not mail.

Each report is a list of records. A record groups messages by sending IP and tells you, for that IP: how many messages, what DMARC verdict was applied, whether SPF passed and for which domain, and whether DKIM passed and for which domain.

What you are looking for on the first pass is a list of sending IPs you cannot account for. Some will be obvious once you see the associated domain: a marketing platform, a helpdesk, an invoicing tool. Some will be genuinely unknown and turn out to be a department that signed up for something. A few will be forwarding, which is the most confusing category, because legitimate mail forwarded through a mailing list often breaks SPF while DKIM survives, and the record shows a partial failure that is not an attack.

Two habits make this bearable. Sort by message volume rather than reading top to bottom, because the long tail of one-message-per-day IPs is mostly noise while the top five sources are almost all of your mail. And resolve the unknowns before enforcing rather than while enforcing, because after enforcement the same unknown source is a support ticket instead of a line in a report.

Where DMARC failures usually come from

In practice the same handful of causes account for most of what you will find.

Third-party senders without aligned DKIM. The service sends from its own infrastructure, SPF passes for the service's domain, and nothing aligns with yours. The fix is publishing the DKIM records the platform gives you, which most provide and many customers never complete.

SPF records over the lookup limit. SPF permits a maximum of ten DNS lookups when evaluating a record, and each include: can consume several. Accumulate enough vendors and the record silently exceeds the limit, at which point SPF returns an error rather than a pass. This is common on domains that have collected tools over years.

Subdomains nobody thought about. A policy on the parent domain does not automatically govern how strictly subdomains are treated once you start using sp=, and non-existent subdomains were unprotected entirely until np= arrived.

Forwarding. Not fixable by you, and not usually a reason to delay enforcement, because DKIM typically survives forwarding while SPF does not, and one aligned pass is enough.

The cold email angle

Two points specific to outbound sending.

First, if you send from separate domains rather than your primary domain, each of those domains needs its own DMARC record. The policy on your main company domain does not extend to yourbrand-mail.com. This is routinely missed, and a sending domain with no DMARC record at all is a worse signal than one at p=none.

Second, enforcement on your primary domain is a reason to keep outbound on separate domains, not an obstacle to it. A strict policy on the domain your invoices and contracts come from is exactly right. Outbound sending domains are separate so that a reputation problem in one place cannot reach the other.

The mechanics of publishing the underlying records are covered in our SPF, DKIM and DMARC setup guide for cold email. For reading what receivers report back about your sending, Google Postmaster Tools is where the spam rate threshold above is measured. If mail is already failing to land, the blacklist check and recovery guide covers diagnosis, and the cold email deliverability guide covers the ongoing maintenance side.

Fixing the warning

If you want the scanner to stop flagging it, the change is one DNS record edit: p=none becomes p=quarantine. That takes thirty seconds and is the wrong first move.

Do the monitoring work first. Publish rua, read what comes back for a month, authenticate everything legitimate, then enforce. The warning is not urgent. A payroll notification silently quarantined because nobody checked the reports is.

If you would rather not own this layer at all, it is one of the more defensible things to outsource, because the work is continuous rather than one-off and the cost of learning it on your own domain is reputational. We run sending infrastructure as part of our outbound engagements, and you can see what a campaign would look like for your market.

DMARC specification details are per RFC 9989, 9990 and 9991, published 20 May 2026. Google bulk sender requirements are per Google's published sender guidelines as of August 2026. Verify current requirements with the official sources before making DNS changes.

Sources: IETF publishes updated DMARC specification, dmarc.org, Google email sender guidelines