If you've set up DMARC on your domain, you've probably stared at the policy tag and wondered what you actually chose. p=none, p=quarantine, p=reject. They look similar, but they tell receiving mail servers to do very different things with messages that fail authentication.
Getting this wrong matters. Pick the wrong policy too early, and you could end up blocking your own newsletters or invoices. Leave it too loose for too long, and you're not actually protecting your domain from spoofing. Let's go through what each policy does and how to move through them safely as part of a proper DKIM SPF DMARC setup.
A Quick Refresher on What DMARC Actually Checks
DMARC sits on top of SPF and DKIM. It doesn't do its own authentication, it just tells receiving servers what to do when SPF or DKIM checks fail, and it requires alignment between the domain in the "From" header and the domains those checks validate.
Without DMARC, SPF and DKIM can both fail silently and the email still lands in someone's inbox. That's the gap DMARC closes. If you haven't gone through the basics yet, we covered the fundamentals in A Plain-Language Guide to Setting Up DKIM, SPF, and DMARC for Your Domain.
Policy One: p=none
This is the starting point for almost every domain. With p=none, you're telling receiving servers: "Check the email against our SPF and DKIM records, but don't do anything special if it fails. Just send us a report."
Nothing gets blocked or quarantined. Your mail flow stays exactly as it was before you added DMARC. The value here is entirely in the reporting. You'll start receiving aggregate reports (usually daily, in XML format) showing every server sending mail using your domain, whether those messages passed authentication, and where they came from.
This is the discovery phase. You'll often be surprised by what you find. Marketing tools, old CRM integrations, a forgotten newsletter platform, all sending mail "from" your domain without proper authentication. You want to catch these before you tighten the policy, not after.
Plan to stay at p=none for at least two to four weeks. Longer if your domain sends mail through a lot of third-party tools.
Policy Two: p=quarantine
Once your reports show that legitimate mail is passing SPF and DKIM consistently, you can move to p=quarantine. This tells receiving servers to treat failing messages with suspicion, usually by routing them to spam or junk folders instead of rejecting them outright.
Quarantine is the middle ground. It gives you real protection, spoofed emails won't land in the primary inbox, while still giving you a safety net. If something you didn't catch during the monitoring phase starts failing, it ends up in spam rather than disappearing completely. You can still find it, diagnose the problem, and fix it.
You can also apply quarantine gradually using the pct tag. Setting pct=25 applies the quarantine policy to only 25% of failing messages, letting you ramp up slowly and watch for problems as you go.
Policy Three: p=reject
This is the strict policy. Receiving mail servers will refuse messages that fail DMARC entirely. No inbox, no spam folder, just a rejection at the server level.
Reject is what you want for a fully protected domain, especially for domains used in financial communication, password resets, or anything attackers would want to impersonate. It's also what most big inbox providers are increasingly expecting to see from legitimate senders, especially after Gmail and Yahoo tightened their bulk sender requirements.
But reject should be the last step, not the first. Jumping straight to p=reject without going through monitoring and quarantine first is one of the most common DMARC mistakes we see. If even one legitimate sending source isn't properly authenticated, those emails vanish. No bounce notification reaches the sender, because the rejection happens on the receiving end. You might not realize anything is wrong until a customer tells you they never got an invoice.
How to Move Through the Policies Safely
The general path looks like this:
- Start with p=none and collect reports for a few weeks.
- Review every sending source in those reports and fix SPF or DKIM for any that are failing but legitimate.
- Move to p=quarantine with a low pct value, then increase it gradually.
- Once quarantine reports look clean, move to p=reject, again ramping up with pct if you want extra caution.
Reading the aggregate reports by hand is painful. Most people use a DMARC reporting tool to parse the XML into something readable. This is the single biggest factor in whether your DKIM SPF DMARC setup actually succeeds. Skipping the reporting step and guessing your way to reject is how legitimate mail disappears.
What About the Subdomain Policy?
DMARC lets you set a separate policy for subdomains using the sp tag. This matters more than people expect. If your main domain has a strict reject policy but you don't set sp, subdomains might inherit a weaker posture, or attackers might specifically target an unprotected subdomain to spoof mail that still looks trustworthy to recipients. Setting sp=reject alongside your main policy closes that gap.
Checking That Your Policy Is Actually Working
Once you've set a policy, don't just assume it's doing its job. Send test emails from unauthenticated sources, review your DMARC reports regularly, and keep an eye out for any drop in deliverability right after a policy change. We walked through this process in more detail in How to Check Whether Your DKIM SPF DMARC Setup Is Actually Working Correctly.
If you're managing email for a business domain, a good hosting provider should be able to help you review your DNS records and confirm your SPF, DKIM, and DMARC entries are formatted correctly. A single typo in a DMARC TXT record can make the entire policy inert without any warning.
The Takeaway
None, quarantine, and reject aren't three separate features, they're stages of the same journey. Start by watching, move to a soft enforcement, and only lock the door once you're sure every legitimate sender has a key. Rush it, and you risk losing real email. Skip it entirely, and your domain stays wide open to spoofing. Either way, the destination is the same: a fully enforced p=reject policy backed by clean SPF and DKIM records across every sending source you own.
