---

title: "Fix: DMARC Policy Not Enabled"
description: "How to fix the 'DMARC policy not enabled' error. A step-by-step guide to moving your domain from p=none to p=quarantine or p=reject."
date: "2026-07-01"

Fix: DMARC Policy Not Enabled

The "DMARC policy not enabled" error means your domain has either no DMARC record at all, or a record set to p=none. In both cases, receiving mail servers are not instructed to act on unauthenticated messages. Anyone can spoof your domain with no consequence.

This guide explains how to fix it.

What the Error Means

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record that tells receiving servers what to do when an email fails SPF or DKIM alignment checks.

There are three policy values:

| Policy | Behavior | |---|---| | p=none | Monitor only. No action taken. | | p=quarantine | Failed messages sent to spam. | | p=reject | Failed messages blocked entirely. |

A domain with p=none is technically "DMARC enabled" but offers no protection. Many email security scanners, inbox providers, and BIMI validators treat p=none as equivalent to no policy.

Step 1: Check Your Current DMARC Record

Run a DNS lookup against your domain's _dmarc subdomain.

dig TXT _dmarc.yourdomain.com +short

Or use a web-based DNS lookup tool. A valid but weak record looks like this:

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

No record returned means DMARC is completely absent.

Step 2: Verify SPF and DKIM Are Passing

Do not move to p=quarantine or p=reject before confirming SPF and DKIM are correctly configured. Jumping to a hard policy without alignment will cause legitimate mail to be blocked.

Check SPF:

dig TXT yourdomain.com +short

Look for a record beginning with v=spf1. A typical SPF record:

"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Check DKIM:

DKIM selectors vary by sending provider. For Google Workspace, check:

dig TXT google._domainkey.yourdomain.com +short

The response should return a p= value containing a public key string.

Send a test message and examine the authentication headers in the received email. Both spf=pass and dkim=pass must appear, with alignment to your From: domain.

Step 3: Publish a DMARC Record with p=none First

If you have no DMARC record, start with p=none to collect reporting data before enforcing any policy.

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Key tags explained:

• rua — Aggregate report destination. Receives daily XML summaries of authentication results.
• ruf — Forensic report destination. Receives individual failure reports.
• fo=1 — Generate failure reports when either SPF or DKIM fails (not just both).

Allow this record to accumulate data for at least two to four weeks before advancing.

Step 4: Analyze Aggregate Reports

DMARC aggregate reports (RUA) arrive as XML files attached to email. They identify every IP address sending mail on behalf of your domain and whether each message passed or failed authentication.

Look for:

• Sending sources you control (ESP, CRM, transactional email providers)
• Legitimate sources failing alignment
• Unknown sources that could indicate spoofing attempts

Fix any legitimate sources that are failing before progressing to enforcement. Common issues include misconfigured third-party senders that have not added your domain's SPF include record or have not implemented DKIM signing.

Step 5: Move to p=quarantine

Once aggregate reports show your legitimate mail streams passing at a high rate, update the policy to p=quarantine:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

The pct tag applies the quarantine policy to a percentage of failing messages. Start at 25, then move to 50, then 100 over successive weeks as you gain confidence.

Step 6: Move to p=reject

Full enforcement requires:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Remove the pct tag at this stage, or set it to pct=100. This instructs receiving servers to reject all unauthenticated messages claiming to originate from your domain.

DNS propagation typically completes within 24–48 hours.

Inbox Provider Requirements

Different providers handle enforcement policies in specific ways.

Gmail honors both p=quarantine and p=reject. Google also requires p=quarantine or p=reject at 100% as a prerequisite for BIMI eligibility.

Apple Mail / iCloud Mail respects all three policy levels. Apple's BIMI implementation reads the Brand Indicators for Message Identification record but requires a valid Verified Mark Certificate (VMC) for display in Apple Mail.

Yahoo Mail enforces DMARC strictly and was among the first major providers to do so. Yahoo also supports BIMI logo display for domains meeting policy requirements.

BIMI Requires an Enforced DMARC Policy

Once p=reject (or p=quarantine at pct=100) is in place, your domain qualifies to publish a BIMI record. BIMI displays your brand logo directly in the inbox next to your sender name.

A BIMI record follows this format:

default._bimi.yourdomain.com.  TXT  "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"

The l= tag points to a Tiny P SVG file hosted on your server. The SVG must conform to the BIMI SVG Profile (SVG Tiny P/S), a restricted subset of the SVG standard. Standard SVG files do not pass validation.

makeBIMI.com converts your existing logo into a BIMI-compliant SVG Tiny P file for free. Upload a PNG, JPG, or standard SVG and receive a validated, specification-compliant file ready for hosting.

The a= tag references your Verified Mark Certificate (VMC), required by Apple Mail and other providers to display the logo with a blue checkmark indicator. veriBIMI.com handles VMC issuance, working with accredited mark verifiers to certify your trademark and issue the certificate.

Common Errors and Fixes

Multiple DMARC records on the same domain Only one TXT record is permitted at _dmarc.yourdomain.com. Remove duplicates. Multiple records cause DMARC to fail entirely.

Subdomain policy not set Add sp=reject to your DMARC record if you want enforcement to apply to subdomains not covered by their own DMARC record:

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

SPF record exceeds DNS lookup limit SPF permits a maximum of ten DNS lookups. Exceeding this causes SPF to return permerror, which breaks DMARC alignment. Audit your SPF record and consolidate include statements.

DKIM key rotation not reflected in DNS After rotating DKIM keys at your mail provider, confirm the new public key is live in DNS before the old key is deactivated. A gap between rotation and DNS propagation causes DKIM failures.

Summary

Fixing "DMARC policy not enabled" is a staged process.

1. Audit current SPF and DKIM configuration.
2. Publish p=none with reporting addresses.
3. Analyze aggregate reports and remediate failing senders.
4. Advance to p=quarantine with pct=25, scaling to 100.
5. Advance to p=reject.
6. Publish a BIMI record with a compliant SVG and VMC.

A domain at p=reject is protected from spoofing, eligible for BIMI logo display, and meets the sender requirements imposed by Gmail, Yahoo, and Apple Mail. Each step in this sequence is a prerequisite for the next. There are no shortcuts.

See also: DMARC requirement for BIMI

Frequently Asked Questions

What does 'DMARC policy not enabled' mean?

It means your domain either has no DMARC record, or has a DMARC record with p=none. A p=none policy monitors but does not enforce — emails that fail authentication are still delivered.

How do I fix DMARC policy not enabled?

Add a DMARC TXT record to your DNS with p=quarantine or p=reject. Start with p=quarantine and monitor aggregate reports before moving to p=reject.

Is DMARC required for BIMI?

Yes. BIMI requires DMARC at p=quarantine or p=reject. A p=none policy will prevent your logo from displaying in Gmail and Apple Mail.