How to move from DMARC p=none to p=reject without breaking production mail. The phased rollout that actually works with the failures most senders hit.
What a DMARC Policy Actually Does
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. The "C" matters: conformance. SPF and DKIM are authentication mechanisms they verify that a message is what it claims to be. DMARC is the policy layer on top that tells receivers what to do when SPF or DKIM fail.
Without DMARC, a receiving server has to make a judgment call. SPF failed? Maybe it is a forwarding scenario. DKIM signature broken? Maybe a mailing list rewrote the body. The receiver guesses. Some guesses are right. Many are not.
DMARC removes the guessing. You publish a record at _dmarc.yourbrand.com that says, in effect: if a message claims to be from yourbrand.com and fails authentication, here is what I want you to do with it. The receiver follows your instruction.
This is why DMARC is the only mechanism that actually prevents domain spoofing. SPF and DKIM tell receivers whether a message is authenticated. Only DMARC tells them what to do when it is not.
The Three Policies, Plainly
A DMARC record looks like this:
The p= tag is the policy. There are three values:
p=none Take no action. The receiver still evaluates SPF and DKIM, still records the result, and still sends you aggregate reports if you have configured rua=. But messages that fail authentication are delivered exactly as if DMARC did not exist. This is monitoring mode.
p=quarantine Route failing messages to the recipient's spam folder. Most major receivers honor this strictly. A few interpret it loosely (some treat quarantine as "increase spam score" rather than "send to spam directly"), but the dominant behavior is clear: failing messages do not reach the inbox.
p=reject Refuse the message at SMTP. The sending server gets a 5xx error. The message never enters the receiver's mailbox infrastructure. No quarantine folder, no spam routing a hard rejection.
There is also a sp= tag for subdomain policy, which behaves identically but applies only to subdomains. I will come back to it.
Why p=none Is Not Enough
The single most common DMARC configuration in the wild is a record with p=none published years ago and never touched since. Senders point to it and say "we have DMARC."
They do not have DMARC. They have monitoring.
p=none provides exactly one thing: visibility. You receive aggregate reports showing what mail is being sent claiming to be from your domain, whether it is authenticated, and what receivers see. That visibility is valuable it is the prerequisite for everything that follows but it is not protection. A spoofed phishing email impersonating your domain will reach the inbox just as easily with p=none published as it would with no DMARC record at all.
The protection only kicks in at p=quarantine or p=reject. Which means: if you have published p=none and never moved past it, you have done the work of setting up DMARC and gained none of its security benefits.
This pattern is overwhelmingly common because moving past p=none is genuinely risky. The next sections cover how to do it without breaking production.
The 60-90 Day Rollout That Actually Works
The phased rollout below assumes you currently have either no DMARC record or a p=none record that has been collecting reports for at least a few weeks. If you have neither, start at Phase 1.
Phase 1: Monitor with p=none (Days 1-30)
Publish this record:
The rua= tag tells receivers where to send aggregate reports. These arrive as XML files attached to emails, typically once per day per receiver. Reading them by hand is unworkable past about three days. Use a parser or an in-house parser if you have engineering capacity.
What you are looking for during Phase 1:
- Authorized senders that fail authentication. Your CRM sends invoices through a third-party provider whose DKIM signature does not align with your domain. Your HR platform sends onboarding emails from
your-hr.example.comand the SPF chain is broken. Every legitimate source of mail from your domain needs to pass either SPF or DKIM with alignment to your From-domain. The aggregate reports show you which sources are failing. - Unauthorized senders. If
random-marketing-tool.example.comis sending mail claiming to be from your domain and you have no idea what that is, that is either an unsanctioned shadow IT setup, a marketing agency you forgot about, or an actual spoofing attempt. All three are problems. - Volume baselines. You need a sense of how much legitimate mail is currently failing authentication. If 30% of your mail is failing, you cannot move to enforcement yet. If 2% is failing and you can identify the sources, you can.
The 30-day window is not arbitrary. Many corporate workflows run on monthly cycles payroll runs, invoice runs, quarterly notifications. Sources that send mail once a month are invisible in a one-week monitoring window. Wait for at least one full monthly cycle before moving to Phase 2.
Phase 2: Quarantine with Percentage Ramp (Days 31-60)
This is where senders take down their own mail if they rush.
Do not jump from p=none directly to p=quarantine; pct=100. Use the pct= tag to ramp gradually. The pct= tag tells receivers what percentage of failing messages to apply the policy to. The remainder are treated as if the policy were p=none.
Start here:
This means: of the messages that fail DMARC, quarantine 10% of them. The other 90% are still delivered. If something is broken if a legitimate sender you missed in Phase 1 is failing authentication 10% of their mail goes to spam. That is enough to surface the problem without nuking the channel entirely.
Wait one week. Read the reports. If no legitimate sources are getting hit, ramp up:
pct=25 → wait one week → pct=50 → wait one week → pct=100
The full Phase 2 ramp takes roughly four weeks. By the end of it, you are at full quarantine: every message that fails DMARC for your domain is routed to spam.
If at any point during the ramp a legitimate source starts failing, do not back off the policy. Fix the source. Backing off teaches you nothing and resets your timeline.
Phase 3: Reject (Days 61-90)
If Phase 2 ran clean for at least two weeks at pct=100, you are ready for p=reject.
Most senders skip the percentage ramp at this stage and go straight to pct=100. That is acceptable because at this point every failing source has either been fixed or accepted as collateral. The difference between quarantine and reject is whether failing messages are deliverable-but-spammed or rejected at SMTP. From an attacker's perspective, both block the spoofing attempt.
The reason to actually move to p=reject and not stay at p=quarantine indefinitely: spam folders still expose users to phishing content. Many users check their spam folder. Quarantine routes the spoofed message to a place where some recipients will still see and click it. Reject means the message never enters their mailbox.
Strict vs. Relaxed Alignment
The adkim= and aspf= tags control alignment mode. Both default to relaxed (r) if not specified. The choice matters:
Relaxed alignment (r) allows the authenticated domain to be a parent of the From-domain. If your From address is newsletter@send.yourbrand.com and DKIM is signed with yourbrand.com, that aligns under relaxed mode.
Strict alignment (s) requires an exact match. newsletter@send.yourbrand.com would only align with a DKIM signature for send.yourbrand.com, not the parent domain.
Use relaxed unless you have a specific reason to use strict. Strict alignment is correct for high-security domains (banking, government), but it makes subdomain delegation harder and surfaces no additional protection for the typical sender.
The Subdomain Trap
The p= tag applies to the organizational domain. Subdomains inherit the policy by default unless sp= is set explicitly.
This catches senders in two ways:
Trap 1: Forgotten subdomains. You move yourbrand.com to p=reject after a clean rollout. Three months later, marketing spins up a campaign from promo.yourbrand.com using a tool that does not align DKIM. Every message rejects. Marketing has no idea why their open rates went to zero.
Trap 2: Wildcard exposure. You publish p=reject only on the parent domain. An attacker spoofs accounts-yourbrand.com.attacker.example.com or yourbrand-support.com different domains entirely, not subdomains and DMARC does nothing because it only protects exact organizational domain matches.
For Trap 1, set sp=quarantine initially even when the parent is at p=reject. This gives subdomains a softer landing while you bring them into the authentication fold.
For Trap 2, DMARC cannot help. Look-alike domains require domain monitoring services and trademark enforcement, not authentication policy.
The Mistakes Senders Actually Make
These are the failure patterns I see repeatedly in production rollouts.
1. Treating DMARC reports as junk mail. Aggregate reports arrive as XML attachments and look like noise. Senders set up the rua= address, never read the reports, and move to p=quarantine blind. Then their CRM stops working. The reports were showing them this would happen for two weeks.
2. Forgetting third-party senders. Your DocuSign emails, your support tool notifications, your Calendly invites, your survey platform every one of these is a third party sending mail from your domain. Each needs SPF or DKIM alignment configured, often through a custom DKIM selector or a verified domain in the third-party tool. If the tool does not support custom signing, you cannot use it from your protected domain.
3. Rushing the monitoring phase. Two weeks of p=none is not enough. Monthly batch jobs, quarterly notifications, semi-annual newsletters any of these can be invisible until they run. The full month is a minimum. For large enterprises with complex infrastructure, 60 days of monitoring before any enforcement is reasonable.
4. Setting pct without understanding it. The pct= tag is sampling, not throttling. It does not slow your mail down. It does not rate-limit anything. It only applies to messages that have already failed DMARC the question is what fraction of those failures are subjected to the policy. If your authentication is clean, pct=10 and pct=100 produce identical user-visible results.
5. Publishing reject and forgetting about it. DMARC is not set-and-forget. New tools get added, ESPs change their signing configurations, certificates expire. Reports need to be reviewed at least monthly even after you reach p=reject. The most painful failures I have seen were domains that had been at p=reject for two years, then switched ESPs, then watched their entire marketing channel get rejected because nobody re-verified alignment.
A Working DMARC Record (Annotated)
This is what a production-ready DMARC record looks like for a sender at the end of Phase 3:
Tag by tag:
v=DMARC1- Version. Always this value.p=reject- Reject failing mail on the organizational domain.sp=quarantine- Quarantine failing mail on subdomains. Softer landing for new subdomain rollouts.rua=- Aggregate report address. Required for monitoring.ruf=- Forensic report address. Optional. Few receivers send these (Google does not). Worth setting in case.pct=100- Apply policy to 100% of failing mail. Default is 100.adkim=r; aspf=r- Relaxed alignment. Default.fo=1- Generate a forensic report if any underlying authentication mechanism fails (not just DMARC overall). More signal inrufreports.
Most senders do not need every tag. The minimum viable production record is:
That is enough to enforce policy and receive aggregate reports
Frequently Asked Questions
Will DMARC break my mailing list subscriptions?
Can I publish DMARC without SPF and DKIM?
How long do I need at p=quarantine before moving to p=reject?
What happens to my forwarded mail?
Should I use a DMARC monitoring service?
Is DMARC required by law?
Key Takeaways
- DMARC policy is the only mechanism that actually prevents domain spoofing. SPF and DKIM authenticate; DMARC enforces.
- p=none is monitoring, not protection. The work is incomplete until you reach p=quarantine or p=reject.
- The phased rollout (none → quarantine with pct ramp → reject) takes 60-90 days when done correctly.
- The biggest risk in moving to enforcement is unmonitored sending sources: third-party tools, monthly batch jobs, internal systems nobody documented.
- Aggregate reports (rua=) are not optional. They are the only signal you have during rollout. Use a parser.
- Subdomain policy (sp=) needs explicit handling; do not assume subdomains will behave like the parent.
- DMARC is not set-and-forget. ESP changes, new tools, and expired certificates can break alignment years after rollout.
Most senders never finish the rollout. The ones who do are the ones whose domains do not get spoofed.
Related articles
Why DMARC Alignment Matters More Than DMARC Itself
DMARC fails when SPF or DKIM pass for the wrong domain. The alignment rules, relaxed vs strict modes, and the ESP configuration that fixes it.
DKIM Key Rotation: A Practical Guide for Production Environments
How to rotate DKIM keys in production without breaking signatures. Dual-selector strategy, 2048-bit key sizes, and the rotation cadence that actually works.
Yahoo and Gmail's February 2024 Bulk Sender Requirements: A Compliance Checklist
The complete compliance checklist for Yahoo and Gmail's February 2024 bulk sender requirements. Authentication, unsubscribe, complaint rates—what you actually need.