- DMARC offers three policy levels: p=none (monitor only), p=quarantine (send failures to spam), and p=reject (block failures entirely).
- Starting at p=none is recommended so you can collect reports and identify all legitimate sending sources before enforcing.
- The pct tag lets you gradually apply quarantine or reject to a percentage of failing messages, reducing the risk of blocking your own email.
- Reaching p=reject is a requirement for BIMI eligibility and provides the strongest protection against domain spoofing.
- Google, Yahoo, and Microsoft now require at minimum a published DMARC record for bulk senders, making enforcement a competitive advantage.
Your DMARC policy is the single most impactful decision in your email authentication setup. It tells every receiving mail server on the internet what to do when an email claiming to be from your domain fails authentication. Set it too loose, and spoofing continues unchecked. Set it too aggressively without preparation, and you risk blocking your own legitimate email.
This guide explains each policy level, walks through the enforcement journey step by step, and shows you how to use the percentage tag to make the transition safe and controlled.
What Is a DMARC Policy?
A DMARC policy is defined by the p= tag in your DMARC DNS record. It instructs receiving mail servers how to handle messages that fail DMARC authentication, meaning they fail both SPF alignment and DKIM alignment with the From domain.
A basic DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;The p= tag accepts three values: none, quarantine, and reject. Each represents an escalating level of enforcement against unauthenticated email.
The Three DMARC Policies Explained
p=none: Monitor Only
With p=none, you are telling receiving servers to take no special action on messages that fail DMARC. Failed emails are still delivered normally (subject to other spam filters). The only benefit is that you receive DMARC aggregate reports showing which IPs are sending email as your domain and whether they pass or fail authentication.
| Attribute | p=none |
|---|---|
| Action on failure | None; email delivered normally |
| Security benefit | Visibility only; no spoofing protection |
| Risk to legitimate email | Zero; no mail is affected |
| Best for | Initial deployment, sender discovery, pre-enforcement monitoring |
Think of p=none as the information-gathering phase. You can see who is sending email as your domain and whether they pass authentication, but you are not yet taking action on failures.
Important: A p=none policy does not protect your domain from spoofing. Attackers can still send fraudulent emails that appear to come from your domain, and those emails will be delivered. Many organizations remain at p=none indefinitely, missing the security and deliverability benefits of enforcement.
p=quarantine: Send Failures to Spam
With p=quarantine, messages that fail DMARC authentication are directed to the recipient's spam or junk folder instead of the inbox. The email is still delivered, but it is flagged as suspicious. This provides a meaningful layer of protection while giving you a safety net: if a legitimate email is incorrectly quarantined, the recipient can still find it in spam.
| Attribute | p=quarantine |
|---|---|
| Action on failure | Deliver to spam/junk folder |
| Security benefit | Moderate; spoofed emails are hidden from primary inbox |
| Risk to legitimate email | Medium; misconfigured senders will land in spam |
| Best for | Transitional enforcement after completing sender inventory |
p=reject: Block Failures Entirely
With p=reject, messages that fail DMARC authentication are blocked outright by the receiving server. The email never reaches the recipient in any folder. This is the strongest level of protection and the ultimate goal of DMARC deployment.
| Attribute | p=reject |
|---|---|
| Action on failure | Reject; email is not delivered at all |
| Security benefit | Maximum; spoofed emails are completely blocked |
| Risk to legitimate email | High if poorly prepared; zero if authentication is complete |
| Best for | Full enforcement after thorough monitoring and testing |
Side-by-Side Policy Comparison
| Factor | p=none | p=quarantine | p=reject |
|---|---|---|---|
| Spoofing protection | None | Partial | Full |
| Failed emails delivered? | Yes, to inbox | Yes, to spam | No |
| DMARC reports generated? | Yes | Yes | Yes |
| Risk to your own email | None | Medium | High (if unprepared) |
| BIMI eligibility | No | Yes | Yes |
| Google/Yahoo requirement met? | Yes (minimum) | Yes | Yes |
Using the pct Tag for Gradual Enforcement
The pct= tag is your most important tool for safe enforcement. It tells receiving servers to apply your policy to only a specified percentage of messages that fail DMARC. The remaining messages are treated as if the policy were p=none.
For example:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com;This record quarantines only 25% of failing messages. The other 75% are delivered normally (but still reported). This lets you test the impact of enforcement on a small subset of traffic before committing fully.
Recommended Ramp-Up Schedule
| Week | Policy | pct Value | Action |
|---|---|---|---|
| 1-4 | p=none | N/A | Collect reports, identify all senders, fix auth gaps |
| 5 | p=quarantine | 10 | Test impact on 10% of failing messages |
| 6 | p=quarantine | 25 | Expand if no legitimate mail is quarantined |
| 7 | p=quarantine | 50 | Monitor reports at each stage |
| 8 | p=quarantine | 100 | Full quarantine enforcement |
| 10 | p=reject | 25 | Begin reject enforcement gradually |
| 11 | p=reject | 50 | Continue expanding |
| 12 | p=reject | 100 | Full reject enforcement achieved |
Stay at each stage for at least one full week before increasing. Review your DMARC aggregate reports at every step to confirm that no legitimate sending sources are being affected. If you discover a misconfigured service at pct=25, it is much easier to fix than discovering it at pct=100.
Subdomain Policy: The sp= Tag
The sp= tag controls the DMARC policy for subdomains that do not have their own DMARC record. If omitted, subdomains inherit the parent domain's policy.
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com;This is important because attackers frequently target subdomains. If your main domain is at p=reject but you have not addressed subdomains, an attacker can spoof messages from random-subdomain.yourdomain.com and bypass your enforcement.
Best practice is to set sp=reject on the parent domain and then create separate DMARC records for any subdomains that legitimately send email but need different policies during their own authentication setup process.
What Must Be in Place Before Enforcing
Moving to quarantine or reject without proper preparation will break your own email delivery. Before changing from p=none, confirm these items:
Complete Sender Inventory
Every service, platform, and server that sends email using your domain must be identified. This includes your primary ESP, CRM, helpdesk, transactional email provider, marketing automation tools, and even one-off services like event platforms or billing systems.
SPF and DKIM Alignment for All Sources
Each sending source must pass either SPF or DKIM alignment with your From domain. Configure custom DKIM keys or custom Return-Path domains for third-party services. Verify each one using a DMARC checker.
Monitoring Infrastructure
Have a system in place to receive and analyze DMARC aggregate reports on an ongoing basis. You need to be able to quickly detect if a legitimate service starts failing DMARC after you enforce.
Internal Communication
Coordinate with every team that sends email: marketing, sales, support, IT, HR, and finance. Shadow IT services that send email without IT's knowledge are the number one cause of enforcement-related email disruptions.
Warning: Never jump directly from p=none to p=reject. The quarantine phase with percentage ramping exists specifically to catch misconfigurations before they cause permanent message rejection. Skipping it is the most common cause of DMARC-related email outages.
Benefits of Reaching p=reject
Spoofing Protection
At p=reject, no one can send email that impersonates your domain and have it delivered. This protects your customers, partners, and employees from phishing attacks that exploit your brand identity.
BIMI Eligibility
BIMI (Brand Indicators for Message Identification) requires DMARC at p=quarantine or p=reject before mailbox providers will display your brand logo next to your emails. Gmail, Yahoo, and Apple Mail all support BIMI, making it a visible trust signal in the inbox. See our BIMI setup guide for implementation details.
Improved Deliverability
Mailbox providers view domains with DMARC enforcement more favorably. A domain at p=reject demonstrates a commitment to authentication hygiene, which contributes positively to domain reputation and inbox placement.
Compliance
DMARC enforcement is increasingly required for regulatory compliance. PCI DSS 4.0 mandates DMARC for organizations processing payment data. Government agencies in many countries require p=reject for official domains. Google and Yahoo require at minimum a published DMARC record for bulk senders, with enforcement providing a competitive edge.
Common Pitfalls During Enforcement
Forgotten Sending Services
The most common issue is a SaaS tool or internal system that sends email using your domain but was not included in your authentication setup. When you move to quarantine or reject, these messages start failing. Thorough report analysis during the p=none phase prevents this.
Email Forwarding Breaks
Email forwarding (mailing lists, auto-forwards) often breaks SPF because the forwarding server's IP is not in your SPF record. If DKIM survives the forward intact, DMARC can still pass. For messages forwarded through mailing lists that modify content, ARC provides a chain of trust that helps receivers honor the original authentication.
SPF Record Exceeding 10 Lookups
As you add more services to your SPF record, you may exceed the 10 DNS lookup limit. SPF records that exceed this limit fail entirely, which can cause DMARC failures for all your SPF-dependent senders. Audit your SPF record regularly and use techniques like flattening or subdomain delegation to stay within limits.
Overly Aggressive Rollout
Jumping to p=reject without the quarantine phase, or increasing pct too fast, gives you no safety net. If something is wrong, messages are rejected permanently with no recovery. The gradual approach gives you time to detect and fix issues before they affect all your email.
Start at p=none to collect data. Fix all authentication gaps using DMARC reports. Move to p=quarantine with a low pct value and gradually increase. After weeks of clean quarantine data, transition to p=reject using the same percentage ramp. Monitor continuously because your email ecosystem changes over time.
Maintaining Enforcement Over Time
Reaching p=reject is not the end of the journey. Your email ecosystem evolves as your organization adopts new tools, changes vendors, or acquires new domains. Ongoing monitoring is essential.
- Weekly report reviews: Check for new sending sources, sudden failures, or changes in compliance percentages.
- Vendor onboarding process: Any time a new service needs to send email using your domain, configure SPF/DKIM before it goes live.
- DKIM key rotation: Rotate DKIM keys periodically (at least annually) and update records proactively.
- SPF record audits: Remove includes for services you no longer use to keep your record clean and within lookup limits.
- Subdomain governance: Ensure new subdomains get proper DMARC records and authentication before sending.
Frequently Asked Questions
The receiving mail server rejects the message during the SMTP transaction. The email is never delivered to any folder, including spam. The sending server receives a bounce response indicating the rejection. This is the intended behavior for spoofed or unauthenticated email.
Yes, the minimum requirement from Google and Yahoo for bulk senders is a published DMARC record, which p=none satisfies. However, p=none provides no actual spoofing protection. Moving to enforcement gives you a deliverability advantage and is strongly recommended beyond the minimum compliance threshold.
For small organizations with a few sending sources, 8 to 12 weeks is a realistic timeline. Larger enterprises with complex email ecosystems involving many third-party senders may need 3 to 6 months. The timeline depends entirely on how quickly you can identify and authenticate all legitimate sending sources.
DMARC p=reject blocks emails that fail authentication, which means it stops direct domain spoofing. It does not stop lookalike domains (e.g., y0urdomain.com), display name spoofing, or spam sent from legitimately authenticated sources. DMARC is one layer of a complete email security strategy.
Yes, you can change your DMARC policy at any time by updating the DNS record. Changes typically propagate within minutes to hours depending on TTL settings. If enforcement causes unexpected issues, you can temporarily downgrade to p=quarantine or p=none while investigating, then re-enforce once the problem is resolved.