DMARC Policy: none vs quarantine vs reject

What DMARC policies do

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM. It publishes a DNS TXT record that tells receiving mail servers what to do with messages that fail SPF or DKIM alignment.

The core of a DMARC record is the p= tag, which sets the policy. The policy only applies to messages that fail DMARC alignment — messages that pass SPF or DKIM alignment are not affected.

Choosing the right enforcement level is important: a policy that is too weak leaves your domain unprotected, while one deployed too aggressively can block legitimate email.

What p=none means

p=none is the monitoring-only DMARC policy. When a message fails DMARC alignment, no action is taken — the message is delivered normally to the recipient's inbox.

With p=none, receiving servers send aggregate reports (rua:) to the address specified in your DMARC record. These reports show which sources are sending email on your behalf and which are failing authentication.

p=none is the correct starting point for DMARC deployment. It lets you understand your email sending landscape before enforcing policy.

However, many domains mistakenly stop at p=none believing they are protected. They are not. A domain with only p=none provides no protection against spoofing or phishing.

What p=quarantine means

p=quarantine instructs receiving mail servers to treat failing messages as suspicious. In practice, this usually means moving them to the recipient's spam or junk folder.

p=quarantine provides meaningful protection against domain spoofing while reducing the risk of blocking legitimate mail that hasn't yet been properly aligned.

It is the recommended intermediate step when moving from p=none toward full enforcement. During this phase, you can continue to monitor aggregate reports and fix any remaining alignment issues before moving to p=reject.

What p=reject means

p=reject is the strongest DMARC enforcement level. Receiving mail servers reject messages that fail DMARC alignment at the SMTP level, before they are delivered to any mailbox.

With p=reject, spoofed or phishing emails purporting to come from your domain are blocked outright. Recipients never see them in inbox or spam.

p=reject provides the strongest available protection against domain impersonation. However, it requires that all legitimate senders are properly configured with SPF or DKIM alignment. Deploying p=reject before completing this alignment work will block legitimate email.

DMARC policy comparison

p=none — Visibility only. Failing messages are delivered normally. Reports are sent. No spoofing protection.

p=quarantine — Partial enforcement. Failing messages go to spam. Provides meaningful protection with lower operational risk during transition.

p=reject — Full enforcement. Failing messages are rejected at SMTP. Maximum protection against spoofing and phishing, but requires complete alignment before deployment.

From a security standpoint, p=reject is clearly the strongest. From a deployment risk standpoint, moving through quarantine first is safer for most organisations.

Why p=none is not enough

A DMARC record with p=none tells receiving servers to take no action on failing messages. Spoofed emails from your domain continue to reach recipients' inboxes.

p=none gives domain owners a false sense of security. It provides reporting visibility but zero enforcement. Attackers can freely send phishing emails using your domain name.

Additionally, BIMI — the standard that allows your logo to appear next to emails in mail clients — requires DMARC enforcement. p=none does not qualify for BIMI.

Once you have reviewed aggregate reports and confirmed that legitimate senders pass alignment, there is no reason to stay at p=none.

How to safely move from none to reject

A staged rollout reduces the risk of blocking legitimate mail:

Step 1: Deploy p=none with rua= reporting. Collect aggregate reports for at least 2–4 weeks.

Step 2: Identify all sources sending email on behalf of your domain. Ensure each one passes SPF or DKIM alignment.

Step 3: Fix alignment issues. Configure DKIM signing for third-party senders and verify MAIL FROM alignment for SPF.

Step 4: Move to p=quarantine. Optionally use pct=10 to apply the policy to a percentage of traffic first, then increase gradually.

Step 5: Move to p=reject once aggregate reports confirm all legitimate mail is passing authentication.

Common DMARC deployment mistakes

Enabling p=reject too early. Deploying rejection before all senders are properly aligned blocks legitimate email.

Missing third-party senders. Marketing platforms, CRMs, and support tools often send email using your domain. Each needs DKIM alignment.

Relying only on SPF. SPF breaks during forwarding. Without DKIM, DMARC has no forwarding-resilient alignment option.

Not monitoring reports. Aggregate reports show authentication failures, new senders, and misconfigured systems. Ignoring them means missing problems.

Forgetting parked domains. Domains that do not send email are frequently spoofed. They should have a DMARC record with p=reject and an SPF record that rejects all senders.

How BIMI depends on DMARC enforcement

BIMI (Brand Indicators for Message Identification) allows your verified logo to appear next to emails in supported mail clients such as Gmail and Apple Mail.

BIMI requires DMARC enforcement — specifically p=quarantine or p=reject. A DMARC record with p=none does not satisfy the BIMI requirement, regardless of how well SPF and DKIM are configured.

This makes DMARC enforcement a prerequisite for any organisation that wants to leverage BIMI for brand visibility in email.

How to check your DMARC policy

Use MXFend's DMARC Checker to validate your DMARC record, check the policy level, verify rua and ruf report addresses, and detect alignment and syntax issues.

Run the MXFend Email Security Score for a complete audit covering DMARC, SPF, DKIM, BIMI, blacklists, SMTP TLS, and more.