The most important decision when configuring DMARC is choosing the right policy. The p= tag determines what receiving mail servers do with messages that fail DMARC authentication. Too lenient, and phishing emails slip through. Too strict, too soon, and you risk blocking your own legitimate email. This guide explains each policy level and how to deploy them safely.
The Three DMARC Policies
DMARC defines three policy values for the p= tag:
| Policy | Action on Failure | Protection Level | Recommended Stage |
|---|---|---|---|
p=none | Deliver message normally | None (monitoring only) | Initial deployment |
p=quarantine | Send to spam/junk folder | Medium | Testing and gradual rollout |
p=reject | Reject at SMTP level | Full enforcement | After authentication is confirmed |
p=none: Monitor Mode
When the policy is set to none, failing emails are still delivered to the recipient's inbox — exactly as they would be without DMARC. The only effect is that DMARC aggregate reports are generated and sent to the rua= address.
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"When to use: Always start here. Before you can safely enforce a stricter policy, you need to know who is legitimately sending email on behalf of your domain. Aggregate reports reveal all sending sources — your ESP, transactional email service, CRM, mailing lists, and any unauthorized senders — without any risk of blocking legitimate email.
p=none is active. Do not remain at p=none indefinitely. It is a diagnostic starting point, not a security measure.p=quarantine: Spam Folder Enforcement
With p=quarantine, emails that fail DMARC authentication are moved to the recipient's spam or junk folder rather than being rejected outright. The message still reaches the recipient, but is flagged as suspicious.
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"When to use: Move to quarantine once you have analyzed your aggregate reports and are confident that the major legitimate sending sources are properly authenticated. Start with a low pct= value (e.g., 10% or 25%) to reduce risk, then increase as you verify no legitimate email is being quarantined.
Advantages: Recipients can still access quarantined messages if needed, reducing the impact of false positives. It provides real protection against most spoofing while allowing recovery if a legitimate sender is misconfigured.
p=reject: Full Enforcement
With p=reject, emails that fail DMARC are rejected at the SMTP level. The receiving server sends a bounce notification back to the sender. The message never reaches the recipient's inbox, spam folder, or any other mailbox.
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com"When to use: Only move to p=reject when you are confident all legitimate sending sources are properly configured with SPF and DKIM alignment. This typically takes weeks to months of monitoring reports and fixing authentication issues.
Benefits: Maximum protection against spoofing, phishing, and brand impersonation. Google, Yahoo, and other major providers explicitly require p=reject or p=quarantine for high-volume senders.
p=none. However, to meet best practices and protect your domain fully, aim for p=reject.The pct= Tag: Gradual Policy Rollout
The pct= tag specifies the percentage of DMARC-failing messages to which the policy is applied. The default is 100 (all failing messages). Using a lower percentage allows you to gradually increase enforcement while monitoring for issues.
# Apply quarantine to 10% of failing messages
"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com"
# Increase to 50%
"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com"
# Full enforcement
"v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com"Messages that fall outside the pct= percentage are treated as if the next lower policy applies. For p=reject; pct=50, 50% of failing messages are rejected and 50% are quarantined.
The sp= Tag: Subdomain Policy
By default, the p= policy applies to the root domain and all subdomains. The sp= tag allows a separate policy for subdomains.
# Root domain at reject, subdomains at quarantine
"v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"This is useful when your root domain is fully locked down but some subdomains are used for bulk sending or third-party services that you haven't fully authenticated yet.
Recommended DMARC Rollout Timeline
| Stage | Policy | Duration | Goal |
|---|---|---|---|
| 1. Monitor | p=none | 2–4 weeks | Collect reports, identify all senders |
| 2. Soft enforcement | p=quarantine; pct=10 | 1–2 weeks | Test quarantine on small percentage |
| 3. Increase coverage | p=quarantine; pct=50 | 1–2 weeks | Expand while monitoring reports |
| 4. Full quarantine | p=quarantine; pct=100 | 1–2 weeks | Confirm no legitimate email affected |
| 5. Full enforcement | p=reject; pct=100 | Permanent | Maximum protection |
Frequently Asked Questions
What happens to legitimate email if I set p=reject too early?
Legitimate email that fails DMARC (due to misconfigured SPF/DKIM or unauthenticated third-party senders) will be rejected and bounce. Recipients will never see the message. This is why careful monitoring and fixing authentication issues before enforcing reject is critical.
Does p=none do anything useful?
Yes — it enables DMARC reporting. Even though no policy is enforced, you receive aggregate reports showing who is sending email on behalf of your domain. This information is essential for safely deploying stricter policies.
Can I go directly to p=reject?
Technically yes, but it is risky unless you have already verified that all your legitimate sending sources pass SPF and DKIM with proper alignment. Skipping the monitoring phase is a common mistake that results in legitimate email being blocked.
How do I check my current DMARC policy?
Use the ShowDNS DMARC Lookup tool or run dig _dmarc.yourdomain.com TXT +short from the command line.