DMARC policy not enabled

What this warning means, why scanners report it, and how to safely move from no DMARC or p=none to quarantine or reject without blocking legitimate mail.

Quick answers

What does DMARC policy not enabled mean?
It usually means the domain has no valid DMARC record, has a malformed record, or has a record set to p=none. Some scanners use the phrase only when they expect an enforcement policy such as p=quarantine or p=reject.
Is p=none a DMARC policy?
Yes. p=none is a valid DMARC policy for monitoring, but it does not ask receivers to quarantine or reject failing mail. If a report says quarantine/reject policy not enabled, it is asking for enforcement rather than basic monitoring.
Should I change directly from no DMARC to p=reject?
Usually no. First publish p=none with a rua reporting address, review your real sending sources, fix SPF or DKIM alignment, then move through quarantine before reject.
What DNS record enables DMARC enforcement?
A valid TXT record at _dmarc.yourdomain.com with p=quarantine or p=reject enables enforcement. Use pct during rollout only when you intentionally want partial enforcement.
How do I know the warning is fixed?
Query _dmarc.yourdomain.com from public DNS and confirm exactly one valid v=DMARC1 record with the intended p= value. Then validate the same domain in a DMARC checker.

The exact warning

You will usually see one of these messages in a security scanner, deliverability tool, BIMI readiness check, or vendor questionnaire: 

DMARC policy not enabled
DMARC quarantine/reject policy not enabled
No DMARC policy found
DMARC policy is p=none

The wording is imprecise. A domain can have DMARC monitoring enabled with p=none, but not have DMARC enforcement enabled. Many tools collapse those states into the same warning, so the first job is to identify which state your DNS is actually in.

What it means

DMARC has three policy values:

  • p=none - monitor only. Receivers report failures but are not asked to block them.
  • p=quarantine - enforcement. Receivers are asked to send failing mail to spam or a similar holding area.
  • p=reject - enforcement. Receivers are asked to reject failing mail during SMTP delivery.

If the error says "DMARC policy not enabled", the tool may mean no usable _dmarc record exists. If it says "DMARC quarantine/reject policy not enabled", it almost always means your current record is valid but still set to p=none.

Step 1: check the current DMARC record

Query the exact DNS name receivers use: 

dig TXT _dmarc.example.com +short

On Windows: 

nslookup -type=TXT _dmarc.example.com

Replace example.com with the domain in the visible From: address. DMARC is checked against that domain, not necessarily the server that sent the message.

If there is no result

DMARC is not published for that domain. Add a TXT record named _dmarc at your DNS provider. A safe monitoring record looks like this: 

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

Use a mailbox or reporting service that actually processes aggregate reports. Publishing p=none without reports gives you almost no operational visibility.

If the result does not start with v=DMARC1

The record is malformed or published at the wrong name. The TXT value must start with v=DMARC1 and must be published at _dmarc.example.com. Common mistakes include publishing at the root domain, using dmarc without the underscore, or adding the full domain twice in DNS providers that append the zone name automatically.

If there is more than one DMARC record

A domain must have exactly one DMARC TXT record at _dmarc. If two records start with v=DMARC1, receivers treat the policy as invalid. Edit the existing record instead of adding another one.

Step 2: decide whether you need monitoring or enforcement

If this is a brand-new DMARC deployment, start with p=none. That is not a failure; it is the normal discovery phase. Use it to collect aggregate reports and identify every service sending mail with your domain in the visible From: header.

If the warning comes from a requirement that explicitly says "quarantine or reject", p=none will not satisfy it. Common examples include internal security baselines, some cyber insurance questionnaires, BIMI readiness checks, and vendor compliance reviews.

Step 3: make legitimate mail pass DMARC

Before you enforce, every legitimate sender should pass DMARC through either aligned SPF or aligned DKIM:

  • SPF alignment: the envelope sender domain must match, or be a subdomain of, the visible From: domain under relaxed alignment.
  • DKIM alignment: the d= signing domain in the DKIM signature must match, or be a subdomain of, the visible From: domain under relaxed alignment.
  • Only one needs to pass. DMARC passes if either SPF or DKIM passes and aligns.

This is where aggregate reports matter. They show which source IPs and sending services pass, fail, and align. If you enforce before fixing those senders, legitimate mail can land in spam or be rejected.

Step 4: move to quarantine safely

When your reports show that normal mail is aligned, change the policy from none to quarantine. For a cautious rollout, use pct first: 

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Watch reports for failed legitimate senders. If the results are clean, raise pct: 

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]

Some scanners still warn when pct is below 100 because only part of failing traffic is covered. If the requirement is strict, use pct=100 or omit pct, since 100 is the default.

Step 5: move to reject when quarantine is clean

After quarantine runs without legitimate mail problems, move to reject: 

v=DMARC1; p=reject; rua=mailto:[email protected]

p=reject is the strongest DMARC policy. It tells receivers to reject unauthenticated, non-aligned mail that claims to be from your domain. This is the state most policy-not-enabled warnings are ultimately trying to push you toward.

Subdomains can still trigger the warning

DMARC policy inheritance is easy to miss. If mail.example.com sends mail, receivers first look for _dmarc.mail.example.com. If no subdomain record exists, they fall back to the organizational domain policy at _dmarc.example.com.

You can define a subdomain policy with sp=: 

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

If a scanner checks a sending subdomain directly, it may report policy not enabled when the subdomain has no explicit record, even though receivers would inherit the parent policy. Check what hostname the scanner is evaluating before changing DNS.

Common mistakes that keep the warning open

  • Wrong host field: publishing _dmarc.example.com.example.com because your DNS provider appends the zone automatically.
  • Two DMARC records: adding a second TXT record instead of editing the existing one.
  • Policy typo: using policy=reject instead of p=reject.
  • Quoted mailto value: publishing rua="mailto:..." inside the record. DMARC tag values do not use quotes.
  • Partial enforcement: leaving pct=10 when a compliance scanner expects full enforcement.
  • DNS propagation: checking too soon after the change. Wait at least one TTL and query multiple public resolvers.

Validate the fix

After updating DNS, query public resolvers directly: 

dig TXT _dmarc.example.com @1.1.1.1 +short
dig TXT _dmarc.example.com @8.8.8.8 +short

Confirm exactly one record appears, it starts with v=DMARC1, and the p= value matches the policy you intended.

Then run the domain through the DMARCTrust DMARC checker. It verifies the live DNS record and shows whether SPF, DKIM, and DMARC are configured well enough to support enforcement.

Was this page helpful? Send us feedback

Last updated: May 2026

← All guides Start now

Need expert help with email deliverability?

Hire an email deliverability consultant who has shipped billions of emails. Free assessment, hands-on engagement, written quote before any work starts.

Talk to a consultant