What is a DMARC Policy? None, Quarantine, and Reject

Email fraud is one of the most persistent and damaging cyber threats organizations face today. According to the Verizon Data Breach Investigations Report, phishing remains a leading cause of data breaches, and most attacks start with a spoofed email domain.

A DMARC policy is your first line of defense. Defined under RFC 7489, DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that tells receiving mail servers what to do when an email fails authentication checks. Without it, attackers can freely impersonate your domain to target your customers, employees, and partners.

This guide breaks down what a DMARC policy is, the three policy options available, how to implement and enforce one correctly, and how to avoid the common pitfalls that keep most companies unprotected.

What is a DMARC Policy?

A DMARC policy is a set of instructions published in your DNS that tells receiving mail servers how to handle emails that fail DMARC authentication. In plain terms, it is the enforcement layer of the DMARC protocol and decides the fate of every unauthenticated message that claims to come from your domain.

Without a DMARC policy, your email domain is essentially an open door. Cybercriminals can send fraudulent emails that appear to come from your organization, targeting your customers and employees with phishing attacks.

How Does a DMARC Policy Work?

A DMARC policy works by giving receiving mail servers a clear rulebook to follow whenever an email fails DMARC authentication. Here is exactly how that process plays out from send to inbox.

The authentication flow, step by step:

1. An email sender sends a message claiming to be from your domain.
2. The receiving mail server runs SPF and DKIM authentication checks on the message.
3. If the message passes either check and the domain aligns with the From header, it passes DMARC authentication and lands in the recipient’s inbox.
4. If the message fails DMARC checks, the server reads your DMARC record from your DNS records.
5. Based on your published DMARC policy, the server delivers, quarantines, or rejects the unauthenticated message.
6. The receiving server sends DMARC aggregate reports back to the address specified in your DMARC record.

DMARC also checks that the authenticated domain matches the domain in the From header. This is called identifier alignment, and it is what closes the loophole that lets attackers use a lookalike domain to slip past basic email authentication checks.

Without alignment, a bad actor could pass SPF on one domain while spoofing a completely different one in the From address your recipients actually see.

Before you configure DMARC

You need SPF and/or DKIM deployed and active for at least 48 hours before setting up your DMARC record. If those are not in place, your DMARC policy has nothing to validate against.

It is also worth understanding how DNS works before you start publishing records, as misconfigured DNS TXT records are one of the most common causes of DMARC failures.

Suggested read: Email Phishing And DMARC Statistics: 2026 Security Trends

The 3 DMARC Policy Options

There are three policy options: p=none, p=quarantine, and p=reject. Each represents a different level of DMARC enforcement. Choosing the right one at the right time is what separates organizations that are genuinely protected from those that just think they are.

1. p=none

p=none is the most relaxed DMARC policy option. It tells receiving servers to take no action on emails that fail DMARC authentication. Every message, whether it passes or fails, is delivered normally to the recipient’s inbox. Nothing is blocked, nothing is flagged as suspicious.

Its only job is to generate DMARC aggregate reports, so you can see who is sending email on behalf of your domain, how many messages are passing or failing authentication, and which IP addresses may be spoofing your domain.

p=none provides zero protection against email spoofing, as:

• Unauthorized emails are still delivered
• Fraudulent messages still reach inboxes
• Attackers can use your domain freely

It is the correct starting point, but it is not a destination. Most companies never move past p=none, leaving themselves completely unprotected. If your DMARC policy is not enabled beyond monitoring mode, your domain is still wide open.

2. p=quarantine

p=quarantine is the transitional enforcement policy. It instructs the receiving mail server to treat messages that fail authentication with suspicion and redirect them to the recipient’s spam folder or junk folder instead of the inbox.

Emails that pass DMARC authentication are completely unaffected. Only unauthenticated messages get treated as suspicious and moved away from the inbox.

The quarantine policy gives you active enforcement while still providing a safety net. If a legitimate email source was misconfigured and starts failing DMARC checks, it lands in spam rather than being rejected outright. You can catch it, fix the issue, and avoid disrupting your email flow.

You should only move to p=quarantine after thoroughly analyzing your DMARC reports and confirming that all known legitimate senders are properly authenticated.

3. p=reject

p=reject is the strictest DMARC policy and the gold standard for email security. It tells receiving servers to reject unauthenticated messages entirely. Fraudulent emails never reach the inbox, the spam folder, or anywhere else.

Full p=reject stops domain spoofing attacks in their tracks, protects your brand reputation, and signals to mailbox providers that your domain is trustworthy, which can improve inbox placement for your legitimate mail.

However, p=reject is unforgiving. Any legitimate email source that is not properly authenticated before you switch to this policy will have those emails rejected. You must ensure all legitimate senders are whitelisted and passing DMARC authentication before making this move.

Other DMARC Policy Tags You Should Know

The p= tag gets most of the attention, but a DMARC record contains several other policy settings that directly affect how your policy behaves. Ignoring these is one of the reasons organizations end up with gaps in their protection even after publishing a DMARC record.

sp= (Subdomain Policy)

The sp= tag controls how your DMARC policy applies to subdomains. If you have a policy set on your root domain but leave sp= out, your subdomains inherit the root domain policy by default. This is fine in most cases, but if you want to apply a different level of enforcement to subdomains, you need to set this explicitly.

For example, if your root domain is at p=reject but a subdomain is not yet ready for full enforcement, you can set sp=quarantine to apply a softer policy there.

pct= (Percentage Tag)

The pct= tag tells receiving servers what percentage of failing messages your policy should be applied to. It defaults to 100 if omitted. This tag is most useful during the transition from p=quarantine to p=reject.

Instead of flipping the switch for all traffic at once, you can start at pct=10 or pct=25 and scale up gradually while monitoring your reports.

adkim= and aspf= (Alignment Modes)

These two tags control how strictly DMARC checks domain alignment for DKIM and SPF respectively. The two options are r (relaxed) and s (strict). Relaxed alignment allows a subdomain match, meaning mail.yourdomain.com would pass alignment for yourdomain.com.

Strict alignment requires an exact match. Most organizations should use relaxed alignment, which is the default when these tags are omitted.

fo= (Failure Reporting Options)

The fo= tag controls when DMARC forensic reports are generated. The default value is 0, which means a report is sent only when both SPF and DKIM fail. Setting fo=1 sends a report whenever either SPF or DKIM fails.

Setting fo=s or fo=d generates reports specific to SPF or DKIM failures respectively. For deeper troubleshooting visibility, fo=1 is the most useful setting.

DMARC Policy Comparison: p=none vs p=quarantine vs p=reject

Choosing between the three DMARC policy options is easier when you can see them side by side. Use this as a quick reference when deciding which policy fits your current stage of DMARC implementation.

Most organizations should treat this as a progression: start at p=none, analyze your DMARC reports, fix misconfigurations, move to p=quarantine, then graduate to p=reject once all legitimate email sources are verified.

How to Move from p=none to p=reject

Moving from p=none to full DMARC policy enforcement is a phased process that requires careful analysis of your reports at every stage. Rushing this transition is the most common cause of legitimate emails being blocked.

Step 1: Publish a p=none record and start collecting data

Start by publishing a DMARC record with p=none and a valid rua= address. This puts you in monitoring mode.

All email messages continue to flow normally, but you begin receiving DMARC aggregate reports showing who is sending from your domain, which messages are passing or failing authentication, and which IP addresses are involved.

Step 2: Analyze your DMARC aggregate reports

Raw aggregate reports arrive as XML files and are not easy to read manually. Use a DMARC report analyzer to parse them into readable dashboards.

Look for all legitimate email sources sending from your domain, IP addresses that are failing DMARC checks unexpectedly, SPF and DKIM alignment failures for known legitimate senders, and unauthorized senders attempting to spoof your domain.

Monitor these DMARC authentication results for at least two to four weeks before making any policy changes. PowerDMARC’s aggregate report views make it easy to track these trends over time.

Step 3: Fix SPF and DKIM misalignments

For every legitimate mail source that is failing DMARC checks, investigate and fix the root cause. Common fixes include adding missing IP addresses to your SPF record, setting up DKIM signing for third-party email services, and correcting configuration errors in forwarded email flows.

Regular audits of DMARC reports help you catch these issues before they become delivery problems.

Step 4: Whitelist all legitimate senders

Before moving to any enforcement policy, every legitimate email source must be passing DMARC authentication consistently. Missing even one sender at this stage can result in those emails being rejected once you enforce p=reject.

Step 5: Move to p=quarantine at 10 to 25 percent

Use the pct= tag to apply your new policy to a percentage of failing messages first. Start with p=quarantine at pct=25 and monitor your reports carefully.

If legitimate emails start landing in the spam folder, you have a sender that still needs to be fixed before you proceed.

Step 6: Scale p=quarantine to 100 percent

Once you are confident that failing messages at 25 percent are genuinely unauthorized, scale pct= up to 100 and continue monitoring.

Step 7: Move to p=reject

Once p=quarantine is running cleanly at 100 percent with no legitimate mail being caught, you are ready to move to full enforcement. All unauthenticated messages will now be blocked before delivery.

PowerDMARC’s hosted DMARC service can manage this entire transition for you, automating policy updates without requiring manual DNS changes at every step.

DMARC Reporting: Aggregate Reports vs. Forensic Reports

DMARC reports are how you turn your policy into an active intelligence tool. Without reading them, you have no visibility into who is using your domain, what is failing, or whether your enforcement is working.

There are two report types, and they serve very different purposes.

Common DMARC Policy Errors and How to Fix Them

DMARC implementation can be complex, and small misconfigurations tend to have outsized consequences. Here are the most common errors and how to resolve them quickly.

Missing or malformed DMARC TXT record

Publishing under the wrong hostname, missing the v=DMARC1 tag, or creating duplicate records will cause receiving servers to ignore your policy entirely. Common hostname mistakes include using dmarc.yourdomain.com instead of _dmarc.yourdomain.com.

Fix: Validate your record with PowerDMARC’s DMARC Record Checker before and after any DNS change.

SPF and DKIM not aligned

Your SPF and DKIM can both pass while your messages still fail DMARC if the authenticated domain does not align with the From header. This is one of the most commonly misunderstood failure points in DMARC implementation.

Fix: Check your adkim= and aspf= alignment settings in your DMARC record. Relaxed alignment is the right default for most organizations and allows subdomain matches without requiring an exact domain match.

Legitimate emails failing after moving to enforcement

This almost always means a legitimate sender was missed during the monitoring phase and is now being caught by your stricter policy.

Fix: Drop back to p=quarantine with a low pct= value while you investigate. Find the failing sender in your aggregate reports, correct their SPF or DKIM configuration, confirm they are passing consistently, then scale back up.

Exceeding SPF DNS lookup limits

SPF records are capped at 10 DNS lookups. Send through enough third-party platforms and you will breach this limit, causing SPF to fail and cascading directly into DMARC failures for legitimate mail.

Fix: Audit your SPF record and use automated SPF management to flatten your record and stay within lookup limits.

No reporting address configured

Without a valid rua= address, you have a policy deployed but no visibility into whether it is working, what is failing, or whether spoofing activity is happening on your domain.

Fix: Always include a valid rua= address from day one. If you manage multiple domains, use a centralized reporting platform to consolidate your DMARC aggregate reports in one place.

Protect Your Domain With PowerDMARC

A DMARC policy is only as effective as the implementation behind it. The technical steps are straightforward. But the ongoing work of analyzing reports, fixing misconfigurations, whitelisting legitimate senders, and safely moving to enforcement is where most organizations fall short.

PowerDMARC is built to make that entire process manageable. From generating your first DMARC record to reaching full p=reject enforcement, the platform handles every stage. It includes hosted policy management, automated reporting dashboards, real-time threat alerts, and SPF and DKIM monitoring across all your domains.

Organizations that use PowerDMARC move from p=none to p=reject faster, with fewer disruptions to legitimate email, and with complete visibility into every sender using their domain.

Your domain is your brand. Do not leave it unprotected.

Book a demo to take your first step toward full email authentication and enforcement today.

FAQs

1. What is the default DMARC policy?

There is no default DMARC policy. If no DMARC record exists, receiving servers will not perform DMARC checks. When you first create a DMARC record, it’s recommended to start with p=none for monitoring purposes.

2. Can DMARC policies affect email deliverability?

Yes, DMARC policies can improve deliverability by 10-15% when properly implemented, as authenticated domains are trusted more by email providers. However, incorrect implementation can cause legitimate emails to be quarantined or rejected.

3. What’s the difference between SPF, DKIM, and DMARC?

SPF verifies the sending server is authorized, DKIM ensures message integrity through cryptographic signatures, while DMARC provides policy enforcement and reporting by building on both SPF and DKIM results.

4. How long should I stay on p=none before moving to stricter policies?

Stay on p=none for at least 30 days to collect comprehensive DMARC reports. For complex organizations with multiple email sources, consider 60-90 days to ensure all legitimate senders are identified and properly authenticated.

5. Which DMARC policy is best?

p=reject is the strongest policy, as it blocks all unauthorized email from being delivered. That said, jumping straight to p=reject is risky. The recommended approach is to start at p=none to monitor your email traffic, move to p=quarantine once you have identified all your legitimate senders, and only enforce p=reject when you are confident everything legitimate is properly authenticated.

6. How do I fix my DMARC policy?

You can update your DMARC policy by editing your DMARC TXT record directly in your DNS management console and changing the p= tag value. If you want a simpler option, PowerDMARC’s Hosted DMARC lets you update your policy with a single click.

7. Which DMARC policy would you use to reject emails that fail DMARC checks?

Use p=reject. This instructs receiving mail servers to block any message that fails DMARC authentication outright. The email will not reach the recipient’s inbox or spam folder. If you want failing emails to land in spam rather than be blocked entirely, use p=quarantine instead.

• About
• Latest Posts

Maitham Al Lawati

Cybersecurity Expert, CEO at PowerDMARC

Maitham is a tech entrepreneur, cybersecurity expert, CEO and Founder of PowerDMARC with 15+ years of industry experience. Maitham holds a Global MBA from the University of Manchester and various professional certifications including CISSP, CISM, CRISC, and ISC2 CCSP.

Latest posts by Maitham Al Lawati (see all)

• Email Phishing and DMARC Statistics: 2026 Email Security Trends - January 6, 2026
• How to Fix “No SPF record found” in 2026 - January 3, 2026
• SPF Permerror: How to Fix Too Many DNS Lookups - December 24, 2025