---
title: "DMARC Quarantine/Reject Policy Not Enabled: Fix It"
description: "See 'DMARC quarantine/reject policy not enabled'? Learn what it means, why it matters, and how to fix it step by step for any DNS provider. Free checker included."
publishedAt: 2026-03-11
lastUpdatedAt: 2026-03-12
tags: ["dmarc", "troubleshooting", "email-authentication", "dns", "enforcement"]
faq:
- question: "What is the difference between DMARC quarantine and reject?"
answer: "Quarantine tells receiving servers to treat failing emails as suspicious — typically routing them to the spam folder. Reject tells receivers to block failing emails outright. Quarantine is a safer intermediate step while you verify all legitimate senders pass authentication before moving to reject."
- question: "Will enabling DMARC enforcement break my email?"
answer: "It can if legitimate senders are not configured with proper SPF and DKIM alignment. Monitor with p=none first, review aggregate reports for two to four weeks, then gradually increase enforcement using the pct= tag. Start at pct=25 with quarantine before moving to full reject."
- question: "How long does a DMARC policy change take to propagate?"
answer: "DNS changes typically propagate within 15 to 60 minutes, though some providers may take up to 48 hours. You can verify your updated record immediately using a DMARC lookup tool. Lower your TTL before making changes to speed up propagation."
- question: "Do Google and Yahoo require DMARC enforcement (quarantine or reject)?"
answer: "No. Both explicitly accept p=none as sufficient for their bulk sender requirements. However, Yahoo recommends enforcement if you have a spoofing problem, and Google's guidelines note that enforcement provides stronger protection. The requirement is a floor, not a ceiling."
- question: "Does PCI DSS 4.0 require DMARC?"
answer: "PCI DSS 4.0 Section 5.4.1 requires anti-phishing mechanisms. DMARC is mentioned in the implementation guidance as an example but is not the sole required method. Many auditors interpret p=none as insufficient since it takes no action on failures. Enforcement at quarantine or reject strengthens your compliance posture."
---
# How to Fix "DMARC Quarantine/Reject Policy Not Enabled"
If your security scanner shows "DMARC quarantine/reject policy not enabled,"
your domain's DMARC record exists but is not enforcing anything. The record uses
`p=none` — a monitoring-only mode that collects reports while letting spoofed
emails reach inboxes unchanged. Tools like MXToolbox, Plesk server health
monitors, Google Postmaster, and email deliverability audit platforms all flag
this warning. You will also see it during PCI DSS compliance scans and
third-party penetration tests that evaluate your DNS posture.
This is more common than you might expect. In our scan of 5.5 million domains,
only 12.8% enforce DMARC with a quarantine or reject policy. The remaining 87.2%
either have no DMARC record at all or sit at `p=none`.
_Source:
[DMARCguard State of Email Authentication 2026](/research/email-authentication-2026/)
— 5,499,028 domains scanned_
This guide explains what the warning means, why it matters, and exactly how to
move from `p=none` to enforcement — with steps for six major DNS providers. If
you are not sure whether your record is at `p=none`,
[check your current DMARC record](/tools/dmarc-checker/) first.
If you are troubleshooting a DMARC failure rather than a policy warning, see our
[DMARC failed troubleshooting guide](/blog/dmarc-failed-how-to-fix/).
## What Does "DMARC Policy Not Enabled" Mean?
A DMARC record lives as a DNS TXT record at `_dmarc.yourdomain.com`. It tells
receiving mail servers what to do when an email claiming to be from your domain
fails authentication. The key tag is `p=`, which sets your policy.
The `p=` tag is the most important part of a DMARC record. It is the instruction
you give to every receiving mail server in the world: "when an email claiming to
be from my domain fails authentication, here is what you should do with it."
With `p=none`, that instruction is "do nothing" — deliver it anyway.
There are three policy levels, defined in
[RFC 7489 Section 6.3](https://datatracker.ietf.org/doc/html/rfc7489#section-6.3):
{/* TODO: SVG diagram — three DMARC policy levels and what happens to failing email at each (none: delivered, quarantine: spam folder, reject: blocked) */}
Here is what the difference looks like in DNS.
**Monitoring only** — triggers the warning:
**Enforcement** — resolves the warning:
The only difference between the two records is a single tag: `p=none` versus
`p=reject`. That one value changes whether receiving servers ignore or act on
authentication failures.
When security scanners flag "DMARC quarantine/reject policy not enabled," they
are telling you that your record exists at `p=none`. Reports arrive, but no
email is quarantined or rejected based on authentication results.
The record works — it is syntactically valid and receivers process it. The issue
is that `p=none` provides visibility without protection.
## Why Staying at p=none Puts Your Domain at Risk
A `p=none` policy means anyone can send email that appears to come from your
domain, and it reaches inboxes. Here is what that looks like in practice.
### State-sponsored spoofing
In late 2023, the North Korean threat group
[Kimsuky exploited domains](https://attack.mitre.org/groups/G0094/) with
`p=none` or no DMARC record to spearphish U.S. policy experts. They impersonated
journalists and academics at think tanks and universities, targeting government
officials and researchers working on East Asian foreign policy.
The attack was serious enough to
[prompt a joint FBI, NSA, and State Department cybersecurity advisory](https://media.defense.gov/2023/Jun/01/2003234055/-1/-1/0/JOINT_CSA_DPRK_SOCIAL_ENGINEERING.PDF).
The advisory's primary mitigation recommendation: upgrade to `p=quarantine` or
`p=reject`.
"Missing DMARC policies or DMARC policies with 'p=none' indicate that the receiving email server should take no security action on emails that fail DMARC checks and allow the emails to be sent through to the recipient's inbox. In order for organizations to make their policy stricter [...] the authoring agencies recommend updating your organization's DMARC policy to 'p=quarantine' or 'p=reject'."
_Source:
[FBI/NSA/State Dept Joint Cybersecurity Advisory JCSA-20240502-001](https://www.ic3.gov/CSA/2024/240502.pdf)_
### Financial impact
Orion S.A., a global chemical manufacturer,
[lost approximately $60 million in a business email compromise (BEC) attack](https://www.helpnetsecurity.com/2024/08/13/orion-fraudulent-wire-transfers-60-million/)
disclosed via SEC Form 8-K in August 2024. A non-executive employee was tricked
into executing multiple fraudulent wire transfers. Industry analysis identifies
this as BEC — the canonical attack type that DMARC enforcement is designed to
prevent.
_Caveat: The DMARC gap is inferred from the attack type, not explicitly stated
in the
[SEC filing](https://www.sec.gov/Archives/edgar/data/1609804/000095014224002170/eh240519238_8k.htm).
If the attack used a lookalike domain rather than exact-domain spoofing, DMARC
alone would not have prevented it._
### The industry gap
Of 5.5 million domains we scanned, 57.9% of those with DMARC records remain at
`p=none`. Only 6.8% use `p=quarantine` and 6.0% use `p=reject`. The gap between
having a DMARC record and actually enforcing it is the industry's most common
vulnerability.
_Source: DMARCguard State of Email Authentication 2026 — 5,499,028 domains
scanned_
Beyond security, there is a practical business incentive: **BIMI eligibility**.
Brand Indicators for Message Identification lets your logo appear next to your
emails in Gmail, Yahoo, and Apple Mail inboxes. BIMI requires `p=quarantine` or
`p=reject` — `p=none` does not qualify.
## Before You Switch — Check Your Sending Sources
Do not jump straight to `p=reject`. The most common concern about enabling DMARC
enforcement is breaking legitimate email — and it is a valid concern. Moving to
enforcement without preparation can quarantine or reject messages from your own
marketing platform, CRM, or support desk.
Follow these three steps before changing your policy:
1. **Review your DMARC aggregate reports (RUA).** These XML reports list every
IP address that sent email using your domain. Look for all legitimate senders
and check whether they show SPF and/or DKIM as aligned. Unknown IP addresses
need investigation before you enforce.
2. **Identify all third-party senders.** Marketing platforms (Mailchimp,
HubSpot), transactional services (SendGrid, Amazon SES), support desks
(Zendesk, Freshdesk), and CRMs (Salesforce) all send on your behalf. Each
must pass DKIM alignment on your domain.
3. **Verify SPF and DKIM are configured for every sender.** Each service should
have custom DKIM signing with `d=yourdomain.com` (not the service's default
domain). Custom Return-Path domains align SPF. Both are typically configured
through the service's "domain authentication" or "verified sending domain"
settings.
Use a [SPF checker](/tools/spf-checker/) to verify your SPF record includes all
authorized senders, and a [DKIM checker](/tools/dkim-checker/) to confirm DKIM
selectors are published and valid.
**Green light signals** — you are ready to enforce:
- Two to four weeks of aggregate reports show only unauthorized senders failing
- All known services pass SPF or DKIM alignment
- No legitimate senders appear in the "fail" column
**Red flag signals** — fix these first:
- Legitimate senders still failing authentication — configure their DKIM/SPF
before enforcing
- Unknown sending sources with high message volumes — investigate before
blocking
- SPF record approaching the 10-DNS-lookup limit — flatten or consolidate before
adding more `include:` mechanisms
## Step-by-Step — Enable Enforcement
The recommended path uses gradual rollout with the `pct=` tag. This tag tells
receivers to apply your policy to only a percentage of failing messages, letting
you catch problems before they affect all mail.
**Recommended rollout:**
1. `p=quarantine; pct=25` — quarantine 25% of failing mail
2. `p=quarantine; pct=50` → `pct=100` — increase over 1-2 weeks
3. `p=reject; pct=25` — reject 25% of failing mail
4. `p=reject; pct=100` — full enforcement
{/* TODO: SVG diagram — gradual pct= rollout: none → quarantine 25% → 100% → reject 25% → 100% */}
Here is the record for the first step:
The `adkim=r` and `aspf=r` tags set relaxed alignment for DKIM and SPF
respectively, meaning subdomains of your domain also count as aligned — this is
the default and the safest choice during rollout, since many third-party
services sign from subdomains like `email.yourdomain.com`.
Monitor your aggregate reports at each stage. If legitimate mail starts failing,
pause and fix the sender configuration before increasing `pct=`.
{/* TODO: Screenshots — editing DMARC TXT record in Cloudflare, cPanel, GoDaddy DNS management panels */}
### Cloudflare
1. Log in to the Cloudflare dashboard and select your domain
2. Go to **DNS** → **Records**
3. Find the TXT record with name `_dmarc`
4. Click **Edit** and update the `p=` value from `none` to `quarantine`
5. Add `pct=25` after the policy tag
6. Save
### cPanel / WHM
1. Log in to cPanel and open **Zone Editor**
2. Find the TXT record for `_dmarc.yourdomain.com`
3. Click **Edit** and change `p=none` to `p=quarantine; pct=25`
4. Save the record
### GoDaddy
1. Go to **My Products** → **DNS Management** for your domain
2. Find the TXT record with host `_dmarc`
3. Click the pencil icon to edit
4. Update the value, changing `p=none` to `p=quarantine; pct=25`
5. Save
### AWS Route 53
1. Open the Route 53 console → **Hosted zones** → select your domain
2. Find the `_dmarc.yourdomain.com` TXT record
3. Click **Edit record** and update the `p=` value
4. Save changes
### Google Cloud DNS
1. Open Cloud Console → **Network services** → **Cloud DNS**
2. Select your zone and find the `_dmarc` TXT record
3. Click **Edit** and update the policy value
4. Save
### Namecheap
1. Go to **Domain List** → **Manage** → **Advanced DNS**
2. Find the TXT record with host `_dmarc`
3. Click **Edit** and change the `p=` value
4. Save all changes
### After updating
DNS changes typically propagate within 15 to 60 minutes. Use a DMARC lookup tool
to verify the updated record is live. If you have a high TTL on the existing
record, propagation may take up to 48 hours.
**Subdomain policy (sp=):** If your organization does not send email from
subdomains, add `sp=reject` to your DMARC record. This prevents attackers from
spoofing `anything.yourdomain.com` while your organizational domain is enforced.
## What About Forwarded Emails? (ARC Explained)
The most common reason organizations delay DMARC enforcement is email
forwarding. When an email is forwarded — through mailing lists, `.forward`
rules, or alias services — two things break:
- **SPF fails** because the forwarding server's IP address is not in the
original domain's SPF record
- **DKIM may break** if the forwarding server modifies the message body or
headers (adding footers, rewriting subjects)
When both SPF and DKIM fail on forwarded mail, DMARC fails too — even though the
original message was legitimate. This creates a real problem: enforce DMARC and
forwarded mail from mailing lists bounces.
**ARC (Authenticated Received Chain)** solves this. ARC is a protocol
([RFC 8617](https://datatracker.ietf.org/doc/html/rfc8617)) that lets forwarding
servers preserve the original authentication results in special ARC headers.
When a receiving server sees that a trusted forwarder has vouched for the
original authentication, it can accept the message even though SPF and DKIM no
longer pass.
The three largest mailbox providers — Gmail, Microsoft 365, and Yahoo — all
support ARC on both sending and receiving sides. If your mail is forwarded
through these providers, ARC headers are already being added.
If you run mailing lists or use email forwarding extensively, check whether your
mail server supports ARC. You can inspect ARC headers on forwarded messages
using our [ARC chain analyzer](/tools/arc-chain-analyzer/).
For a deeper look at how ARC works and who supports it, see our
[ARC protocol guide](/learn/arc/).
## Regulatory and Industry Pressure to Enforce
Several major mandates now require DMARC for email senders. It is important to
understand what they actually require — and what they do not.
_Source: .gov adoption data from DMARCguard State of Email Authentication 2026_
If your organization sends bulk email, processes payments, or operates in a
regulated industry, at least one of these mandates applies to you. Even if
`p=none` technically satisfies today's minimum requirements, the trajectory is
unmistakable: every revision tightens the bar.
Here is the honest framing:
[Google](https://support.google.com/a/answer/81126?hl=en),
[Yahoo](https://senders.yahooinc.com/best-practices/), and
[Microsoft](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)
all explicitly accept `p=none` as sufficient for their bulk sender requirements.
PCI DSS 4.0 Section 5.4.1 requires "anti-phishing mechanisms" and mentions DMARC
in implementation guidance as an example — but does not mandate a specific
policy level. Many auditors interpret `p=none` as insufficient because it takes
no protective action on failures, but this is an interpretation, not a
requirement.
The exception is
[CISA BOD 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security),
which requires U.S. federal agencies to reach `p=reject`. The result: .gov
domains lead the private sector at 76.4% DMARC adoption.
The direction is clear. Every mandate is moving toward authentication
enforcement. `p=none` meets today's minimum requirements. `p=quarantine` or
`p=reject` is where the industry is heading — and where your domain's protection
starts.
## Frequently Asked Questions
### What is the difference between DMARC quarantine and reject?
Quarantine tells receiving mail servers to treat emails that fail DMARC as
suspicious. In practice, this means routing them to the spam or junk folder.
Reject tells receivers to block failing emails entirely — they never reach the
recipient's inbox or spam folder. Quarantine is a good intermediate step while
you verify all legitimate senders pass authentication, because misrouted mail
can still be recovered from spam. Rejected mail cannot.
### Will enabling DMARC enforcement break my email?
It can, if legitimate senders are not configured with proper SPF and DKIM
alignment. That is why we recommend monitoring with `p=none` first, reviewing
aggregate reports for two to four weeks, then gradually increasing enforcement
using the `pct=` tag. Start at `pct=25` with `p=quarantine` before moving to
full `p=reject`. This staged approach lets you catch and fix issues before they
affect all your mail.
### How long does a DMARC policy change take to propagate?
DNS changes typically propagate within 15 to 60 minutes, though some providers
may take up to 48 hours. You can verify your updated record immediately using a
DMARC lookup tool. To speed up propagation, lower your TTL (Time to Live) value
on the `_dmarc` TXT record before making changes — a TTL of 300 seconds (5
minutes) is a common choice during policy transitions.
### Do Google and Yahoo require DMARC enforcement (quarantine or reject)?
No — both explicitly accept `p=none` as sufficient for their bulk sender
requirements (5,000+ messages per day for Google). However, Yahoo recommends
enforcement if you have a spoofing problem, and Google's guidelines note that
enforcement provides stronger protection. These requirements are a floor, not a
ceiling. Meeting them prevents your email from being rejected, but enforcement
is what prevents your domain from being spoofed.
### Does PCI DSS 4.0 require DMARC?
[PCI DSS 4.0 Section 5.4.1](/learn/pci-dss/) requires anti-phishing mechanisms
for any organization that processes, stores, or transmits cardholder data. DMARC
is mentioned in the implementation guidance as an example approach but is not
the sole required method. The standard does not specify a DMARC policy level.
However, many QSAs (Qualified Security Assessors) interpret `p=none` as
insufficient anti-phishing protection because it takes no action when
authentication fails. Moving to `p=quarantine` or `p=reject` strengthens your
compliance posture.
## Conclusion
The "DMARC quarantine/reject policy not enabled" warning means your domain has a
DMARC record at `p=none` — monitoring only, no enforcement. Reports arrive, but
spoofed emails still reach inboxes.
You are not alone: 87.2% of the 5.5 million domains we scanned either have no
DMARC or remain at `p=none`.
The fix follows a clear path:
1. Review your aggregate reports to identify all legitimate senders
2. Verify SPF and DKIM alignment for every third-party service
3. Enforce gradually — `p=quarantine` at `pct=25`, then increase to full
`p=reject`
4. Update your DNS TXT record at your provider (Cloudflare, cPanel, GoDaddy,
Route 53, Cloud DNS, or Namecheap)
5. Handle forwarded email with ARC
Enabling your DMARC quarantine or reject policy is the step that turns
monitoring into protection. Every mandate is heading toward enforcement, and
your domain's security depends on making the move.
Already have a record and want to verify it? Use our DMARC checker to confirm
your policy is live and propagated.