What Is a DMARC Policy? None, Quarantine, and Reject Explained

Email domain spoofing allows attackers to send fraudulent messages that appear to come from a legitimate company. These emails may be used to steal credentials, distribute malicious content, impersonate executives, or deceive customers into transferring money.

A DMARC policy helps domain owners reduce this risk by telling receiving email servers how they would prefer messages to be handled when those messages fail DMARC authentication.

Key Takeaways

• A DMARC policy communicates how a domain owner wants receiving servers to treat messages that fail DMARC.
• The three policy values are p=none, p=quarantine, and p=reject.
• A message passes DMARC when at least one authenticated SPF or DKIM identifier aligns with the domain in the visible From address.
• p=none supports monitoring but does not request enforcement against failing messages.
• p=quarantine indicates that failed messages should be treated as suspicious.
• p=reject indicates that failed messages represent unauthorised use of the domain.
• Receiving servers ultimately make their own delivery decisions and may override the published policy.
• Domain owners should analyse aggregate reports and correct legitimate authentication failures before enabling enforcement.

What Is a DMARC Policy?

 
A DMARC policy is a message-handling preference published by a domain owner in a DNS TXT record. It tells receiving email systems how the domain owner assesses messages that use its domain but fail DMARC validation.

The policy is defined using the p tag in a DMARC record:

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

In this example:

• v=DMARC1 identifies the record as a DMARC record.
• p=none sets the policy to monitoring mode.
• rua specifies where aggregate DMARC reports should be sent.

A DMARC policy is not an absolute command that every mailbox provider must follow. Under the current DMARC standard, it represents the domain owner’s preferred treatment of failing messages. The final decision remains with the receiving server, which may also consider reputation, message content, previous sending behaviour, forwarding patterns, and other anti-abuse signals.

How Does a DMARC Policy Work?

 
When a receiving email server processes a message, it identifies the domain displayed in the message’s From header. This is also known as the Author Domain.

The receiver then checks SPF and DKIM:

• SPF verifies whether the message was sent through an IP address authorised by the envelope sender’s domain.
• DKIM verifies the message’s cryptographic signature and identifies the domain that signed it.

Passing SPF or DKIM alone is not enough for DMARC. The authenticated domain must also align with the domain in the visible From address.

A message passes DMARC when one or more authenticated SPF or DKIM identifiers align with the Author Domain. It fails when no authenticated identifier exists or none of the authenticated identifiers align.

When a message fails, the receiving system can review the domain’s DMARC record and consider the policy published in the p tag.

The Three DMARC Policy Options

 
The DMARC standard supports three primary policy values:

DMARC Policies

Although these policies indicate increasing levels of enforcement, they remain assessment signals. Receiving email providers retain control over the final disposition of each message.

What Does p=none Mean?

 
The p=none policy means that the domain owner expresses no special handling preference for messages that fail DMARC.

A basic monitoring record may look like this:

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

Receiving systems should not alter their normal message-handling process solely because of a p=none policy. A failed message may still be filtered as spam or rejected for other reasons, but the DMARC policy itself does not request quarantine or rejection.

The main purpose of p=none is visibility. With a rua reporting address in the record, domain owners can receive aggregate reports showing:

• Which IP addresses are sending messages using the domain
• How much email passes or fails DMARC
• Whether SPF and DKIM are aligned
• Which legitimate platforms require configuration changes
• Whether unknown sources may be spoofing the domain

Aggregate reports are XML files containing authentication results, sending sources, message counts, policy information, and message dispositions. They help domain owners understand their actual email infrastructure before applying stricter controls.

But raw XML reports are difficult to review manually, especially for domains with large email volumes. A DMARC monitoring platform such as DMARKOFF can organise the reporting data into readable dashboards and help teams identify sending sources, alignment failures, and configuration gaps.
 
Secure Your Brand
 

What Does p=quarantine Mean?

 
The p=quarantine policy tells receiving systems that messages failing DMARC should be considered suspicious.

An example record is:

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

Depending on the receiving provider, a quarantined message may be:

• Delivered to the spam or junk folder
• Flagged as suspicious
• Subjected to additional filtering
• Restricted from the primary inbox
• Temporarily held for further analysis

The current DMARC specification defines quarantine as an indication that the message may still be legitimate, but its authentication failure creates significant concern.

This makes p=quarantine a useful intermediate stage for many organisations. It begins reducing the inbox exposure of unauthorised mail while providing some opportunity to discover legitimate services that remain incorrectly configured.

Before publishing this policy, domain owners should identify all authorised senders, including:

• Corporate mail servers
• Email marketing platforms
• Customer support systems
• CRM platforms
• Billing and invoicing tools
• Recruitment software
• Transactional email providers
• Third-party agencies and vendors

Each legitimate source should use aligned SPF, aligned DKIM, or preferably both.

What Does p=reject Mean?

 
The p=reject policy tells receivers that the domain owner considers a DMARC failure a clear indication that the domain’s use is not valid.

An example record is:

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

This is the strongest DMARC policy assessment. It is commonly used when an organisation has identified its legitimate sending infrastructure and corrected authentication or alignment problems.

Under a reject policy, a receiving server may reject the message during the SMTP transaction, preventing it from being accepted for delivery.

However, p=reject does not guarantee that every failing message will be rejected. The current IETF standard states that receivers should not reject messages solely because a domain has published p=reject. They may apply additional analysis to account for legitimate indirect email flows, mailing lists, forwarding, and local filtering rules.

DMARC allows a domain owner to express a strong assessment, but the receiving provider maintains control over message handling.

DMARC Policy Comparison

 
1. p=none

Best used for: Initial discovery and ongoing monitoring.

Advantages:

• Provides visibility into domain use
• Helps identify legitimate email services
• Does not request changes to message delivery
• Supports safer preparation for enforcement

Limitations:

• Does not request quarantine or rejection
• Provides limited direct protection against spoofing
• Requires reports to be actively analysed

2. p=quarantine

Best used for: Introducing enforcement while retaining some flexibility.

Advantages:

• Treats unauthenticated messages as suspicious
• Reduces their likelihood of reaching the primary inbox
• May expose overlooked legitimate senders before rejection is enabled

Limitations:

• Some fraudulent emails may still be delivered
• Legitimate misconfigured messages may reach spam
• Receiver behaviour can vary

3. p=reject

Best used for: Domains with mature and well-monitored authentication.

Advantages:

• Expresses the strongest assessment of failed messages
• Reduces opportunities for exact-domain spoofing
• Helps separate authorised and unauthorised domain use

Limitations:

• Misconfigured legitimate mail may be disrupted
• Mailing lists and forwarding can create interoperability problems
• Receiving providers may override the policy

Common DMARC Policy Mistakes

 
1. Moving to enforcement without analysing reports.

Publishing p=reject before discovering all authorised senders can interrupt legitimate email from overlooked services.

2. Assuming SPF or DKIM automatically passes DMARC.

DMARC requires alignment. A message may pass SPF or DKIM authentication but still fail DMARC when the authenticated domain does not align with the visible From domain.

3. Staying at p=none indefinitely.

Monitoring is valuable, but it does not express an enforcement preference. Organisations should use the collected data to decide whether quarantine or reject is appropriate.

4. Ignoring subdomains.

Attackers may attempt to impersonate subdomains as well as the main organisational domain. Domain owners should review sp, np, and any separate DMARC records published for individual subdomains.

5. Treating DMARC as a spam filter.

DMARC verifies whether use of the From domain is authorised. It does not determine whether the message content is safe, valuable, or wanted. A message can pass DMARC and still be malicious or unsolicited.

Conclusion

 
A DMARC policy allows a domain owner to communicate how receiving servers should assess messages that fail domain authentication and alignment.

The three policies serve different purposes:

• p=none supports monitoring.
• p=quarantine marks failures as suspicious.
• p=reject indicates that failed messages represent unauthorised domain use.

Effective DMARC deployment is not simply a matter of publishing the strictest policy. Organisations must first identify legitimate sending sources, configure aligned SPF and DKIM, analyse aggregate reports, and correct authentication problems.

Tools such as DMARKOFF can simplify this process by translating complex reporting data into practical information about sending sources, authentication results, and policy readiness. With consistent monitoring and careful enforcement, a DMARC policy can substantially reduce exact-domain spoofing while protecting legitimate email operations.
 
Start 14-day Free Trial