DMARC quarantine/reject policy not enabled: finishing setup

If you've run a security assessment or reviewed your email authentication settings, you may have come across the warning, "DMARC quarantine/reject policy not enabled."

At first glance, it sounds like something is broken. In reality, it's a sign that you've started implementing DMARC but simply haven't finished the journey.

Many organizations publish a DMARC record with a policy of p=none, which allows them to monitor email authentication without affecting mail delivery. That's an important first step, but it doesn't stop attackers from spoofing your domain. Until your policy advances to quarantine or reject, mailbox providers aren't instructed to take action against emails that fail authentication.

Understanding what this warning means—and how to move toward enforcement safely—can help reduce phishing risk, protect your brand, and build greater trust in every email your organization sends.

How DMARC policies work: A quick refresher

Domain-based Message Authentication, Reporting, and Conformance (DMARC) helps domain owners tell mailbox providers what to do when an email fails authentication. It builds on SPF and DKIM, adding policy enforcement and reporting, so you can both protect your domains and gain visibility into authentication issues.

Every DMARC record includes a policy (p=) that tells receiving mail servers how to handle messages that don't pass authentication.

p=none

This policy tells mailbox providers to take no action on messages that fail DMARC. Instead, they'll continue delivering the email as they normally would while sending authentication reports to the domain owner.

Monitoring mode is useful during deployment because it lets you identify legitimate email sources, uncover authentication gaps, and fix configuration issues before enforcing stricter policies.

p=quarantine

With p=quarantine, mailbox providers are asked to treat failed messages as suspicious. Depending on the provider, those emails may be delivered to a spam or junk folder instead of the recipient's inbox.

This policy offers meaningful protection while still giving you an opportunity to monitor the impact before fully blocking failed messages.

p=reject

A p=reject policy provides the strongest level of protection. Mailbox providers are instructed to reject emails that fail DMARC, preventing spoofed messages from reaching recipients altogether.

For organizations that have properly authenticated all legitimate email sources, a reject policy is typically the long-term goal.

What does "DMARC quarantine/reject policy not enabled" mean? 

This warning typically means your domain already has a DMARC record, but it's still configured with p=none rather than p=quarantine or p=reject. 

In other words, you're collecting valuable authentication reports, but mailbox providers haven't been instructed to quarantine or reject messages that fail DMARC. As a result, attackers still may be able to impersonate your domain if their messages aren't stopped by other security controls. 

Think of it as installing a security camera without locking the front door—you're gaining visibility into what's happening, but you're not yet taking advantage of DMARC's strongest protections. 

Why so many organizations stay at p=none 

If enforcement offers better protection, why don't more organizations enable it? 

The biggest challenge isn't publishing a DMARC record. It’s making sure every legitimate email source is ready for enforcement. 

Most organizations send email from far more systems than they realize—marketing automation platforms, customer support tools, HR software, CRM systems, billing platforms, collaboration tools, and other third-party services may all send email using your domain. If even one of those systems isn't properly authenticated, moving to enforcement too quickly could disrupt legitimate communications. 

Many security and IT teams also inherit years of legacy infrastructure with limited documentation. Identifying every sender, validating SPF and DKIM alignment, and coordinating changes across multiple departments takes time. 

That's why p=none exists. It gives you the visibility you need to understand your full email ecosystem before enforcing stricter policies. 

Why p=none is useful but not enough alone

Running in monitoring mode is a smart way to begin a DMARC deployment. It allows you to: 

• Discover legitimate email senders across your organization 

• Identify authentication failures 

• Validate SPF and DKIM alignment 

• Review DMARC reports without affecting email delivery 

The problem is when you stop there. A domain that remains at p=none for months (or even years) is still vulnerable to spoofing attacks because mailbox providers haven't been instructed to block unauthenticated messages. Monitoring provides insight, but enforcement is what delivers meaningful protection. 

Risks of leaving DMARC enforcement disabled 

Remaining in DMARC monitoring mode indefinitely can expose your organization to several security and business risks: 

Domain spoofing 

Attackers can continue sending emails that appear to come from your domain, increasing the likelihood of successful phishing campaigns. 

Phishing and business email compromise 

Cybercriminals frequently impersonate trusted organizations to steal credentials, distribute malware, or convince employees and customers to transfer money or sensitive information. Strong DMARC enforcement makes these attacks significantly more difficult to carry out using your domain. 

Damage to brand trust 

Customers expect legitimate emails from your organization to be trustworthy. If they receive convincing spoofed messages, they may begin questioning future communications—even authentic ones. 

Rebuilding trust after an impersonation campaign can take far longer than putting protections in place to prevent a breach in the first place. 

Deliverability challenges 

Mailbox providers increasingly consider authentication when evaluating sender reputation. While DMARC alone doesn't guarantee inbox placement, maintaining strong authentication practices helps support a healthier sending reputation and greater confidence in your email program. 

More work for security and IT teams 

Without enforcement, security teams often spend additional time investigating phishing reports, responding to user concerns, and tracking down spoofing incidents that could have been prevented. 

How to check your current DMARC policy 

You can determine your current policy by reviewing your domain's DMARC record. 

Look for a DNS TXT record published at: 

_dmarc.example.com 

A typical record might look like this: 

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Pay particular attention to: 

• Version (v=DMARC1) to confirm you're using the current DMARC specification 

• Policy (p=) to see whether you're using none, quarantine, or reject 

• Reporting addresses (rua and, where used, ruf) that receive DMARC reports 

• Alignment settings (adkim and aspf) if you've configured strict or relaxed alignment 

If your policy is still set to p=none, the warning simply indicates that enforcement hasn't been enabled yet. 

What to do before you enable DMARC enforcement 

Before changing your DMARC policy, make sure you’ve completed the following: 

• Identified every legitimate system that sends email using your domain 

• Configured SPF and/or DKIM correctly for each sender 

• Reviewed DMARC reports over time to identify authentication failures 

• Coordinated with internal teams that manage business applications 

• Tested critical email workflows before making policy changes 

Completing these steps can help reduce the risk of disrupting legitimate email when enforcement begins. 

How to move from p=none to quarantine or reject 

For most organizations, the safest approach is a gradual rollout rather than an immediate switch to full enforcement. 

1. Inventory every legitimate sender 

Create a complete list of all systems that send email on behalf of your domain, including third-party services and internally managed applications. 

2. Fix authentication issues 

Ensure every sender is properly configured with SPF, DKIM, or both—and verify alignment with your DMARC policy. 

 3. Review DMARC reports 

Analyze authentication reports to identify unknown senders, configuration issues, and recurring failures before tightening your policy. 

 4. Begin with partial enforcement 

Many organizations move first to p=quarantine to limit the impact while monitoring results. 

5. Increase enforcement over time 

As authentication improves and confidence grows, gradually increase the percentage of mail subject to enforcement. 

6. Move to p=reject 

Once you're confident that legitimate email is authenticating successfully, transition to p=reject for the strongest protection against domain spoofing. 

Common mistakes when enabling DMARC enforcement 

Even well-planned deployments can run into problems. Some of the most common include: 

• Overlooking third-party email services that send on your behalf 

• Missing or incorrect SPF include statements 

• Forgetting to enable DKIM signing for cloud applications 

• Moving directly to p=reject before validating all legitimate senders 

• Publishing a policy but failing to review DMARC reports on an ongoing basis 

Taking a phased approach helps minimize these issues while improving confidence in your deployment. 

How DigiCert and Valimail help organizations reach DMARC enforcement 

Moving from p=none to quarantine or reject is more than a technical configuration change. To be successful, you need confidence that every legitimate email source is accounted for and properly authenticated. 

That's where DigiCert and Valimail work together. Now part of DigiCert, Valimail gives you visibility to identify legitimate senders, monitor authentication results, uncover configuration issues, and safely progress toward DMARC enforcement. Instead of relying on manual audits and spreadsheets, you get a clearer picture of your email ecosystem and gain the confidence to move from monitoring to enforcement. Combined with DigiCert's broader digital trust platform, you can strengthen the identities behind digital communications while protecting customers, employees, and partners from spoofing and impersonation attacks. 

The result goes past a stronger DMARC policy. It's a more resilient approach to digital trust—one that helps receiving systems verify authorized use of your domain.