DMARC Policy Not Enabled: What It Means and How to Fix It

If you're seeing a warning that says "DMARC quarantine/reject policy not enabled" or "DMARC policy not enabled," you're not alone. This is one of the most common DMARC issues, and it usually means your domain is running in monitoring mode without actual protection.

What This Warning Means

This warning appears when your DMARC record has p=none set as the policy. Here's what that looks like:

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

The p=none policy tells receiving email servers: "Even if an email fails DMARC authentication, deliver it anyway."

In other words, you have a DMARC record, but it's not actually doing anything to protect your domain. Spoofers can still send fake emails that appear to come from your domain, and those emails will be delivered normally.

Security scanners, email deliverability tools, and compliance checks flag this because p=none provides no real protection.

Why You Might Be on p=none

There are a few common reasons domains stay on p=none:

You just set up DMARC: Starting with p=none is actually the recommended approach. It lets you collect reports and identify authentication issues before blocking any email.

You forgot to upgrade: Many organizations set up DMARC in monitoring mode with good intentions but never complete the migration to enforcement. The monitoring phase dragged on, and nobody circled back.

You're worried about breaking email: Moving to p=quarantine or p=reject can block legitimate email if your authentication isn't properly configured. Some organizations stay on p=none out of caution.

Third-party services aren't set up: If you use email marketing platforms, CRM systems, or other services that send email as your domain, each one needs proper SPF and DKIM configuration. Until they're all set up, enforcement is risky.

The Risks of Running p=none Long-Term

Staying on p=none indefinitely creates real problems:

No spoofing protection: Anyone can send emails that appear to come from your domain. Phishers and spammers exploit this regularly.

Reputation damage: If your domain is used for spam or phishing, email providers may start treating all your email as suspicious, even legitimate messages.

Compliance issues: Many security frameworks and industry standards now require DMARC enforcement. Running p=none may fail compliance audits.

False sense of security: Having a DMARC record feels like protection, but p=none doesn't actually block anything.

How to Move from p=none to Enforcement

Moving to enforcement requires preparation. Here's the process:

Step 1: Review Your DMARC Reports

If you've been running p=none with a rua= address configured, you should be receiving aggregate reports. These reports show:

• Who's sending email as your domain
• Whether those emails pass or fail SPF and DKIM
• Which IP addresses and services are involved

Review these reports to identify all legitimate email sources. If you're not receiving reports, or need help reading them, see our guide on DMARC reports.

Step 2: Fix Authentication Issues

For each legitimate email source you identify, verify:

SPF: Is the sending service's IP included in your SPF record? Check your SPF configuration.

DKIM: Is the service signing emails with DKIM, and is the public key published in your DNS? Test your DKIM setup.

Common sources that need configuration:

• Your email provider (Google Workspace, Microsoft 365, etc.)
• Email marketing platforms (Mailchimp, SendGrid, etc.)
• CRM and support systems
• Transactional email services
• Any custom applications that send email

Step 3: Move to Quarantine

Once you've addressed authentication issues, update your DMARC record to p=quarantine:

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

With quarantine, emails that fail DMARC go to spam instead of the inbox. This provides protection while leaving room for recovery if legitimate email has issues.

You can also use the pct= tag to start with partial enforcement:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

This applies quarantine to only 10% of failing emails. Gradually increase the percentage as you confirm things are working.

Step 4: Monitor and Adjust

After moving to quarantine, watch for problems:

• Check your DMARC reports for new failures
• Ask recipients if they're seeing email in spam
• Verify all business-critical email is being delivered

Address any issues that surface before moving on.

Step 5: Move to Reject

Once quarantine is running smoothly, upgrade to p=reject:

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

Now emails that fail DMARC are blocked entirely. Your domain is fully protected against spoofing.

Checklist Before Enabling Enforcement

Before moving from p=none, verify:

• [ ] You've been collecting DMARC reports for at least 2-4 weeks
• [ ] You've identified all legitimate email sources in those reports
• [ ] SPF includes all authorized sending IPs
• [ ] DKIM is configured for all email-sending services
• [ ] You've tested email delivery from each source
• [ ] You have a plan for monitoring after the change

If you're not sure your setup is ready, use DMARC Creator to review your configuration.

Monitor Your DMARC Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.