DMARC p=none vs p=quarantine vs p=reject: Understanding Your Enforcement Options

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a critical email authentication protocol that helps protect your domain from impersonation and phishing attacks. While the core idea is straightforward—validate email senders—the enforcement policies can be a source of confusion. The p tag in your DMARC record dictates how receiving mail servers should handle emails that fail DMARC authentication.

Understanding the nuances of p=none, p=quarantine, and p=reject is essential for a successful DMARC deployment. Choosing the right policy at the right time can mean the difference between robust email security and inadvertently blocking your own legitimate mail.

Understanding DMARC Policy (p)

At its heart, DMARC builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). For an email to pass DMARC, it must pass either SPF or DKIM authentication, and the domain used for SPF/DKIM must "align" with the From: header domain that the recipient sees.

The p tag in your DMARC record specifies the policy for emails that fail this alignment check. It tells receiving mail servers what to do with messages that claim to be from your domain but don't properly authenticate. Alongside p, you'll often see rua (reporting URI for aggregate reports) and ruf (reporting URI for forensic reports), which are crucial for monitoring and understanding DMARC outcomes.

Here's what a basic DMARC record looks like in your DNS:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc_reports@yourdomain.com;"

Let's break down the three primary policy options.

p=none: The Monitoring Policy

When you set p=none, you're essentially telling receiving mail servers: "Hey, if an email claiming to be from my domain fails DMARC, just deliver it as usual. But please, send me reports about it."

  • What it does: No enforcement action is taken. Emails that fail DMARC authentication are still delivered to the recipient's inbox (or whatever their receiving server's default policy is for unauthenticated mail).
  • Why use it: This is the starting point for any DMARC deployment. It allows you to gather vital intelligence about your email ecosystem without risking legitimate emails being blocked. You'll receive aggregate reports that show you who is sending email on behalf of your domain, whether SPF and DKIM are passing, and if alignment is happening correctly. This is how you identify legitimate third-party senders (like marketing platforms or transactional email services) that might not yet be properly configured for SPF/DKIM alignment.
  • Pitfalls: While crucial for initial deployment, p=none offers no protection against spoofing or phishing attacks. If you leave your policy at p=none indefinitely, your domain remains vulnerable. It's a monitoring phase, not an end state.

Example DMARC Record:

v=DMARC1; p=none; rua=mailto:dmarc_aggregate@yourdomain.com;

In this scenario, if an attacker sends an email spoofing yourdomain.com without proper SPF/DKIM, it will still likely reach the inbox. However, you'll see a record of this failed attempt in your DMARC aggregate reports, which is invaluable for identifying these threats.

p=quarantine: The Soft Enforcement Policy

With p=quarantine, you're stepping up your enforcement. You're telling receiving servers: "If an email from my domain fails DMARC, please treat it with suspicion. Don't outright reject it, but don't deliver it normally either."

  • What it does: Receiving servers are instructed to place non-aligned emails into the recipient's spam/junk folder, flag them as suspicious, or hold them for moderation. The exact action depends on the receiving server's interpretation, but the intent is to prevent the email from reaching the primary inbox.
  • Why use it: This is typically the next step after you've thoroughly analyzed your p=none reports and feel confident that most of your legitimate email sources are DMARC-aligned. It provides a level of protection against spoofing by moving suspicious emails out of sight, while still offering a safety net: if a legitimate email somehow fails, it might still be recoverable from the spam folder. It's a good intermediate step before full rejection.
  • Pitfalls: p=quarantine is not foolproof. Some recipients might check their spam folders, and sophisticated phishing attacks can still be effective if the email lands there. More critically, if you haven't identified all legitimate sending sources and properly configured their SPF/DKIM, your own legitimate emails could end up in spam, leading to missed communications and support headaches. It requires continued, diligent monitoring of DMARC reports.

Example DMARC Record:

v=DMARC1; p=quarantine; rua=mailto:dmarc_aggregate@yourdomain.com;

If you're using a third-party service like Mailchimp to send newsletters and their DKIM signing isn't correctly set up for your domain, emails sent via Mailchimp will fail DMARC alignment. With p=quarantine, these legitimate newsletters would likely land in your subscribers' spam folders, reducing engagement and potentially harming your sender reputation. You'd need to configure Mailchimp's DKIM records (typically CNAMEs provided by Mailchimp) in your DNS to ensure alignment.

p=reject: The Strict Enforcement Policy

This is the strongest DMARC policy. When you set p=reject, you're making a definitive statement: "If an email claiming to be from my domain fails DMARC, do not deliver it. Reject it outright."

  • What it does: Receiving servers are instructed to bounce or drop non-aligned emails. They will not reach the recipient's inbox or spam folder. They are simply refused at the gateway.
  • Why use it: p=reject offers the highest level of protection against email spoofing and phishing. It ensures that only emails that properly authenticate and align with your DMARC policy are delivered, drastically reducing the chances of your domain being used for malicious purposes. This is the ultimate goal for DMARC deployment.
  • Why it's scary: The primary pitfall is the risk of blocking legitimate emails. If even one legitimate sending service (e.g., your HR system sending password resets, or a support portal sending ticket updates) isn't perfectly DMARC-aligned, those critical emails will be silently rejected. This can lead to serious operational disruptions, frustrated users, and lost business. Moving to p=reject requires absolute confidence that all legitimate email streams are fully compliant.

Example DMARC Record:

v=DMARC1; p=reject; rua=mailto:dmarc_aggregate@yourdomain.com;

Consider an organization that uses SendGrid for transactional emails (e.g., order confirmations, password resets). If the DMARC policy is p=reject and SendGrid's SPF include:sendgrid.net or DKIM records (specific CNAMEs from SendGrid) are missing or misconfigured in the domain's DNS, then all transactional emails sent via SendGrid will be rejected by DMARC-compliant receiving servers. This would halt critical communications, causing significant issues for customers and internal operations.

The DMARC Rollout Strategy: A Practical Path

Moving from p=none to p=reject should be a deliberate, phased process, guided by continuous monitoring of your DMARC aggregate reports.

  1. Start with p=none: Deploy DMARC with p=none and include a rua tag to receive aggregate reports. Monitor these reports diligently for several weeks or months. Identify all legitimate senders (internal systems, marketing platforms, cloud services) and verify their SPF and DKIM configurations. This is where a tool that parses these XML reports into human-readable insights becomes invaluable.