- Development
While DMARC projects can vary greatly in size, complexity, and stage, they all face a common challenge: knowing when to move forward with your policy.
This guide will cover essential factors to consider, milestone validation tips, and DNS syntax best practices, providing you with the confidence to advance your domains to a more stringent DMARC policy of p=reject.
DMARC Policies
Here’s a brief overview of DMARC policies, the typical order in which they are applied, and how each policy provides varying levels of protection against phishing, spoofing, and unauthorized use of your domains:
The three DMARC policy modes are none, quarantine, and reject. These policies are generally applied in the order listed, but in certain cases—such as when applying DMARC to a parked or inactive domain—it may be appropriate to start with a stricter policy.
When your email is received by organizations, they will refer to the DMARC policy in your DNS to determine how to treat your mail. Here’s a breakdown of the policies:
- p=none: This is typically the first policy used in a DMARC project. The “none” policy provides visibility into how your domain is being used without affecting how your emails are handled by email receivers. Essentially, it tells receivers, “don’t treat my email differently, but send me DMARC reports so I can make informed decisions going forward.” While it provides no protection, it gives you full visibility into the use of your domain.
- p=quarantine: The second policy applied in a typical DMARC project, “quarantine” offers partial protection. It tells email receivers to still accept the message, but flag it as suspicious by placing it into the recipient’s spam or quarantine folder. This is an important milestone in a DMARC project, as it helps reduce the risk of unauthorized use while still allowing emails to be delivered.
- p=reject: The strictest DMARC policy, “reject,” provides the highest level of protection against unauthorized domain use. It instructs email receivers to block emails that fail the DMARC check entirely. Unlike the “quarantine” policy, “reject” results in an automatic rejection notice being sent back to the sender. You’ll also be able to monitor the number of rejected emails and the sources of those rejections in your DMARC reports.
Getting Ready for DMARC Policy Advancement
Before advancing your DMARC policy, there are several important factors to consider:
1. Avoid Advancing Too Quickly
Moving forward with your DMARC policy without proper visibility may lead to the blocking or degradation of legitimate email delivery. To prevent this, ensure you have a solid understanding of DMARC and full visibility into your email sources. It’s also recommended to gather at least four weeks of data before proceeding, so you have enough time to assess and make adjustments.
2. Achieve Alignment Across Legitimate Email Sources
DMARC alignment refers to the consistency between the domain in your From: header and the domains in your SPF and DKIM records. All three elements must match for the email to pass DMARC validation. Be sure all your legitimate email sources are aligned to prevent unauthorized emails from bypassing the policy.
3. Analyze DMARC Compliance Percentage
Understanding your DMARC compliance percentage is crucial to policy progression. Generally, once you achieve a 98% compliance rate or higher, you can start advancing your DMARC policy on a domain-by-domain basis. However, in certain situations—such as if there’s a known unauthorized email source you choose not to bring into alignment—you may be ready to proceed before reaching the 98% mark.
Example Scenario: The IT security team discovers a third-party vendor, not aligned with internal standards, is sending unauthorized shopping cart abandonment emails. Despite this, the team decides to proceed with advancing the DMARC policy, knowing these unauthorized emails will be affected and the vendor’s messages will be blocked.
4. Communicate and Collaborate Across Teams
Keep your colleagues informed about the progress of your DMARC project. Ensure that everyone knows about the changes and has a way to report issues if they notice legitimate email being affected. Socializing the project internally will help mitigate potential disruptions and encourage proactive problem-solving.
Understanding the Importance of DMARC’s Percentage Tag
pct tag is optional in a DMARC record, it allows for a gradual increase in policy enforcement. This approach helps identify necessary actions and resolve issues before enforcing a strict 100% p=quarantine or p=reject DMARC policy. We’ll provide recommendations for pct tag values in the section below.
If you do not include the pct tag, the default value is set to 100%. The tag values can range from 1% to 100%. Since p=none is used for monitoring only and does not take action on email flows, the pct tag is unnecessary and should not be included when using a p=none policy. 
What to Anticipate with a p=quarantine DMARC Policy
When you implement a p=quarantine DMARC policy, you instruct email receivers to route messages that fail the DMARC check to the recipient’s spam folder. Here are two key aspects to keep in mind with this policy:
- Message Handling:
- For consumer-oriented mailboxes (e.g., Gmail, Yahoo, Hotmail), emails that fail DMARC checks will be directed to the recipient’s spam folder.
- For business-oriented mailboxes (e.g., Microsoft 365, Google Workspaces, Mimecast), the messages may be placed in a quarantine area managed by the recipient’s IT team. As the sender, you won’t have direct access to these quarantine areas to inspect the messages. However, using DMARC platforms like DMARCtron can help identify which mailstreams are being quarantined and how often.
- Observing Impact:
- The effect of the p=quarantine policy is seen by the email receivers, as they are the ones who will notice the emails being treated as spam or quarantined. You won’t receive notifications unless you’re monitoring through a DMARC platform. With tools like DMARCtron’s Detail Viewer, you can track how many emails are getting quarantined or rejected, providing valuable data on your DMARC deployment, gaps in authentication, and sending patterns.
Although p=quarantine is useful for data collection and testing, the most secure state for your domain protection is a p=reject policy at 100%. This prevents unauthenticated emails from being delivered. Without DMARC, email receivers make their own decisions on what is considered fraudulent, but with DMARC, you control the outcome and ensure only authenticated emails are delivered.
What to Expect with a p=reject DMARC Policy
The p=reject DMARC policy instructs email receivers to permanently reject any email that fails the DMARC check. In most cases, this results in a 5XX series hard bounce message being sent to the sending server, informing them that the email was rejected.
To effectively monitor the impact of this policy, it’s important to regularly check your DMARC data to identify any changes in patterns. This will help you detect potential issues with legitimate email streams and ensure smooth email delivery.
The p=reject policy offers the highest level of protection against unauthenticated email, including fraudulent or malicious emails originating from your domain or shadow IT sources. By implementing this policy, you ensure that only legitimate, authenticated emails are delivered, safeguarding your brand and maintaining email security.
DMARC Maintenance
After achieving the goal of enforcing a p=reject DMARC policy, it’s essential to establish a strategy for long-term DMARC management to maintain compliance and address any emerging issues. The “Life after Reject” phase focuses on proactively managing your DMARC environment and staying prepared for unforeseen changes. Here’s what you should monitor moving forward with the help of our DMARC Management Platform:
Regular SPF Record Checks – Use tools like our SPF Surveyor to regularly verify that your SPF records are current. Check for any outdated IPs or netblocks that are no longer authorized to send email on behalf of your organization. Reviewing SPF records helps prevent over-authentication, which can negatively affect deliverability.
Approval Process for SPF Changes – Ensure that any changes to SPF records go through an approval process managed by the DMARC project owner. Set up alerts to notify you of any unapproved changes, reducing the risk of unintended alterations.
DKIM Key Rotation – Regularly rotate your DKIM keys (e.g., every few months or annually) to maintain security. Monitoring the key rotation process helps prevent potential vulnerabilities.
Periodic DMARC Data Review – Consistently check for new sources of legitimate email traffic. Investigate potential issues such as vendor consolidation, changes in email volume, compliance regressions with specific vendors, and unexpected delivery patterns to ensure smooth and compliant email delivery.
Regular Reporting – Configure your DMARC management platform to send reports on how your domains are being used, including any misuse or abuse. These reports help you stay on top of unauthorized activity and identify potential security threats.
Internal Incident Management – In case of email deliverability issues, use DMARC data to investigate the cause. Filter the data to get a comprehensive view of the issue’s scope and determine the best solution, ensuring that your email traffic continues to align with your security standards.
By establishing a structured approach to managing DMARC compliance, you can maintain a high level of email security and address potential challenges as they arise.
