Most domains that publish a DMARC record never move past the first policy mode. They set p=none, maybe configure a reporting address, and then leave it there permanently. The record exists. It looks like progress. But p=none tells receivers to do absolutely nothing when authentication fails, which means an attacker spoofing your exact domain faces the same consequences as if you had no DMARC record at all. The three policy modes, none, quarantine, and reject, represent a progression from observation to enforcement, and the distance between the first and the last is the difference between knowing about spoofing and actually stopping it.
This guide covers what each policy mode does, what you gain and risk at each stage, and how to move through the progression without breaking legitimate mail. The focus is specifically on the policy decision, not on SPF or DKIM mechanics (covered in SPF, DKIM, and DMARC explained) and not on report interpretation (covered in DMARC report analysis).
Quick check: Use the DMARC Builder to see your current policy and Email Security Check to evaluate your full authentication posture.
What DMARC Policy Controls
The p= tag in a DMARC record tells receiving mail servers what to do when an incoming message claims to be from your domain but fails both SPF alignment and DKIM alignment. Alignment is the key word. A message can pass an SPF check against one domain and still fail DMARC because the authenticated domain does not match the visible From address. The policy only fires when both authentication methods fail to align, meaning neither the SPF-authenticated domain nor the DKIM-signing domain matches the From header domain.
Three values are possible. p=none means the receiver should take no action based on DMARC results, though it should still send reports if a rua= address is provided. p=quarantine means the receiver should treat failing messages as suspicious, which in practice usually means routing them to the spam folder. p=reject means the receiver should block the message outright, refusing delivery at the SMTP level.
Two additional tags shape how the policy is applied. The sp= tag sets a separate policy for subdomains, which lets you protect subdomains more aggressively than the organizational domain or vice versa. The pct= tag controls what percentage of failing messages the policy actually applies to. Setting pct=25 on a quarantine policy means only 25 percent of failing messages are quarantined; the other 75 percent are treated as if the policy were none. This percentage mechanism is what makes gradual rollout possible.
p=none: The Monitoring Phase
Publishing p=none with a rua= reporting address is the correct starting point. It causes no disruption to mail delivery because receivers are instructed to take no enforcement action. What it does provide is visibility. Aggregate reports will begin arriving within 24 to 48 hours, and they show every IP address that sent mail using your domain in the From header, along with whether each source passed or failed SPF and DKIM and whether those results were aligned.
The monitoring phase answers several critical questions. Which services and IPs are sending mail as your domain? Which of those are legitimate? Which legitimate senders are failing authentication, and why? Are there unexpected sources that indicate active spoofing? Teams typically need two to eight weeks at p=none, depending on the complexity of their mail infrastructure. A domain with one mail provider and no third-party senders may be ready to move in days. A domain with a CRM, a marketing platform, a transactional email service, an HR system, and a legacy application server may need two months to catalog everything.
The trap with p=none is that it feels like security. You have a DMARC record. You are receiving reports. But from a protection standpoint, p=none is identical to having no DMARC record. An attacker can still send a perfectly spoofed message from your domain and it will be delivered normally. The only difference is that you will see it in a report after the fact. If your domain has been at p=none for more than three months without a concrete plan to advance, the monitoring phase has become a permanent parking lot.
- Aggregate reports show source IPs, message counts, SPF and DKIM pass or fail, and alignment status.
- Identify every legitimate sender and verify each one passes SPF or DKIM with proper alignment.
- Track down failing legitimate sources and fix them before moving forward.
- Two to eight weeks is typical; longer if the domain has many third-party senders.
p=quarantine: The Testing Phase
Once aggregate reports show that all known legitimate senders pass authentication with alignment, the next step is p=quarantine. At this level, receivers treat messages that fail DMARC as suspicious. In most implementations, this means the message lands in the spam or junk folder rather than the inbox. The message is not blocked, so if something was misconfigured, the mail is still recoverable, just not prominent.
The critical practice at this stage is to use the pct= tag to limit exposure. Start with pct=25, which tells receivers to quarantine only 25 percent of messages that fail DMARC. The remaining 75 percent are still treated under p=none behavior. This creates a controlled experiment: you can watch reports for a week or two and see whether any legitimate mail is being quarantined. If the reports are clean, increase to pct=50, then pct=75, then pct=100.
During the quarantine phase, pay close attention to feedback from internal teams and customers. Marketing teams may notice campaign emails hitting spam. Sales may report that sequences from the CRM are underperforming. Support may hear from customers who stopped receiving transactional messages. Each of these is a signal that a sender was missed during the monitoring phase and needs its SPF or DKIM alignment corrected before moving further.
p=reject: Full Enforcement
p=reject is the end goal. When a receiver sees a message that fails DMARC alignment and the policy is reject, the message is blocked at the SMTP transaction level. It is not delivered to spam. It is not silently dropped. It is refused, and the sending server receives a rejection notice. This is the strongest protection DMARC offers: exact-domain spoofing becomes functionally impossible against receivers that honor the policy, which includes all major mailbox providers.
The prerequisites for moving to reject are straightforward but demanding. Every legitimate sender must pass either SPF or DKIM with alignment. DMARC aggregate reports at pct=100 quarantine should show zero unexpected failures from known sources. The team should be confident that its sender inventory is complete, meaning no forgotten marketing tool, no legacy application, no partner integration sending as your domain without proper authentication.
The same pct= ramp applies. Move to p=reject with pct=25 first. Monitor for a week. If aggregate reports show no legitimate mail being rejected, increase to 50, then 75, then 100. At pct=100 with p=reject, your domain has reached full DMARC enforcement. Any message that fails both SPF and DKIM alignment will be blocked before it reaches the recipient.
The Safe Rollout Path
The progression from none to reject is a seven-stage process. Each stage has a clear action, a monitoring period, and a gate condition for moving to the next. Rushing through these stages is how organizations break legitimate mail. Taking them seriously is how organizations reach full enforcement without incident.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected];"_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected];"
; Same record. Work happens in SPF/DKIM configuration, not here._dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected];"_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];"_dmarc.example.com TXT "v=DMARC1; p=reject; pct=25; rua=mailto:[email protected];"_dmarc.example.com TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected];"_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected];"
; pct defaults to 100 when omitted. Record is now at maximum enforcement.The gate condition at every stage is the same: aggregate reports show no legitimate mail failing alignment. If a problem appears, fix the sender's authentication, wait for reports to confirm, then resume the progression. Never advance while a known legitimate sender is still failing.
Subdomain Policy: The sp= Tag
The sp= tag sets a DMARC policy specifically for subdomains of the organizational domain. This is one of the most underused DMARC features. Most organizations have a small number of subdomains that actively send mail and a very large number that do not. Attackers know this and frequently spoof addresses like invoice.yourdomain.com, support.yourdomain.com, or entirely random strings like x7q.yourdomain.com. Without an explicit sp= tag, subdomains inherit the organizational domain's p= policy.
The practical advice is to set sp=reject early, even while the organizational domain is still at p=none. If no subdomain sends mail, there is no legitimate traffic to disrupt. If a few subdomains do send mail, they can publish their own DMARC records that override the organizational policy. This means the organizational domain can protect the entire subdomain namespace aggressively while maintaining a more cautious rollout for the primary domain.
_dmarc.example.com TXT "v=DMARC1; p=none; sp=reject; rua=mailto:[email protected];"
; Subdomains that need to send mail publish their own DMARC record:
_dmarc.mail.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected];"Common DMARC Policy Mistakes
The same mistakes appear repeatedly across organizations of every size. Each one either delays enforcement unnecessarily or causes avoidable disruption to legitimate mail.
- Jumping straight to p=reject without monitoring. This blocks legitimate mail from any sender that is not yet properly authenticated, which is discovered only after customers or partners stop receiving messages.
- Publishing DMARC without rua=. Without a reporting address, you have enforcement with no visibility. You cannot diagnose failures, identify senders, or confirm that the policy is working correctly.
- Forgetting third-party senders. CRMs, marketing platforms, transactional email services, helpdesk tools, and HR systems often send as your domain. Each one needs SPF inclusion or DKIM signing with your domain's alignment.
- Not setting sp= explicitly. Without sp=, subdomains inherit the organizational policy. If the organizational domain is at p=none, every subdomain is unprotected, and attackers can spoof arbitrary subdomains freely.
- Staying at p=none indefinitely. Monitoring without a plan to enforce is the most common failure mode. Set a target date for quarantine within 90 days of publishing p=none.
- Ignoring the pct= ramp. Moving from none to quarantine at pct=100 or from quarantine to reject at pct=100 in a single step removes the safety margin that makes gradual enforcement work.
How to Check Your Current Policy
Use the DMARC Builder to inspect your current DMARC record and see which policy mode, subdomain policy, and reporting addresses are configured. The Email Security Check runs a broader evaluation that includes SPF and DKIM alongside DMARC, showing you whether the underlying authentication is ready to support a policy upgrade. If you are still building or fixing your SPF record, the SPF Builder keeps lookup limits visible. For DKIM, the DKIM Discovery tool checks selectors and published keys.
Independent references: Review RFC 7489 for the authoritative DMARC specification and Google Email Sender Guidelines for current enforcement expectations from the largest mailbox provider.
The difference between a domain at p=none and a domain at p=reject is not a configuration detail. It is the difference between knowing that spoofing happens and actually preventing it. Every domain that sends mail should have a concrete plan to reach p=reject, and the pct= mechanism makes that plan safe to execute one step at a time.