How to use DMARC p=reject to combat email spoofing and its potential impact on legitimate mail?
Matthew Whittaker
Co-founder & CTO, Suped
Published 14 Aug 2025
Updated 19 Aug 2025
8 min read
Email spoofing has become a significant threat, allowing malicious actors to impersonate legitimate domains and trick recipients. When I first encountered an increase in spoofed emails originating from my domain, it was a clear sign that a more robust defense was needed beyond just monitoring with DMARC's p=none policy.
The immediate thought was to switch to p=reject, the strongest DMARC policy. While this seems like a straightforward solution to block fraudulent emails, it comes with a critical consideration: the potential impact on legitimate email delivery. My experience has shown that a hasty implementation can lead to unforeseen deliverability issues.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that works in conjunction with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to protect your domain from unauthorized use. It instructs receiving mail servers on how to handle emails that fail authentication checks. There are three main DMARC policies: p=none, p=quarantine, and p=reject.
The p=reject policy is the most stringent. It tells receiving mail servers to outright reject emails that fail DMARC authentication and alignment checks. This means the email will not be delivered to the recipient's inbox or even their spam folder. This robust approach makes it a powerful tool for combating email spoofing and phishing, as it effectively stops unauthorized emails from reaching their intended targets.
Understanding how each policy works is crucial before making any changes. A p=none policy is for monitoring and data collection, offering visibility into your email ecosystem without enforcing any action. p=quarantine instructs receivers to place failed emails into a junk or spam folder, providing a layer of protection while still allowing some visibility to the user. Finally, p=reject offers the highest level of security, blocking emails outright.
Policy
Action
Use Case
p=none
Monitor only, no action on failed emails.
Initial deployment phase to gather data.
p=quarantine
Move failed emails to spam/junk folder.
Intermediate phase, gentle enforcement.
p=reject
Outright block failed emails from delivery.
Strongest protection against spoofing and phishing.
The power of p=reject against spoofing
The primary benefit of deploying p=reject is its effectiveness in eliminating email spoofing. When your DMARC record specifies p=reject, any email claiming to be from your domain but failing DMARC authentication (meaning it doesn't align with your SPF or DKIM records) is simply not accepted by participating mail servers. This directly combats phishing attacks and protects your brand's reputation.
For instance, if a fraudster sends an email impersonating your domain, say from scammer.com but with your From: address showing yourdomain.com, the receiving server performs a DMARC check. If your policy is p=reject, that email is immediately bounced. This means fewer fraudulent emails reaching inboxes and a stronger defense against email-based attacks.
The enforcement of p=reject ensures that only authorized senders using your domain can successfully deliver mail, significantly reducing the surface area for phishing and email spoofing attempts. This proactive stance is essential for maintaining trust with your customers and partners. You can learn more about configuring DMARC for Microsoft Defender for Office 365.
Benefits of p=reject
Implementing p=reject drastically reduces the volume of fraudulent emails purporting to be from your domain. This directly translates to improved trust and a stronger brand reputation among recipients and mail providers. It provides the strongest defense, stopping malicious emails at the gate.
Navigating the impact on legitimate mail
While p=reject is effective against spoofing, it can inadvertently affect legitimate mail if not implemented carefully. The main risk is that genuine emails that fail DMARC authentication checks will be rejected, potentially leading to lost communication or support tickets. Common culprits include email forwarders and mailing lists, which can break SPF and DKIM authentication.
Email forwarding often modifies the email headers in a way that can invalidate SPF or DKIM signatures. When an email is forwarded, the Mail From address, which SPF checks, may change, causing an SPF failure. Similarly, mailing lists can alter message content, breaking DKIM signatures. If these legitimate emails originate from your domain and then fail DMARC due to forwarding or mailing list modifications, a p=reject policy will cause them to be discarded. This can lead to serious deliverability issues. It's important to understand how to troubleshoot DMARC failures to mitigate these risks.
Another common scenario is misconfigured legitimate sending sources. If you use third-party email service providers (ESPs) like Mailgun or SendGrid for sending marketing or transactional emails, they must be properly configured to align with your DMARC policy. This usually involves setting up SPF and DKIM records specific to those services. If these configurations are incorrect, even your own legitimate emails could be rejected, causing significant disruption.
Before moving to p=reject, it's essential to ensure all your legitimate email streams are fully authenticated and aligned. This requires diligent monitoring of DMARC reports (RUA and RUF reports) to identify any legitimate sending sources that might be failing authentication. These reports provide invaluable insights into your email ecosystem, showing you which emails are passing or failing DMARC checks, and from where they originate.
Risks with p=reject
Legitimate email loss: Emails sent via forwarding services or mailing lists may fail DMARC and be discarded.
Misconfiguration: Incorrectly set up SPF or DKIM for legitimate senders leads to rejection.
Lack of visibility: Without DMARC reporting, you won't know which legitimate emails are being rejected.
Mitigating the risks
Start with p=none: Monitor reports for several weeks or months to identify all legitimate sending sources.
Progress to p=quarantine: Move to this policy once you are confident in your legitimate sending sources, continuing to monitor.
Utilize DMARC reports: Analyze these reports regularly to ensure all legitimate emails are authenticating correctly. You can get more information about DMARC reports from Google and Yahoo.
The phased approach to p=reject
The recommended approach to implementing p=reject is a phased transition. Starting with p=none allows you to collect DMARC reports without affecting email delivery. These reports are crucial for identifying all your legitimate sending sources and ensuring they are correctly configured with SPF and DKIM. Only once you are confident that all legitimate mail streams are authenticating properly should you consider moving to a stricter policy.
The next step is to transition to p=quarantine. This policy offers a middle ground, moving non-compliant emails to the recipient's spam folder instead of blocking them entirely. This allows you to observe the impact of DMARC enforcement and make any necessary adjustments to your authentication records. It's also wise to implement a DMARC p=reject policy safely.
Once you are confident that p=quarantine is not negatively impacting legitimate emails, you can gradually increase the pct tag value (percentage of emails to which the policy applies) before ultimately moving to p=reject for 100% of your mail. This iterative approach minimizes the risk of legitimate email disruption while maximizing protection against spoofing. For more information, the DMARC.org FAQ provides helpful insights.
It's also worth noting that DMARC policies can be set per domain and even per subdomain. If you're using subdomains for promotional emails, you can implement a stricter DMARC policy on those subdomains without immediately affecting your primary domain. This provides flexibility and allows for a more controlled rollout of p=reject.
Always start your DMARC implementation journey with a p=none policy to gather comprehensive reports on your email traffic and identify all legitimate sending sources, including third-party services.
Analyze DMARC aggregate (RUA) reports thoroughly to ensure all your authorized mail is passing SPF and DKIM authentication with DMARC alignment before considering a stricter policy.
Gradually transition from p=none to p=quarantine, and then eventually to p=reject, monitoring the impact at each stage to avoid blocking legitimate emails.
Regularly review your DMARC reports, even after implementing p=reject, to detect any new or unexpected sending sources or potential misconfigurations that could affect deliverability.
Consider setting up DMARC policies for subdomains independently, especially if they are used by different email service providers or for specific campaigns, to allow for more granular control and testing.
Common pitfalls
Switching directly to p=reject from p=none without proper monitoring, which often leads to legitimate emails being rejected or silently discarded, causing communication breakdowns.
Failing to account for email forwarders and mailing lists, which can break SPF and DKIM authentication and result in legitimate forwarded emails being blocked by a p=reject policy.
Not configuring SPF and DKIM correctly for all third-party sending services (e.g., ESPs, CRM platforms), causing emails from these services to fail DMARC and be rejected.
Ignoring DMARC reports (RUA and RUF), which are essential for understanding your email ecosystem and identifying issues before they impact deliverability.
Overlooking the impact of DMARC alignment on deliverability, where both SPF and DKIM must align with the 'From' domain for DMARC to pass effectively.
Expert tips
Ensure SPF and DKIM are fully compliant and aligned before transitioning to any enforcement policy. This is the cornerstone of successful DMARC implementation.
Pay close attention to the 'pct' tag in your DMARC record; it allows for a gradual increase in enforcement, reducing risk during the rollout.
If using subdomains for different purposes, apply DMARC policies at the subdomain level. This offers greater flexibility and minimizes risk to your main domain.
Set up DMARC reporting to an analytics platform for easier data interpretation, which is critical for making informed decisions about policy changes.
Be aware that even with a perfect setup, some legitimate emails (like those from complex forwarding chains) may still be affected by p=reject. Monitor and adjust as needed.
Expert view
Expert from Email Geeks says that if you are questioning whether to move to p=reject, you probably should not do it yet, as you need sufficient data to make an informed decision.
2023-10-21 - Email Geeks
Marketer view
Marketer from Email Geeks says they saw a sudden surge of complaints from emails they didn't send, indicating immediate action was needed, but advised caution for p=reject.
2023-10-21 - Email Geeks
Strategic DMARC implementation
Implementing DMARC with a p=reject policy is a highly effective way to combat email spoofing and protect your brand from malicious impersonation. However, it's not a step to be taken lightly. The strength of p=reject lies in its ability to enforce strict authentication, but this enforcement applies to all emails, legitimate or otherwise, that fail the DMARC checks.
The key takeaway is that a phased approach, coupled with diligent monitoring of DMARC reports, is paramount. By starting with p=none to gather data, transitioning to p=quarantine, and only then moving to p=reject, you can minimize the risk to legitimate mail while achieving maximum protection against email fraud. This strategic implementation ensures that your emails reach their intended recipients, while unauthorized attempts are effectively blocked, safeguarding your domain's integrity and your brand's reputation.
SendGrid for sending marketing or transactional emails, they must be properly configured to align with your DMARC policy. This usually involves setting up SPF and DKIM records specific to those services. If these configurations are incorrect, even your own legitimate emails could be rejected, causing significant disruption.
