What are the best practices for setting DMARC policy, particularly p=reject?
Matthew Whittaker
Co-founder & CTO, Suped
Published 25 May 2025
Updated 19 Aug 2025
7 min read
Setting a DMARC policy, especially one as strong as p=reject, is a critical step for domain security and email deliverability. DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to give domain owners control over unauthenticated email.
A well-configured DMARC record helps prevent email spoofing and phishing attacks by telling receiving mail servers what to do with messages that fail authentication checks. While the ultimate goal for many organizations is to reach a p=reject policy, achieving this safely requires a thoughtful and systematic approach. Jumping directly to p=reject without proper preparation can inadvertently block legitimate email traffic, leading to significant disruption.
In this guide, I'll walk through the best practices for setting your DMARC policy, focusing on how to implement p=reject effectively while minimizing risks to your legitimate email campaigns. Understanding each policy type and the phased rollout process is key to protecting your brand and ensuring your emails reach their intended recipients.
DMARC policies dictate how receiving mail servers should handle emails that fail DMARC authentication. There are three primary policy types, each with increasing levels of enforcement.
The choice of policy depends on your current DMARC maturity and confidence in your email sending infrastructure. Transitioning through these policies is generally recommended to ensure all legitimate email sources are properly authenticated before enforcing strict rejection.
P=none: This policy is for monitoring only. It tells receiving servers to deliver emails that fail authentication as usual, but to send DMARC reports to the specified email address. This allows you to collect data on who is sending email on behalf of your domain and identify any legitimate sources that might not be correctly authenticated. It's the recommended starting point for any DMARC implementation. You can learn more about its use cases in our guide on when to use DMARC p=none.
P=quarantine: With this policy, emails that fail DMARC authentication are sent to the recipient's spam or junk folder. This is a step up in enforcement, allowing you to catch potentially fraudulent emails without outright blocking them. It provides a safer middle ground to assess the impact of DMARC failures before moving to full rejection. Google Workspace recommends a gradual approach to DMARC.
P=reject: This is the strictest DMARC policy. When p=reject is set, receiving mail servers are instructed to completely refuse emails that fail DMARC checks. This means the emails will bounce and not reach the recipient's inbox or spam folder. It offers the highest level of protection against spoofing and phishing, ensuring only fully authenticated emails from your domain are delivered. This is often the goal for domains serious about security.
The phased approach to DMARC implementation
The path to safely implementing p=reject typically involves a phased approach. This iterative process allows you to identify and fix any authentication issues without disrupting your legitimate email flow.
Starting with p=none is crucial. This policy lets you monitor your email streams and gather valuable insights from DMARC aggregate reports (RUA) and forensic reports (RUF), if configured. These reports detail which emails are passing or failing DMARC authentication, helping you discover any legitimate sending sources you might not have accounted for.
The gradual DMARC rollout
Step 1: Start with p=none. Deploy your initial DMARC record with p=none. This monitors email activity without impacting delivery. It's essential to collect and analyze DMARC reports during this phase to understand your email ecosystem fully. Refer to our guide on simple DMARC examples.
Step 2: Analyze DMARC reports. Use the reports to identify all legitimate email sending sources and ensure they are properly authenticated with SPF and DKIM. Any source that fails authentication needs to be reconfigured or brought into compliance. You can learn how to set up DMARC reports effectively.
Step 3: Gradually move to p=quarantine. Once you are confident that all your legitimate emails are passing DMARC, update your policy to p=quarantine, perhaps with a low percentage initially (using the pct tag). Continue monitoring your DMARC reports closely.
Step 4: Advance to p=reject. Only when you've observed consistent DMARC passing rates for legitimate mail, and minimal or no false positives under p=quarantine, should you transition to p=reject (and remove the pct tag or set it to 100). This provides the highest level of brand protection.
Benefits and potential challenges of p=reject
Moving to a p=reject DMARC policy significantly enhances your domain's security. It ensures that only emails properly authenticated by SPF and DKIM, and aligned with your DMARC record, will be delivered. This effectively blocks malicious actors from spoofing your domain, protecting your brand reputation and preventing your customers from falling victim to phishing scams. For a deeper dive into the specific tags, check our list of DMARC tags.
However, it's crucial to be aware of potential challenges. One common pitfall is the existence of unknown or unauthenticated mail streams. These could be third-party services, legacy systems, or even individual users sending email on behalf of your domain without proper SPF or DKIM configuration. Implementing p=reject without first authenticating these sources will lead to their legitimate emails being rejected, causing significant deliverability issues.
Another consideration is mail forwarding. When an email is forwarded, the authentication headers (SPF and sometimes DKIM) can break due to changes in the message path. If a forwarded email from your domain fails DMARC authentication at the final recipient's server, it could be rejected. While this is often an edge case, it's something to be aware of, especially for discussion lists or similar scenarios.
To ensure a smooth transition to p=reject, consider these key best practices for your DMARC configuration and ongoing maintenance. Microsoft 365 also advises a gradual DMARC approach.
Key considerations for p=reject
Ensure SPF and DKIM are robust: DMARC relies on the proper configuration and alignment of SPF and DKIM. Before considering p=reject, thoroughly review your SPF and DKIM records to ensure all legitimate sending IPs and signing keys are included and correctly aligned.
Monitor DMARC reports continuously: Even after reaching p=reject, ongoing monitoring of DMARC reports is vital. This helps you quickly detect any new unauthenticated email streams or unexpected failures. Tools can help you analyze these reports effectively.
Handle subdomains and parked domains: Consider how your DMARC policy affects subdomains. You may need a separate DMARC record for specific subdomains or utilize the sp tag to apply the policy to them. For parked domains, a p=reject policy with an empty SPF is standard practice to prevent spoofing.
A standard DMARC record looks like a TXT record in your DNS. Here’s a typical example you might see:
This record specifies the DMARC version (v=DMARC1), the policy (p=reject), and where to send aggregate (rua) and forensic (ruf) reports. The fo=1 tag specifies that forensic reports should be generated when any underlying authentication mechanism (SPF or DKIM) fails to produce a DMARC pass. This is key for understanding issues that might only affect one authentication method.
Final thoughts on DMARC policy enforcement
P=reject represents the strongest posture for email authentication, effectively preventing unauthorized use of your domain. While the benefits for security and brand trust are significant, the key is to ensure meticulous preparation and continuous monitoring.
Always prioritize a phased rollout, starting with p=none to gather data and verify all legitimate sending sources. This diagnostic phase is crucial for identifying and correcting any authentication gaps before enforcing stricter policies.
By following these best practices, you can confidently implement a p=reject DMARC policy, knowing that your domain is protected and your legitimate emails are reaching their intended recipients without issue.
Views from the trenches
Best practices
Start with DMARC p=none and analyze reports for several months before moving to stricter policies.
Ensure all legitimate email sending sources are properly authenticated with SPF and DKIM.
Continuously monitor your DMARC reports to identify new mail streams or potential abuse.
Common pitfalls
Jumping straight to p=reject without first identifying and authenticating all legitimate mail streams.
Not monitoring DMARC reports, leading to unknown deliverability issues or undetected spoofing.
Failing to account for mail forwarding or discussion lists, which can break DMARC authentication.
Expert tips
Use Google Postmaster Tools as a quick sanity check for your DMARC authentication status if comprehensive reports are unavailable.
Be aware that some ISPs might treat p=quarantine and p=reject similarly, often delivering failed emails to the bulk or spam folder.
If a domain or subdomain is newly set up exclusively for an Email Service Provider, you may be able to accelerate the move to p=reject, but careful monitoring is still essential.
Marketer view
Marketer from Email Geeks says the choice of DMARC policy depends entirely on how confident you are about the mail you are sending out. If you are very confident, then p=reject is fine.
2019-08-27 - Email Geeks
Marketer view
Marketer from Email Geeks says p=none is intended for situations where you are unsure about your mail streams and need to understand what's being sent. P=quarantine is for when you are fairly confident but want unauthenticated emails to go to the spam folder. P=reject is for when you are certain and want unauthenticated emails to be completely blocked.
