How to Implement a DMARC Policy for Enhanced Email Security

Let’s be honest: email authentication is complicated. If you’ve landed on this guide, you’re probably staring at a DMARC record wondering what all those tags mean, or you’ve been told your “DMARC policy not enabled” and you’re not sure what that actually means for your organization.

Here’s the reality. Setting up a DMARC policy isn’t a five-minute task you check off and forget. It’s a process that requires understanding your email ecosystem, coordinating with vendors, and making deliberate decisions about how aggressively you want to protect your domain. But it’s absolutely worth doing, and this guide will walk you through it step by step.

Understanding DMARC Policy

What is DMARC Policy?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The “policy” part is the instruction you publish in DNS that tells receiving mail servers what to do when an email claiming to be from your domain fails authentication checks.

Think of it this way: SPF and DKIM are the authentication mechanisms that verify whether an email is legitimate. DMARC is the enforcement layer that says, “If authentication fails, here’s what I want you to do about it.”

Your DMARC policy lives in a DNS TXT record at _dmarc.yourdomain.com. A basic record looks like this:

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

The p= tag is your policy. That’s what we’re here to talk about.

Importance of DMARC in Email Security

Without DMARC, anyone can send email that appears to come from your domain. Phishing attacks, business email compromise, and brand impersonation all exploit this gap. Your customers, partners, and employees receive fraudulent emails that look legitimate because there’s no mechanism telling mail servers to reject them.

DMARC enforcement changes that equation. When you reach p=reject, you’re telling every receiving mail server on the internet: “If an email claims to be from my domain and it doesn’t pass authentication, don’t deliver it. Period.”

The numbers tell the story. Countries that have mandated DMARC for government domains have seen phishing success rates drop from 69% to 14%. That’s not a minor improvement. That’s a fundamental shift in how effective email-based attacks can be against your organization.

Beyond security, DMARC is increasingly a deliverability requirement. Google and Yahoo now require DMARC for bulk senders. PCI DSS 4.0 mandates it for payment processors. If you’re sending significant email volume, DMARC isn’t optional anymore. See our guide on what counts as a bulk sender to understand the thresholds.

DMARC Policy Options

You have three choices for your DMARC policy. Each represents a different level of protection and a different level of risk if you haven’t properly configured your email authentication.

DMARC Monitoring Policy (p=none)

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

The p=none policy is monitoring mode. You’re telling receivers: “Check authentication, send me reports about the results, but don’t take any action on failures.”

This is where every organization should start. Not because it’s safe, but because it’s necessary. You need visibility into who’s sending email as your domain before you can make enforcement decisions.

Here’s what p=none gives you:

• Aggregate reports showing authentication results for all email claiming to be from your domain
• Visibility into legitimate senders you may have forgotten about (that marketing platform from three years ago, the CRM your sales team set up)
• Time to fix authentication issues before they cause delivery problems

What p=none doesn’t do is protect you. Spoofed emails still get delivered. You’re just watching it happen with better data.

DMARC Quarantine Policy (p=quarantine)

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]

The p=quarantine policy tells receivers to treat failing emails as suspicious. In practice, this usually means sending them to spam or junk folders rather than the inbox.

Quarantine is the intermediate step. You’re saying: “I’m confident enough in my authentication setup to start taking action, but I want a safety net in case something’s misconfigured.”

Some organizations stay at quarantine permanently. Others use it as a stepping stone to full enforcement. The right choice depends on your risk tolerance and how mission-critical your email deliverability is.

The pct= tag lets you apply the policy to only a percentage of failing messages. Setting pct=25 means quarantine only 25% of failures while the rest are treated as p=none. This gives you a way to test enforcement gradually.

DMARC Reject Policy (p=reject)

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

The p=reject policy is full enforcement. Emails that fail DMARC authentication don’t get delivered at all. They’re blocked before they reach any folder.

This is the destination. This is what actually stops spoofing. Everything before this is just preparation.

Reaching p=reject requires confidence that:

1. All legitimate email sources are properly authenticated
2. Your SPF record includes every service that sends as your domain
3. DKIM is configured for all sending sources
4. You’ve reviewed enough report data to know there aren’t surprises waiting

The fear most organizations have is blocking their own legitimate email. That fear is valid. It’s also why the monitoring and quarantine phases exist. If you do the work to get your authentication right, the move to reject is straightforward.

Steps to Implement DMARC Policy

Setting Up Your DMARC Record

Before you create a DMARC record, you need SPF and DKIM in place. DMARC builds on these protocols. If you haven’t configured them yet, start there.

You can check your current setup with our email authentication checker to see what’s already in place.

Step 1: Create your initial DMARC record

Start with monitoring mode:

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

The rua tag specifies where aggregate reports should be sent. Use an email address you actually monitor, or better yet, use a DMARC reporting service that can parse and visualize the data.

Step 2: Add the DNS record

Create a TXT record with:

• Host/Name: _dmarc
• Value: Your DMARC record string
• TTL: 3600 (1 hour) is reasonable

Step 3: Wait for reports

DMARC reports typically arrive within 24-48 hours, though some reporters take longer. You need at least 2-4 weeks of data before making policy decisions.

Step 4: Analyze and fix

Review your reports to identify:

• Legitimate senders failing authentication (fix these)
• Unknown senders (investigate whether they’re legitimate or spoofing)
• Spoofing attempts (these will be blocked once you enforce)

Step 5: Progress to enforcement

Once your pass rates are consistently above 95% and you’ve authorized all legitimate sources, you’re ready to move to quarantine and eventually reject.

Use our DMARC checker to verify your record is properly configured at each step.

Using a DMARC Policy Generator

Writing DMARC records by hand works, but it’s easy to make syntax errors that break the entire record. A DMARC policy generator helps you create valid records with the right tags for your situation.

A good generator should:

• Validate your syntax before you publish
• Explain what each tag does
• Warn you about common misconfigurations
• Support advanced options like forensic reporting (ruf), subdomain policies (sp), and alignment modes

The most important thing isn’t which generator you use. It’s that you understand what the generated record does before you publish it to DNS.

DMARC Alignment and Its Significance

DMARC alignment is the concept that trips up most people new to email authentication. Here’s what it means in plain terms.

When an email arrives, there are multiple “from” addresses involved:

• The Header From (what recipients see in their email client)
• The Envelope From (used by SPF, often called Return-Path or Mail From)
• The DKIM domain (the domain in the d= tag of the DKIM signature)

DMARC requires alignment between the Header From domain and at least one of the authenticated domains (SPF or DKIM). Without alignment, authentication can pass but DMARC still fails.

Relaxed alignment (the default) requires the organizational domains to match. So mail.example.com aligns with example.com.

Strict alignment requires exact domain matches. mail.example.com would not align with example.com.

Most organizations use relaxed alignment. Strict alignment is more secure but breaks many legitimate email flows, especially with third-party senders.

You can check alignment in your DMARC record with:

• adkim=r (relaxed DKIM alignment, the default)
• adkim=s (strict DKIM alignment)
• aspf=r (relaxed SPF alignment, the default)
• aspf=s (strict SPF alignment)

If you’re seeing DMARC failures despite SPF and DKIM passing, alignment is usually the culprit. Use our SPF checker and DKIM checker to verify your records are set up correctly.

DMARC Reporting and Monitoring

Understanding DMARC Reports

DMARC generates two types of reports:

Aggregate reports (rua) are XML files summarizing authentication results over a time period (usually 24 hours). They show:

• Sending IP addresses
• Message counts
• SPF and DKIM results
• Policy applied
• Disposition (none, quarantine, reject)

These reports are essential for understanding your email ecosystem. They’re also nearly unreadable in raw XML format. You’ll want a tool that parses and visualizes them. Read our complete guide to understanding DMARC reports for detailed analysis tips.

Forensic reports (ruf) contain details about individual failing messages. They’re useful for investigating specific issues but raise privacy concerns since they may include message content. Many large receivers don’t send forensic reports at all.

Start with aggregate reports only:

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

Add forensic reports later if you need them:

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

DMARC Dashboard Overview

Raw DMARC reports are XML files that look like this:

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>127</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

A proper DMARC dashboard transforms this data into something actionable:

• Pass rates over time showing your authentication health
• Source identification revealing who’s sending as your domain
• Failure analysis breaking down why messages are failing
• Trend monitoring alerting you to sudden changes

The goal of a dashboard isn’t just visibility. It’s answering the question: “Am I ready to move to a stricter policy?” If your pass rate is 97% but 3% of failures represent thousands of legitimate emails from a vendor you haven’t configured, you’re not ready.

Troubleshooting Common DMARC Issues

554 5.7.5 Permanent Error Evaluating DMARC Policy

The 554 5.7.5 permanent error evaluating DMARC policy message means the receiving server tried to check your DMARC record and encountered a problem it couldn’t recover from.

Common causes:

DNS issues

• Your DMARC record doesn’t exist or hasn’t propagated
• Multiple DMARC records (you should only have one)
• DNS server timeouts

Syntax errors in your DMARC record

• Missing required tags (v=DMARC1 must be first)
• Invalid characters or formatting
• Typos in tag names (p=quaratine instead of p=quarantine)

Cascading failures

• SPF record with syntax errors causing permerror
• DKIM signature validation failures due to key rotation issues

To diagnose, start by checking your DMARC record with our DMARC checker. Then verify your SPF and DKIM records are valid.

The 5.7.5 permanent error evaluating DMARC policy variant without the 554 prefix indicates the same class of problem. The prefix just indicates it occurred during the SMTP conversation rather than later processing.

DMARC Policy Not Enabled Errors

Seeing “DMARC policy not enabled” or “DMARC quarantine/reject policy not enabled” usually means one of two things:

You don’t have a DMARC record at all

Check _dmarc.yourdomain.com for a TXT record. If nothing’s there, you need to create one.

Your policy is set to p=none

Technically, you have DMARC configured. But p=none is monitoring only. It doesn’t provide protection. Security scanners and compliance tools flag this because you’re not actually enforcing authentication.

If you see “DMARC quarantine reject policy not enabled,” this specifically means you’re at p=none and haven’t moved to an enforcing policy. The fix is to progress through the implementation steps we covered earlier.

The related message “DMARC quarantine/reject policy not enabled” (with the slash) means the same thing. Different tools phrase it differently, but the underlying issue is identical.

Best Practices for DMARC Enforcement

Regularly Checking DMARC Policy

DMARC isn’t set-and-forget. Your email ecosystem changes over time:

• New vendors start sending as your domain
• Marketing tools get added or removed
• Acquisitions bring new domains and sending infrastructure
• Certificate rotations affect DKIM

Build a habit of reviewing your DMARC reports at least monthly. Watch for:

• New sending sources you don’t recognize
• Declining pass rates
• Spikes in message volume from unknown IPs
• Changes in which receivers are sending you reports

Automate what you can. Alerts for sudden drops in pass rate or new high-volume senders catch problems before they become emergencies.

Use our tools to periodically verify your DNS records haven’t drifted from their intended configuration.

Ensuring DMARC Quarantine/Reject Policy is Enabled

Moving to enforcement requires confidence, and confidence comes from data. Here’s the practical progression:

Week 1-4: Monitoring (p=none)

• Collect reports
• Identify all legitimate senders
• Document unknown sources for investigation

Week 5-8: Fix authentication issues

• Configure SPF includes for all legitimate senders
• Set up DKIM for services that support it
• Work with vendors who are failing authentication

Week 9-10: Gradual enforcement (p=quarantine with pct=25)

• Start quarantining a percentage of failures
• Monitor for delivery complaints
• Verify legitimate mail is still flowing

Week 11-12: Increase enforcement (p=quarantine with pct=100)

• Full quarantine policy
• Continue monitoring
• Address any remaining issues

Week 13+: Full enforcement (p=reject)

• Move to reject when quarantine shows no legitimate failures
• Maintain monitoring for ongoing protection

The timeline varies based on your organization’s complexity. A small business with one email provider might move to enforcement in two weeks. An enterprise with dozens of sending sources across multiple business units might take six months. The important thing is making progress, not hitting arbitrary deadlines.

Conclusion and Next Steps

Implementing a DMARC policy is a journey from visibility to protection. You start by understanding who’s sending email as your domain, progress through fixing authentication issues, and ultimately reach enforcement where spoofed emails get blocked entirely.

The path isn’t always smooth. You’ll discover forgotten vendors, wrestle with alignment issues, and spend more time than you’d like waiting for DNS propagation. But each step brings you closer to actually protecting your domain rather than just hoping nobody abuses it.

Here’s where to go from here:

1. Check your current state with our email authentication checker
2. Verify your records using our DMARC, SPF, and DKIM tools
3. Start monitoring if you haven’t already with at least a p=none policy
4. Review your reports to understand your email ecosystem
5. Progress to enforcement when your data shows you’re ready—see our enforcement guide for detailed steps

The destination is enforcement. The transformation is knowing you’ve actually done something about email security rather than just talking about it. You can get there. It just takes the willingness to work through the complexity rather than pretending it doesn’t exist.