What you'll learn in this article
- “DMARC policy not enabled” usually means your domain has no DMARC record published or your DMARC policy is set to p=none, which monitors but doesn’t take action on unauthenticated mail.
- Fixing it starts with publishing a valid DMARC record (a DNS TXT record) and confirming SPF/DKIM identifier alignment before you move to enforcement.
- Moving from p=none → quarantine → rejection should be gradual, using DMARC reporting to identify every legitimate email source first.
- DKIM is strongest when combined with SPF and DMARC as part of a broader email security strategy.
- Tools like Mimecast DMARC Analyzer can help generate, publish, and monitor records, making enforcement safer and easier to manage at scale.
What is the “DMARC Policy Not Enabled” Error?
The “DMARC policy not enabled” error means your domain is not applying an enforcement action through DMARC. In many tools, it’s triggered when:
- There is no DMARC record published for your domain, or
- A DMARC record exists, but the DMARC policy is set to p=none (monitoring only), so it can’t take action on unauthorized email.
DMARC works with Sender Policy Framework (SPF) and DKIM to support email authentication. SPF checks whether the sending IP is authorized (based on your SPF record). DKIM checks the DKIM signature using your DKIM record.
DMARC then evaluates alignment (also called identifier alignment) to confirm whether SPF or DKIM “matches” the visible From domain, which is what makes DMARC authentication meaningful for brand protection.
Why a DMARC Policy May Not Be Enabled
This DMARC policy not enabled issue usually comes down to one of two things: missing DNS configuration or delayed enforcement.
Common technical causes
This issue is often rooted in DNS configuration and authentication alignment. Before making policy changes, confirm the record exists, is valid, and that SPF/DKIM are set up to align with your From domain.
- No DMARC DNS TXT record published on your DNS server (so tools show “no record” or “DMARC record found: no”)
- DMARC record exists but is incomplete (missing v=DMARC1 or p=), failing dmarc validation
- SPF/DKIM exist, but spf alignment or DKIM alignment isn’t passing, so the domain owner hesitates to enforce
- Third-party senders (marketing platforms, ticketing systems, CRM tools) send mail without proper DKIM signing or aligned SPF
Common organizational causes
Even when the technical pieces are available, organizations may delay enforcement due to risk concerns and unclear sender visibility. These blockers are common in environments with multiple third-party senders and limited DMARC reporting maturity.
- Reliance on SPF/DKIM alone, without realizing DMARC adds enforcement and DMARC reports
- Legacy mail systems and complex sender ecosystems make DMARC implementation feel risky
- Fear of disrupting email deliverability if enforcement is turned on before all senders are accounted for
- Limited visibility into mail streams, so teams don’t know which systems send on behalf of the domain until they begin monitoring with p=none
This is why reporting and monitoring tools matter in reducing guesswork and making enforcement a controlled, staged rollout.
How to Fix the “DMARC Policy Not Enabled” Error
Step 1: Check whether a DMARC record exists
Run a check using a DMARC checker / DMARC lookup tool. You’re looking for confirmation that a DMARC record is present as a DNS TXT record on:
_dmarc.yourdomain.com
If the tool shows “no DMARC record” (or similar), you’ll need to publish one.
Step 2: Generate and publish a basic DMARC record (p=none)
Start with monitoring mode to avoid breaking legitimate mail. A simple DMARC record example:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100
- p=none means monitor only (no enforcement)
- rua= enables DMARC aggregate reports to help you see who’s sending as you
- adkim / aspf set alignment behavior (relaxed is a safer starting point)
You can create this with a DMARC record generator (or “generate DMARC record” workflow), then publish it as a TXT record in DNS.
Step 3: Validate SPF and DKIM alignment before enforcement
Before you move to quarantine or reject:
- Confirm your SPF auth works (your SPF record authorizes the right senders)
- Confirm DKIM signing works (valid DKIM signature for each sending stream)
- Confirm alignment for the From domain (SPF alignment and/or DKIM alignment)
If you don’t validate alignment first, enforcement can impact email provider acceptance and overall email deliverability.
Step 4: Move from monitoring to enforcement safely
Once reporting shows your legitimate email streams are aligned, progress policy:
- p=none → p=quarantine (messages that fail DMARC may be treated as suspicious; often routed to spam)
- p=quarantine → p=reject (strongest enforcement; failing mail is blocked)
This “road to enforcement” approach is widely recommended: monitor first, then tighten. To resolve “DMARC policy not enabled” specifically, many checkers expect quarantine or reject (i.e., enforcement enabled).
Step 5: Use tooling to manage complexity at scale
If you have many domains, many senders, or frequent changes, a hosted DMARC approach can help with:
- Centralized views of DMARC statistics
- Easier record updates
- Faster identification of sources causing DMARC failure
- Simplified enforcement progression
Mimecast DMARC Analyzer includes workflows for generating and publishing DMARC records and analyzing DMARC data, which helps reduce disruption risk during rollout.
Why Enabling DMARC Matters for Email Security
Leaving “DMARC policy not enabled” unresolved means your domain is easier to spoof. Without enforcement, receivers have fewer instructions on what to do with unauthenticated messages claiming to be from you, which increases exposure to phishing and brand impersonation.
Enabling DMARC enforcement supports:
-
Stronger email security (reduces unauthenticated email reaching recipients)
-
Better brand trust and sender reputation over time
-
Improved consistency for inbox placement when authentic mail is aligned
-
Cleaner reporting and faster detection of misconfigured senders
It can also be a prerequisite for some brand indicators. Many BIMI implementations require DMARC enforcement (p=quarantine or p=reject), which means “policy not enabled” can block BIMI progress.
Moving From “DMARC Policy Not Enabled” to Full Protection
“DMARC policy not enabled” is a sign your domain isn’t enforcing DMARC yet, either because no DMARC record exists or because your policy is still set to p=none monitoring mode. The safest fix is a staged rollout: publish a valid DMARC TXT record, use reporting to confirm alignment across all senders, then move to quarantine and ultimately reject.
If you want to reduce risk while speeding up DMARC setup and enforcement, tools like Mimecast DMARC Analyzer can help you track senders, validate changes, and manage reporting at scale.