DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a critical email authentication protocol that helps protect your domain from being used for phishing and spoofing attacks. At its core, DMARC allows a domain owner to tell receiving mail servers how to handle emails that claim to be from their domain but fail authentication checks. This instruction is given through a DMARC policy, which is specified in your DMARC DNS record. There are three main policy settings you can use: p=none, p=quarantine, and p=reject. The p=reject policy is the most powerful of the three.
Simply put, the p=reject policy is an explicit instruction to receiving mail servers to completely block any email that fails DMARC authentication checks. This means if an email appears to come from your domain but doesn't pass SPF and/or DKIM alignment, it will be rejected outright and will not be delivered to the recipient's inbox or even their spam folder. It's the strictest level of DMARC enforcement.
What does a `p=reject` policy do?
When a mail server receives an email, it checks for a DMARC record on the sender's domain. If a p=reject policy is found, the server knows that the domain owner wants strict enforcement. If the email then fails authentication, the server follows the reject instruction and blocks the message. The recipient never even sees it. This is a powerful mechanism to prevent malicious actors from impersonating your brand.
Implementing a p=reject policy achieves several key objectives:
- Maximum Protection: It offers the highest level of protection against email spoofing and phishing attacks that abuse your domain.
- Brand Trust: It builds trust with mailbox providers and recipients, as it shows you are serious about email security.
- Improved Deliverability: Because mailbox providers like Google and Yahoo can trust that email from your domain is legitimate, it can improve the deliverability of your authenticated messages.
- Complete Control: You, the domain owner, decide what happens to unauthenticated email, not the receiving server.
Why is `p=reject` the ultimate goal?
While p=none is a great starting point for monitoring and p=quarantine offers a good middle ground, neither provides complete protection. A p=none policy doesn't stop any malicious mail, and a p=quarantine policy still allows potentially harmful emails to reach a user's spam folder, where they might still be opened. As VerifyDMARC points out, p=reject is the strongest policy. Reaching a full p=reject policy is the only way to fully leverage DMARC to protect your domain and your recipients. With major mailbox providers now requiring DMARC, moving towards enforcement is more important than ever.
How to safely implement `p=reject`
Jumping straight to a p=reject policy is a common and costly mistake. If you haven't correctly configured SPF and DKIM for all your legitimate sending services (like your marketing platform, transactional email provider, and even your HR system), you could block your own important emails. The journey to p=reject must be a gradual one.
The correct approach is to start with p=none. This allows you to receive DMARC aggregate reports and identify all the services sending email on your behalf without affecting mail flow. Once you've analyzed these reports and authenticated all legitimate sources, you can move to p=quarantine. This policy sends failing emails to the spam folder, providing a buffer as you gain confidence in your configuration.
To make this transition even safer, you can use the percentage tag (pct). This tag lets you apply the policy to only a certain percentage of your mail. You could start with p=quarantine; pct=10, which would quarantine 10% of failing emails and let the rest through. As you monitor the results, you can gradually increase the percentage.
Once you're at p=quarantine; pct=100 and are confident that no legitimate mail is being flagged, you can begin the final stage: moving to p=reject. Again, use the percentage tag to do this safely. Start with p=reject; pct=5 or p=reject; pct=10 and slowly ramp up to 100% as you verify that only malicious traffic is being rejected.
A final word on `p=reject`
The DMARC p=reject policy is the gold standard for domain security in email. It's a clear statement that you are actively protecting your brand, your customers, and the broader email ecosystem from fraudulent activity. While it requires a careful and methodical implementation, achieving a full p=reject policy is an essential goal for any modern organization.
What is the default value for the DMARC 'p' tag?
Can DMARC policies be applied without an SPF or DKIM record?
What DMARC policy allows for email delivery but marks suspicious emails?
What does a DMARC 'p=none' policy signify?
What DMARC policy setting offers the strongest protection?
Does DMARC affect inbound email handling?
