Definition
DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy graduation is the progressive process of transitioning a domain's DMARC policy from the least restrictive enforcement level (p=none) through the intermediate level (p=quarantine) to the most restrictive level (p=reject), incorporating subdomain policy staging along the way. The graduation process is designed to prevent the common mistake of adopting an overly restrictive DMARC policy before all legitimate sending sources are properly authenticated, which would cause legitimate emails to be rejected or quarantined. A carefully managed graduation typically spans three to six months, though domains with complex sending infrastructure, numerous third-party senders, or fragmented email programmes may require longer to achieve full enforcement.
The graduation begins with p=none (monitoring only), during which the domain owner receives aggregate and forensic DMARC reports from participating mailbox providers but takes no enforcement action against authentication failures. This monitoring phase is critical for identifying all legitimate email sources that send from your domain, including known and unknown senders, shadow IT deployments, and third-party platforms used by different business units. After comprehensive sender discovery and authentication remediation, the domain progresses to p=quarantine, where authentication failures are directed to the spam or junk folder rather than rejected outright, providing a safety net for any undiscovered legitimate senders. The final step to p=reject instructs receiving mail servers to hard-bounce any email that fails SPF or DKIM alignment with the sending domain. Subdomain policy staging using the sp= tag allows organisations to apply different DMARC policies to subdomains during the parent domain graduation process, enabling subdomains used for testing or high-risk sending scenarios to remain at a lower enforcement level while the primary domain moves to p=reject.
Best Practices
Begin with p=none and a reporting address (rua=) to receive aggregate DMARC reports from mailbox providers. During this phase, systematically analyse DMARC aggregate reports to discover every IP address and sending platform sending email from your domain. Configure reports to be delivered to a DMARC analysis platform that can parse and visualise the XML report data, making sender discovery feasible at scale rather than requiring manual report review.
Create a comprehensive sender inventory from DMARC report analysis that includes: each sending source's IP address range, the volume of email sent from each source, SPF and DKIM authentication status for each source, and the business owner responsible for each sending platform. Prioritise remediation of high-volume senders first, as these represent the greatest risk to deliverability if they fail authentication after policy enforcement progresses.
Move to p=quarantine only after you have verified that all sending sources discovered during the p=none phase have implemented either SPF authentication (where the sending domain matches your domain) or DKIM alignment (where the d= domain in the DKIM signature matches your domain). Allow at least two weeks at p=none to gather sufficient DMARC report data for a complete sender inventory — longer if your sending volume is low or if you send infrequent campaigns that may not appear in reports quickly.
Progress to p=reject after maintaining p=quarantine for a minimum of four weeks with confirmed low authentication failure rates, ideally below 1% of total email volume. During the quarantine phase, monitor DMARC reports daily for the first week, then weekly, to identify any senders that appeared during quarantine and require authentication remediation before the move to p=reject. Document the failure rate baseline and establish a formal go/no-go decision checkpoint for the p=reject transition.
Apply subdomain policy staging using the sp= tag in your DMARC record, setting subdomain policies to p=none or p=quarantine while the parent domain graduates to p=reject. This staged approach protects subdomains used for testing, staging environments, or delegated sending that may not yet have full authentication coverage. As each subdomain's sending sources are verified and authenticated, progress that subdomain's policy through the same graduation stages independently.
Related Glossary Terms
Bounce Classification
Bounce classification uses SMTP codes (550, 551, 552, 553, 554, 450, 451, 452) and enhanced status codes to categorise permanent and transient delivery failures.
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
DMARC Policy Tags
DMARC DNS record tags including v, p, sp, rua, ruf, pct, adkim, aspf, fo, rf, and ri control authentication policy, reporting, and alignment enforcement.
Email Active Subscriber
An active email subscriber has opened or clicked an email within a defined recency period, typically 30-90 days by industry. Active subscriber rate of 40-60% is typical for healthy email lists.
Email Authentication Failure
Email authentication failures occur when SPF, DKIM, or DMARC checks fail, causing messages to be rejected, spammed, or quarantined by receiving mailbox providers.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Frequently Asked Questions
At p=none, receiving mail providers deliver DMARC reports to the domain owner but take no enforcement action — authentication failures are delivered normally. At p=quarantine, authentication failures are placed in the recipient's spam or junk folder. At p=reject, authentication failures are hard-bounced and never reach the recipient's inbox or spam folder. Each progressive level provides stronger protection against email spoofing but carries increasing risk of blocking legitimate emails.
The monitoring phase (p=none) typically takes two to four weeks to gather sufficient aggregate report data for sender inventory. The quarantine phase typically takes four to eight weeks to confirm authentication compliance. The full graduation from p=none to p=reject generally takes three to six months depending on the complexity of your sending infrastructure and the speed at which business units can remediate their sending sources.
The sp= tag allows you to set a separate DMARC policy for all subdomains of your domain independently from the parent domain policy. This enables staging: you can set sp=none for subdomains while moving the parent domain to p=reject, then graduate each subdomain's policy individually as their sending sources are authenticated. This prevents subdomains used for testing or specialised sending from disrupting your primary domain's graduation.
Establish a process for receiving and investigating false positive reports from internal teams and external recipients. Common false positive causes include: third-party senders not yet authenticated, shadow IT deployments, shared hosting platforms, and legacy systems with hardcoded from addresses. Each false positive should be traced to its sending source, the source should be authenticated, and the source should be added to your sender inventory for ongoing monitoring.
A standard timeline: weeks 1-4 at p=none for sender discovery and report analysis; weeks 5-8 for sender remediation and authentication implementation; weeks 9-12 at p=quarantine with monitoring and any final remediation; weeks 13-16 verifying quarantine stability and failure rate below threshold; weeks 17-20 move to p=reject with ongoing monitoring. Complex environments with multiple business units, international subsidiaries, or numerous third-party platforms may require four to eight months total.