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

“DMARC policy not enabled” means your domain either has no DMARC record or has one set to p=none, which asks receivers to take no action on mail that fails authentication. It is a warning from a checker, not a delivery error. The fix is to publish a DMARC TXT record at _dmarc.example.com, read the reports it produces, and once your legitimate mail passes, move the policy to quarantine or reject.

This page covers the diagnosis and the minimum fix. For the full phased rollout, use the step-by-step DMARC setup guide.

Which warning did you get, and what does it mean?

Wording varies by tool. The messages below are taken from MXToolbox’s own problem pages (fetched 2026-10-06). Other checkers phrase the same findings differently.

Message on MXToolbox	What it detected	Your fix
“DMARC Record Published Failed” (“No DMARC Record found”)	No DMARC record at _dmarc for the domain	Fix 1
“DMARC Policy Not Enabled”	A record exists, but it does not set a quarantine or reject policy	Fix 2
“DMARC Policy Not Enabled BIMI Required”	The p tag is not quarantine or reject, which BIMI needs	Fix 2

MXToolbox’s page for the second message says the fix is to “set a Quarantine or Reject policy on the domain’s DMARC record”. Messages that mention a “quarantine/reject policy” are the same finding: the record is missing or sits at none.

Is DMARC policy not enabled actually a problem?

At p=none, DMARC monitors and does not enforce. RFC 9989, the current DMARC specification (published May 2026, obsoleting RFC 7489), defines it this way: “none: The Domain Owner offers no expression of preference.” Spoofed mail that uses your domain in the From address is not blocked by DMARC. You get reports, nothing more.

Whether you are required to have a record depends on volume. Checked on 2026-10-06:

• Google: bulk senders, defined as those who “send more than 5,000 messages per day to Gmail accounts”, must set up DMARC, and “Your DMARC enforcement policy can be set to none.” (Google sender guidelines)
• Yahoo: senders must “Publish a valid DMARC policy with at least p=none”. (Yahoo Sender Hub)
• Microsoft: Outlook.com’s page names domains “sending over 5,000 emails per day” and lists SPF, DKIM and DMARC among the standards it enforces from May 5th, 2025. It does not state a minimum policy, so check Microsoft’s page for your case.
• BIMI: the BIMI Group’s implementation guide says “‘None’ policies or ‘pct’ less than 100 percent are not accepted”, so a logo in the inbox needs quarantine or reject.

A missing record can fail those bulk-sender rules. A p=none record satisfies Google and Yahoo, which is why you can see this warning while mail still delivers. See email deliverability best practices for how authentication fits with the rest of your sending setup.

Fix 1: publish a DMARC record when none exists

1. Confirm the record is really missing:

dig +short TXT _dmarc.example.com
# Windows:
nslookup -type=TXT _dmarc.example.com

Empty output means no record. A published record returns a string starting with v=DMARC1.

1. Confirm [SPF](https://coldletter.com/blog/spf-record-syntax/) and [DKIM](https://coldletter.com/blog/what-is-dkim/) are in place. DMARC has nothing to evaluate without them. The overview of [SPF, DKIM, and DMARC](https://coldletter.com/blog/what-is-email-authentication/) explains how the three fit together.
2. Add a TXT record. Most DNS hosts want just `_dmarc` in the Name or Host field, because they append the domain themselves. Some want the full `_dmarc.example.com`.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

1. Re-run the dig command. How soon it appears depends on the record’s TTL and your DNS host.

If the rua mailbox is on a different domain than the one you are protecting, the receiving domain must authorize it. RFC 9990 describes a TXT record at example.com._report._dmarc.<destination-host> whose value starts with v=DMARC1. Without it, receivers must ignore the external reporting address.

Publishing p=none clears the “no record” warning. It will still trigger the “policy not enabled” one, which is expected at this stage.

Fix 2: move from p=none to an enforcing policy

Confirm alignment first. Only enforce after your aggregate reports show every legitimate sender passing SPF or DKIM with a domain that matches your From address. That includes your marketing tool, your CRM and any support desk that sends as your domain. Third-party senders often need their own DKIM selector published in your DNS. The setup guide’s report-reading step shows how to find failing sources.

Then change one tag:

# Before
v=DMARC1; p=none; rua=mailto:[email protected]

# After
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Policy	What you are asking receivers to do	Clears the checker warning?
p=none	Nothing, reports only	No
p=quarantine	Treat failing mail as suspicious, typically junk folder	Yes
p=reject	Treat failing mail as invalid and refuse it	Yes

RFC 9989 words these as “quarantine: The Domain Owner considers such mail to be suspicious” and “reject: The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid.” Receivers decide what to do with that request.

Two more tags matter here:

• sp= sets the policy for subdomains, which otherwise follow p. RFC 9989 also adds np= for non-existent subdomains.
• pct= is gone from the current specification. RFC 9989 removes it (Appendix A.6) and adds a t tag: t=y asks receivers to apply a policy one level below yours, so p=reject; t=y is treated as quarantine. Older checkers and the BIMI guide still reference pct, and the t tag is new, so confirm its effect in your reports rather than assuming every receiver applies it.

Once a policy is enforcing, Google Postmaster Tools is a useful second signal for how Gmail sees your domain.

Why the DMARC warning comes back after you fix it

If the checker still complains after you published a record, work through this list.

• Two DMARC records at the same name. RFC 9989, Section 4.10: “If multiple DMARC Policy Records are returned for a single target, they are all discarded.” Result: you effectively have none. Delete the extra one.
• Record at the wrong name. It must be at _dmarc.example.com, not at example.com or dmarc.example.com.
• v=DMARC1 is not first or is mistyped. Per the RFC, “Records that do not start with a ‘v’ tag that identifies the current version of DMARC are discarded.”
• No valid p tag. RFC 9989 treats a record without a p tag as p=none and discards syntax errors in favor of default values, so a misspelled policy leaves you at none and the warning persists.
• Wrong domain tested. sp= governs subdomains, so a check on mail.example.com can reflect a different policy than your root domain. Test the exact domain you send from.
• A cached result. Resolvers keep the old answer until the TTL expires. Query a public resolver directly, for example dig +short TXT _dmarc.example.com @1.1.1.1.

Frequently Asked Questions