Use cases for none, quarantine, and reject policy in DMARC

 

DMARC’s purpose of instructing receiving servers on how to handle unauthorized emails from your domain is achieved based on what policy you have set in your DMARC record. While p=reject is undoubtedly the strictest policy, there are conditions in which it isn’t a suitable one. 

Similarly, p=none is considered a good-for-nothing policy, but that’s not entirely true. There are conditions where it’s the suitable DMARC policy. 

As of August 2024, almost 20 million domains worldwide have adopted DMARC. Google and Yahoo’s announcements regarding the requirement of DMARC for bulk and regular email senders have undoubtedly contributed to this growing number. A significant growth in the DMARC adoption rate was observed between January 2024 and April 2024. However, out of these 20 million domains, almost 13 million are stuck at the p=none policy.

The gradual transition from the ‘none’ to ‘quarantine’ to ‘reject’ policy requires a professional-level understanding of cases in which each of these policies is suitable. So, consider this article your guide to implementing the right DMARC policy in the right condition to get minimum false positives and optimum protection from phishing and spoofing attacks attempted in your domain’s name.

 

 

DMARC ‘none’ policy

DMARC’s ‘none’ policy is also called the ‘monitoring policy’ because it doesn’t enforce any action on unauthorized emails sent from your domain, allowing receiving servers to handle such emails as usual. 

Since the ‘none’ policy offers no protection, it’s usually considered a useless or inefficient element of DMARC. But that’s not always the case. Here is a breakdown of scenarios where you are encouraged to use this policy. 

 

During the initial DMARC setup and reporting

If your domain has just started with DMARC, using the ‘none’ policy helps you gather data on legitimate email servers and IP addresses that send emails from your domain. These are the sending sources you officially authorize to be used to communicate through emails on behalf of your brand. This way, you gather the required data without jeopardizing email delivery by subjecting them to rejections or quarantines. 

 

 

For the gradual rollout of DMARC enforcement

While it’s encouraged that you move from p=none to stricter policies, like p=quarantine or p=reject, doing it abruptly surely disrupts the email flow. This can get uglier if SPF and DKIM are not fully aligned across all sending sources.

 A gradual, phased approach gives you enough time to identify and fix issues with SPF, DKIM, and other settings without triggering emails to be marked as spam or bounce-back. Once you gain enough confidence that all the sending sources are fine-tuned, move to stricter policies. 

 

For domains used for transactional emails with multiple third-party vendors

If your business style involves sending transactional emails through multiple third-party vendors, like CRM systems, marketing platforms, and support systems, then using the ‘none’ policy is advised. This is because this policy will help you identify the third-party senders and even check their authentication configurations without harming the delivery of transactional emails in any way. 

This approach helps you understand if any external sending sources need further authentication adjustments.

 

For organizations with complex, decentralized email infrastructure

Generally, large organizations have a complex and decentralized email infrastructure involving multiple domains and subdomains. Many of them also have multiple business units or teams, which complicates DMARC alignment.

 

 

 

In such conditions, if your domain’s DMARC record enforces p=none, you can monitor email sources across departments. This is all the more useful when it is difficult to apply a single authentication method across all systems. After some time, you can also use the reports to spot non-compliant sources and create a customized DMARC policy. 

 

For public-facing or high-volume domains

For domains used for high-volume communication or public interactions (e.g., notifications or info@ domains), there may be high variability in the email senders and configurations. If the monitoring policy is in place, you can get to know the IPs, domains, and sources that interact with public-facing addresses. This gives you a clear roadmap to progressively implement the ‘quarantine’ or ‘reject’ policy. 

 

To test DMARC with internal and external emails

With the monitoring policy, you can see how DMARC is affecting internal and external emails sent from your domain. At times, internal emails bypass public DNS-based checks. In such cases, a domain owner or administrator has to test internal email routing and authentication separately. 

By setting your DMARC record on p=none, it gets easier to troubleshoot potential issues in internal routing or forwarding setups. This way, you don’t interrupt the end-user experience or email delivery. 

 

 

DMARC ‘quarantine’ policy

p=quarantine is a moderate enforcement step that instructs recipients’ servers to mark unauthorized emails sent from your domain as spam. This policy helps divert suspicious emails rather than rejecting them altogether. So, if you want some level of protection for your domain without being in haste and risking the rejection of legitimate emails. 

So, here are the scenarios in which experts advise enforcing the quarantine policy–

 

For the transition phase between p=none and p=reject

While going from ‘none’ to ‘reject,’ it’s good to rest on the ‘quarantine’ policy. This relatively lenient transitional policy helps you find legitimate senders who aren’t properly compliant with SPF and DKIM. This gives you some time to adjust the configurations. 

 

 

Moreover, this transition policy provides insight into the operational impact of enforcement. You get to know about services or internal senders that need alignment adjustments. 

 

If you have a high-risk domain with potential spoofing but with some email complexity

Domains at risk of being spoofed, such as customer service or sales email addresses, may require a DMARC policy stronger than p=none but not as strict as p=reject. So, setting your DMARC record at p=quarantine ensures unauthorized emails reach the recipients’ mailboxes but get placed in their spam folders and not primary inboxes. This minimizes the risk of accidentally rejecting legitimate communications. 

 

 

 

For mitigating false positives

If you own an organization with multiple departments or business units, chances are your email flow is complex and decentralized. This situation tends to trigger false positives due to slight misalignments in SPF and DKIM setups. Setting p=quarantine helps identify and isolate emails that fail DMARC without deleting them. This allows IT teams to review potential false positives without fully rejecting emails.

This policy is beneficial when internal forwarding and relaying is included in your email infrastructure, as it preserves the original sender’s authentication.

 

 

If your domain is still gaining visibility into legitimate and illegitimate senders

For organizations that have recently started using DMARC, p=quarantine can help classify non-compliant emails. By observing quarantined emails, you can pinpoint any gaps in your email ecosystem and take steps to align these senders before advancing to p=reject.

 

To secure non-essential subdomains

Threat actors often target subdomains of reputed companies for sending phishing and spoofing emails in their name. This is because many domain owners ignore the security of non-essential, infrequently used, or parked subdomains. So, if you aren’t one of these and want to secure your subdomains moderately, p=quarantine will serve the purpose. 

If subdomains are managed by teams outside the central IT, enforcing p=quarantine for them makes it easier to catch non-compliant messages without hampering email deliverability.

 

 

For testing DMARC policy in a high-volume email environment

High-volume environments, such as customer service or automated notification systems, benefit from p=quarantine as it allows you to detect misconfigurations without significantly affecting deliverability. The high volume helps provide valuable data on how enforcement policies impact legitimate email sources, setting the stage for a future shift to ‘p=reject’ once confidence in alignment is achieved.

 

When you have to handle internal domain forwarding or routing issues

If your email infrastructure includes frequent internal email forwarding or routing, it’s likely that your emails will lose SPF and DKIM headers, triggering DMARC to fail. In such conditions, p=quarantine behaves as an intermediary step that helps you understand how internal email forwarding affects DMARC compliance without causing outright rejections.

 

DMARC ‘reject’ policy

The ‘reject’ policy in DMARC helps you instruct the receiving servers to reject emails sent from your domain that fail DMARC authentication. It’s the strictest DMARC setting, allowing you to prevent unauthorized emails from getting delivered to recipients’ inboxes.

Here are the conditions where the ‘reject’ policy fits the best:

 

 

For high-profile brands, government or public sector organizations, and high-value e-commerce platforms

The domains of these entities are often exploited because of their credibility and trust among people. Government or public sector organizations usually use the ‘reject’ policy to prevent impersonation that could otherwise mislead citizens into sharing sensitive information. Government agencies are advised to strictly adhere to healthy SPF and DKIM practices to validate critical communications, thus ensuring the public keeps trusting their emails. 

If we talk about e-commerce platforms, we know how frequently they have to send emails with transaction information, receipts, and promotional offers, making them prime targets for spoofing and phishing. Implementing p=reject ensures that only authenticated emails from the platform reach customers, reducing the risk of fake promotions, account takeovers, or fraud.

 

For financial institutions or regulated industries requiring high-security

Finance institutions and regulated industries store tons of sensitive data; therefore, stringent regulations regarding email security and data protection are imposed on them. They can’t risk potentially fraudulent emails sent from their domains reaching recipients’ mailboxes, even in spam folders. This is because recipients might open these emails and, as a result, share sensitive financial information or transfer money, falling victim to the attackers’ schemes.

 

 

For executive or VIP email addresses

Company executives are prone to becoming targets for impersonation so as to trick employees or clients into making financial transfers or sharing confidential information. So, by enforcing the p=reject policy for such domains or subdomains, you prevent hackers from impersonating these high-value individuals. 

 

Final words

We hope this guide specifying use cases of DMARC policies comes in handy in different phases of your domain’s email authentication journey. We understand that amidst all the business chaos, monitoring DMARC reports and adjusting policies as and when required is challenging. So, allow DuoCircle to help you with this.