If you've started looking into DMARC, you've likely seen references to p=none, p=quarantine, and p=reject. These are the three DMARC policy levels — and choosing the right one, in the right order, is the difference between a smooth deployment and broken email.
This guide explains what each policy does, the concerns around moving to enforcement, and the safe progression path that prevents disruption.
The Question Everyone Asks First
"Won't changing my DMARC policy to reject break my email?"
It can — but only if you skip the preparation steps. Done correctly, the phased approach to DMARC enforcement has no impact on legitimate email delivery.
Here's why the risk exists: DMARC p=reject tells receiving servers to block any email from your domain that fails authentication. If a legitimate sender — your marketing platform, your CRM, your support tool — isn't correctly set up in your SPF record or doesn't have DKIM configured, their emails from your domain will fail authentication and get blocked.
The solution isn't to avoid enforcement. It's to identify every legitimate sender first, confirm they all pass authentication, and then enforce.
What DMARC Policy Actually Does
DMARC works by checking whether an incoming email passes SPF, DKIM, or both — and then applying your policy instruction to the result.
Your DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
The p= tag is the policy. It has three possible values.
p=none: Monitor Mode
p=none
What it does: Nothing to delivery. Email that fails authentication is delivered normally. The only effect is that you start receiving aggregate DMARC reports.
What it's for: Discovery. With p=none active and a rua reporting address configured, major mail providers send you daily XML reports showing:
- Every source sending email from your domain
- Whether each source passes SPF, DKIM, or both
- Volume by source
This is how you find out which services send email on your domain's behalf — including services you may have forgotten about.
Protection level: None. Your domain can still be spoofed.
When to use it: As your starting point, always. Never skip this stage.
How long to stay here: 2–4 weeks, or until you've identified all sending sources and confirmed each one passes authentication.
p=quarantine: Partial Enforcement
p=quarantine
What it does: Email that fails authentication is sent to the recipient's spam or junk folder instead of the inbox. It's delivered, but filtered.
What it's for: A middle step between monitoring and full enforcement. It provides real protection against spoofing while giving you a safety net — if a legitimate sender fails authentication, their email goes to spam rather than disappearing entirely.
Protection level: Partial. Spoofed emails land in spam, not the inbox. Many recipients won't see them.
When to use it: After 2–4 weeks at p=none, once your aggregate reports show all known legitimate senders passing authentication consistently.
How long to stay here: Another 2–4 weeks. Monitor your DMARC reports and watch for any legitimate senders showing failures. If a tool you use suddenly starts failing (because they changed their sending configuration, for example), you'll catch it before it affects delivery at p=reject.
p=reject: Full Enforcement
p=reject
What it does: Email that fails authentication is rejected outright. It never reaches the recipient's inbox or spam folder. The sending server receives a bounce.
What it's for: Complete protection against domain spoofing. At p=reject, it becomes technically impossible for an attacker to send email that appears to come from your domain and have it delivered to recipients.
Protection level: Full. Domain spoofing attacks using your domain are blocked at the receiving server.
When to use it: After 2–4 weeks at p=quarantine, once you're confident every legitimate sender is passing authentication with no failures.
Important: Don't rush here. The cost of a false positive at p=reject is an email silently disappearing. At p=quarantine, the cost is an email going to spam — recoverable. Give yourself time to find edge cases.
The Safe Progression Path
| Stage | Policy | Duration | What to Do |
|---|---|---|---|
| 1 | p=none |
2–4 weeks | Identify all senders from aggregate reports |
| 2 | p=none (continued) |
1–2 weeks | Ensure every sender passes SPF and DKIM |
| 3 | p=quarantine |
2–4 weeks | Monitor for legitimate failures going to spam |
| 4 | p=reject |
Ongoing | Full enforcement; continue monitoring reports |
How to Read Your DMARC Aggregate Reports
The rua tag in your DMARC record tells mail providers where to send aggregate reports. These XML files arrive daily and contain:
- Source IP — the server that sent email claiming to be from your domain
- Count — how many messages from that source
- SPF result — pass or fail
- DKIM result — pass or fail
- Disposition — what the receiving server did with the message
What to look for:
- Any source with SPF fail AND DKIM fail — this is either a legitimate sender not correctly set up, or a spoofing attempt
- Unexpected sending IPs — could indicate a compromised account or a service you forgot about
- Low pass rates on a known sender — indicates that sender's DKIM or SPF configuration needs attention
Signs You're Ready to Move to the Next Level
Move from p=none to p=quarantine when:
- All known legitimate senders appear in reports with consistent pass results
- You've identified and fixed any senders that were failing
- No unexpected sending sources appear in reports
Move from p=quarantine to p=reject when:
- No legitimate emails are appearing in spam folders
- DMARC reports show 100% pass rates for all legitimate sources over 2+ weeks
- You've added all third-party senders to your SPF record
Updating Your DMARC Policy
To update your policy, log in to your DNS provider and edit the TXT record at _dmarc.yourdomain.com. Change the p= value. DNS propagation takes up to 48 hours.
If you're setting up DMARC from scratch on Google Workspace, see the step-by-step DMARC setup guide for Google Workspace. For Microsoft 365, see the Microsoft 365 authentication guide.
For post-migration verification, the Google Workspace email migration checklist covers where DMARC fits in the migration sequence.
What p=none Looks Like in Plain English
A lot of domains have a DMARC record that says p=none and the owner thinks they're protected. They're not.
p=none is the equivalent of installing a security camera but not locking the front door. You can see what's happening, but you're not stopping anything.
The SPF, DKIM, and DMARC overview explains why all three components — including a DMARC policy that actually enforces — are needed for real protection.
Get a free Full Audit PDF showing your current DMARC policy and recommended enforcement path at EmailAudit.io
The Full Audit checks your DMARC record, identifies your current policy level, and shows what's needed before you can safely move to enforcement. No account required.