DMARC Policy Progression: From p=none to p=reject
DMARC is the policy layer that ties SPF and DKIM together and tells receiving servers what to do when authentication fails. But most organizations set up DMARC at p=none and never advance it. Their DMARC record is technically present, satisfying the checkbox requirements from Google and Microsoft, but it is not actually protecting their domain from abuse.
Moving from p=none to p=reject is a process that takes weeks or months, requires monitoring, and has real consequences if done incorrectly. Here is the complete progression guide.
Understanding the Three DMARC Policies
p=none (Monitor). This policy tells receiving servers to take no action on messages that fail DMARC. The email is delivered normally regardless of authentication results. However, the receiving server generates aggregate reports (if you have configured a reporting address), which give you data on who is sending email as your domain and whether their authentication passes.
p=none is the starting point for every DMARC implementation. It lets you collect data without affecting email delivery. You can see exactly which servers are sending email as your domain, whether they pass SPF and DKIM, and whether any legitimate services are misconfigured.
p=quarantine (Spam Folder). This policy tells receiving servers to quarantine messages that fail DMARC. In practice, this usually means the email is delivered to the spam or junk folder. The message still reaches the recipient, but it is flagged as suspicious.
Quarantine is the intermediate step. It starts protecting your domain from spoofing while giving you a safety net. If a legitimate email accidentally fails authentication, it goes to spam rather than being rejected outright. The recipient can still find it.
p=reject (Block). This policy tells receiving servers to reject messages that fail DMARC entirely. The email is not delivered at all. It bounces back to the sender (or is silently dropped, depending on the receiving server).
Reject provides maximum protection against domain spoofing. If someone tries to send email pretending to be from your domain without proper authentication, the email never reaches anyone's inbox. This is the gold standard for DMARC, but getting here requires confidence that all legitimate sending is properly authenticated.
Phase 1: p=none (Weeks 1-4)
Start with this DMARC record: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The rua tag specifies where aggregate reports should be sent. You will receive XML reports from receiving servers (Gmail, Outlook, Yahoo, etc.) showing all email traffic using your domain in the From address.
During the none phase, your job is to monitor these reports and build a complete picture of your domain's email ecosystem. Look for every service that sends email as your domain. Your email hosting (Google Workspace, Microsoft 365), cold email platforms, marketing tools, CRM systems, transactional email services. Every one of these must pass SPF and DKIM with proper alignment.
Use a DMARC report analysis tool (dmarcian, Valimail, EasyDMARC, or similar) to parse the XML reports into readable dashboards. These tools show you exactly which sending sources pass and fail authentication, making it easy to identify misconfigured services.
Common issues found during monitoring: a cold email platform that was set up without DKIM, a marketing tool that sends through shared infrastructure without SPF alignment, an old SaaS tool that nobody remembers connecting that still sends occasional emails from your domain.
Fix every authentication issue you find. For each sending service, verify SPF include, configure custom DKIM signing, and ensure DMARC alignment. Test each fix by sending emails and checking authentication results in the headers.
Stay at p=none for at least 2-4 weeks. You want at least two full reporting cycles (reports are typically generated daily or weekly) to be confident you have identified and fixed all sending sources.
Phase 2: p=quarantine (Weeks 5-8)
Once you are confident that all legitimate sending passes authentication, advance to quarantine. Update your DMARC record: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=25
The pct tag is your safety valve. pct=25 means the quarantine policy applies to only 25% of failing messages. The other 75% are still treated as p=none. This gradual rollout limits the blast radius if something is misconfigured.
Monitor your reports closely during the first week at pct=25. If any legitimate email is being quarantined, you will see it in the reports and can fix the authentication issue before it affects more traffic.
If everything looks clean after a week at pct=25, increase to pct=50. Wait another week. Then pct=75. Then pct=100. Each step increases the percentage of failing messages that get quarantined, giving you time to catch issues at each level.
At pct=100 quarantine, all messages that fail DMARC go to spam. This is a meaningful level of protection. Spoofed emails using your domain are now being filtered. But the recipient can still find them in their spam folder if needed.
Phase 3: p=reject (Weeks 9-12+)
Moving from quarantine to reject is the most consequential step. Rejected emails are not delivered at all. If a legitimate email fails authentication after you move to p=reject, it will not reach the recipient and you might not even know about it unless the sender reports the issue.
Before advancing to reject, verify that your aggregate reports show 100% pass rate for all legitimate sending sources for at least 2-4 consecutive weeks at p=quarantine with pct=100. Any failures must be investigated and resolved.
Advance using the same pct approach: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=25
Ramp from pct=25 to pct=100 over 2-4 weeks, monitoring at each step. At pct=100 reject, your DMARC implementation is complete. Any email sent as your domain that fails SPF and DKIM alignment will be rejected by receiving servers.
Common Pitfalls in DMARC Progression
Advancing too fast. Jumping from p=none to p=reject without the intermediate quarantine phase and percentage ramp risks blocking legitimate email. Take the time to progress gradually.
Forgetting about subdomains. DMARC policies apply to subdomains by default via the sp= tag. If you have services sending from subdomains (e.g., marketing.yourdomain.com), their authentication must also be configured. If you do not set an sp= tag, subdomains inherit the main domain's policy.
Not monitoring after reaching reject. DMARC monitoring should continue indefinitely, not just during the setup phase. New sending services get added, existing services change their infrastructure, and team members connect new tools. Ongoing monitoring catches these changes before they cause delivery failures.
Ignoring forensic reports. DMARC supports forensic reports (ruf= tag) that provide detail on individual failed messages. These are useful for investigating specific authentication failures but can contain personal data. Some organizations skip forensic reports for privacy reasons, which is understandable, but aggregate reports (rua=) should always be monitored.
DMARC for Cold Email Domains
Cold email domains have simpler DMARC requirements than primary business domains because they typically have fewer sending services. A cold email domain usually sends through only Google Workspace (or Microsoft 365) and one cold email platform.
This simplicity makes DMARC progression faster for cold email domains. With only two sending services to authenticate, you can often complete the entire progression from p=none to p=reject in 4-6 weeks rather than the 8-12 weeks that a complex business domain might require.
For cold email domains, reaching p=reject is especially valuable. If someone tries to spoof your cold email domain (for phishing or spam), p=reject prevents those spoofed emails from reaching anyone. This protects your domain's reputation from being damaged by unauthorized use.
Start DMARC setup at the same time you set up SPF and DKIM for new cold email domains. Do not wait until after warmup. Having proper DMARC in place from day one means your warmup emails carry full authentication, which builds a stronger reputation foundation from the start.
The progression from p=none to p=reject is one of the most impactful things you can do for your email security and deliverability. It takes patience and monitoring, but the end result is a domain that is authenticated, protected, and trusted by mailbox providers. That trust translates directly into better inbox placement for every email you send.
