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 — 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 first.

If you are troubleshooting a DMARC failure rather than a policy warning, see our DMARC failed troubleshooting guide.

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:

Here is what the difference looks like in DNS.

Monitoring only — triggers the warning:

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

Enforcement — resolves the warning:

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

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 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. The advisory’s primary mitigation recommendation: upgrade to p=quarantine or p=reject.

Financial impact

Orion S.A., a global chemical manufacturer, lost approximately $60 million in a business email compromise (BEC) attack 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. 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:

Use a SPF checker to verify your SPF record includes all authorized senders, and a 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

Here is the record for the first step:

"v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; adkim=r; aspf=r"

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=.

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.

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

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) 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.

For a deeper look at how ARC works and who supports it, see our ARC protocol guide.

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, Yahoo, and Microsoft 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, 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 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.