The DMARC enforcement gap is the most consequential compliance gap of the 2024-2026 era. By June 2026, roughly 75% of Fortune 500 domains have published DMARC records, but only about 35% of those records enforce at p=quarantine or p=reject. Across global internet domains the rate is lower still: approximately 2.5% enforce at p=reject. The gap between "DMARC published" and "DMARC enforced" is where every BIMI deployment stalls, where most domain spoofing prevention fails in practice, and where the slow drift from compliance theatre to actual security tends to get stuck for months or years.
This piece works through the migration framework. The three-stage path (p=none → p=quarantine → p=reject) is well-documented but routinely misexecuted. The most common failure pattern is rushing through quarantine to reject in under 60 days, during which legitimate sending sources get blocked because the operator never identified them in DMARC aggregate reports. The second most common is publishing p=quarantine and stopping there because the early enforcement signal looks acceptable, then sitting at quarantine indefinitely without the additional discipline that p=reject demands. This guide covers what each stage actually does, when to move between them, and the operational signals that mean the migration is safe to advance.
What each policy actually does at the inbound side
The three DMARC policy values produce different behaviour at the receiving mailbox provider. Understanding the difference is the foundation of a safe migration.
At p=none, the receiving provider takes no action based on DMARC alignment failures. Messages that fail DMARC alignment are still delivered, with spam filtering applied normally. The sole purpose of p=none is to collect aggregate (RUA) reports that identify what is sending mail under the domain. The policy is non-enforcing; it is observation only. The aggregate reports are the diagnostic instrument.
At p=quarantine, the receiving provider routes messages that fail DMARC alignment to the spam or junk folder rather than the inbox. The message still arrives at the recipient's account; it just lands somewhere less visible. Users who actively check spam will still find the message. This is the soft-enforcement tier: misaligned mail is degraded but not lost.
At p=reject, the receiving provider rejects misaligned mail at the SMTP layer. The message does not arrive in the inbox, does not arrive in spam, does not arrive at all. The sender receives a permanent SMTP error indicating DMARC rejection. This is the hard-enforcement tier: misaligned mail is lost.
The asymmetry is important. p=none is observation. p=quarantine is degraded delivery. p=reject is non-delivery. The transition from quarantine to reject crosses a hard line: any legitimate sending source that has not been aligned correctly will start producing rejection-class failures the moment reject is published. The migration discipline that matters most is making sure no legitimate source is unaligned at the moment of crossing.
The aggregate report workflow that drives migration
DMARC's discipline is built around the aggregate (RUA) reports that mailbox providers send back to senders during the observation period. The reports arrive as XML files attached to messages sent to the address in the rua= tag of the DMARC record. Each report covers one day of mail from one mailbox provider, summarising every IP that sent mail claiming to be from the domain, whether SPF and DKIM passed, and whether alignment held.
The workflow during the p=none observation period has three parts. The first is collecting the reports, which usually involves either an aggregate report parser (Dmarcian, EasyDMARC, Postmark's DMARC Digests, or PowerDMARC are common choices) or a custom parser if the organisation has the engineering resources. The second is reading the reports for unauthorised sending sources: IPs that are sending mail claiming the domain but that the organisation does not recognise. These are typically either legitimate-but-unknown sources (third-party services the marketing team forgot to mention, vendors signing emails on behalf of the domain) or actual abuse (spammers spoofing the domain). The third is bringing unauthorised legitimate sources into alignment, usually by adding them to SPF, configuring DKIM signing for them, or contacting them to request alignment.
The observation period typically takes between 60 and 180 days to be useful, depending on the complexity of the organisation's mail infrastructure. Smaller organisations with a handful of sending services may identify all sources within 60 days. Enterprises with dozens of marketing tools, internal apps, third-party integrations, and historical legacy senders typically need 120-180 days. Moving to enforcement before the observation period has run its course is the most common cause of legitimate-mail blockage during migration.
A financial-services client migrated DMARC from p=none to p=reject over four weeks in late 2025. The aggregate reports during the four-week period showed 95% of mail passing alignment. The 5% failing was attributed to "spam" and ignored. After p=reject went live, customer statements stopped arriving at recipient inboxes. The 5% was a third-party statement-generation service whose alignment had never been configured. The fix took 11 business days during which thousands of statements were not delivered. The migration should have run longer; the 5% deserved investigation, not dismissal.
The pct tag: gradual enforcement that most senders ignore
DMARC supports a pct= tag that controls what percentage of failing mail receives the published policy. pct=100 (the default) applies the policy to all failing mail. pct=50 applies it to 50%, with the other 50% receiving the next-lower policy (p=quarantine policy applies quarantine to 50% and lets the other 50% through as if at p=none; p=reject policy applies reject to 50% and quarantines the other 50%).
The pct tag is the most underused mechanism in real-world DMARC migrations. Used correctly, it lets a sender publish p=quarantine or p=reject at a low percentage initially, observe the impact, and increase the percentage over time as confidence grows. Used incorrectly (which is most of the time, because it is not used at all), the sender publishes p=quarantine or p=reject at 100% from day one and discovers downstream problems through customer complaints rather than through controlled observation.
A typical staged migration using pct looks like this. Week 1: publish p=quarantine; pct=10. Week 2: observe impact in reports, no significant issues, raise to pct=25. Week 3-4: continue observation, raise to pct=50. Week 5-6: raise to pct=75. Week 7-8: raise to pct=100. Week 12-16 onward: similar staged ramp from p=reject; pct=10 through pct=100. The total migration window is 4-6 months and produces high-confidence enforcement at the end of it.
Subdomain policy: the sp= tag
DMARC distinguishes between the organisational domain policy (the p= tag) and the subdomain policy (the sp= tag). The organisational domain is the registered domain (example.com); subdomains are anything underneath (marketing.example.com, mail.example.com, anything.example.com).
Without an explicit sp= tag, subdomains inherit the organisational policy. A record like v=DMARC1; p=reject; rua=mailto:dmarc@example.com applies reject to both example.com and to every subdomain. This is sometimes desirable and sometimes catastrophic. If marketing has been sending from info@marketing.example.com without DMARC alignment, moving the organisational policy to p=reject blocks the marketing mail along with the apex-domain mail.
The standard pattern for organisations with mixed mail infrastructure is to publish a permissive subdomain policy while moving the organisational domain to reject. A record like v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com applies reject to the apex domain while leaving subdomains at observation only. The subdomains can then be migrated independently as each is brought into alignment.
The trade-off is that sp=none leaves subdomains exposed to spoofing. An attacker can send mail spoofing anything.example.com and it will not be rejected. For organisations where the apex domain is the primary brand vector and subdomains are operational only, the trade-off is acceptable. For organisations where subdomains have visible brand presence (transactional subdomains, customer-facing API subdomains), the trade-off requires more careful handling.
The "p=reject without enforcement" pitfall
A subtle failure mode that DMARC analysis tools sometimes flag: publishing p=reject while also publishing pct=0. The combination produces a record that looks like enforcement at first glance but actually applies the policy to 0% of failing mail. The receiving provider sees the published policy and reports the domain as "enforcing" in adoption statistics, but the practical effect is identical to p=none.
The pattern shows up in two contexts. The first is operators who started a staged migration with pct=0 and never raised it. The second is operators who reverted from a higher pct after an incident but published the reversion as pct=0 rather than as p=quarantine or p=none at a moderate pct. Either way, the published record claims enforcement but provides none of it.
The check is simple: any DMARC record with p=reject should have pct either absent (which defaults to 100) or explicitly set to a non-zero value. Records with p=reject; pct=0 are misconfigurations and should be corrected to either remove the pct tag or set it to the intended percentage.
Decision framework: when to move from quarantine to reject
The transition from p=quarantine to p=reject is the highest-stakes step in the migration. Three signals should be satisfied before crossing.
| Signal | Threshold | What it tells you |
|---|---|---|
| DMARC alignment rate | ≥99.5% across all reporting providers | Almost no legitimate mail is failing alignment |
| Unauthorised source rate | ≤0.1% of reported volume | The remaining failures are likely spoofing, not legitimate sources |
| Observation window | ≥60 days at p=quarantine pct=100 | The data has had time to surface seasonal or low-frequency sources |
| Forensic report review | Forensic (RUF) samples reviewed for the past 30 days | Specific failing messages have been examined for legitimate vs spoofing patterns |
| Subdomain inventory | All known subdomains catalogued and policy-decided | The sp= tag is set deliberately, not defaulted |
| Stakeholder review | Marketing, IT, security teams informed | The decision has organisational coverage in case of post-migration issues |
If all six signals are satisfied, the move to p=reject is low-risk. If any are not satisfied, the safer path is staying at p=quarantine pct=100 for an additional period and addressing the specific signal that is not yet ready. The cost of waiting is bounded; the cost of premature p=reject is unbounded.
What to do when something breaks
Even with careful migration, post-enforcement incidents happen. The standard response sequence is fast and reversible.
First, identify the affected sender. The DMARC report will show which sending source is failing alignment. Either it is a legitimate source that needs to be added to SPF or signed with DKIM, or it is an unauthorised source that should remain blocked. The distinction is made by checking whether the source IP belongs to a service the organisation actually uses.
Second, if the source is legitimate and the fix will take longer than a few hours, temporarily roll back. The fastest rollback is changing p=reject back to p=quarantine. Messages start arriving in spam folders rather than being rejected outright. The legitimate sender's traffic is degraded but not lost, providing time to do the alignment work properly.
Third, once the alignment fix is in place and verified through new aggregate reports showing the source as passing, return to p=reject. The round trip should take days rather than weeks; protracted rollbacks are how migrations get stuck at p=quarantine indefinitely.
The post-migration discipline
Reaching p=reject is not the end of the work. Three ongoing disciplines maintain enforcement.
The first is continuous aggregate report monitoring. Any new sending source that appears in the reports requires investigation: is it legitimate-but-unauthorised, or is it spoofing? Legitimate-but-unauthorised sources need to be aligned. Spoofing sources confirm the enforcement is doing its job. Either way, the data is useful.
The second is alignment maintenance during infrastructure changes. Every time the organisation adds a new sending tool, changes ESP, modifies DKIM keys, or restructures sending subdomains, the change has potential to break alignment. Pre-change verification (sending a test message and confirming alignment) is faster than post-change recovery.
The third is periodic policy review. A DMARC record published two years ago may not reflect current sending patterns. Annual review (preferably as part of broader security review) catches drift between the published policy and the actual infrastructure.
Organisations that hold p=reject sustainably tend to share one operational habit: somebody owns the DMARC posture as a continuing responsibility, not as a one-time project. The role does not need to be large — an hour per week is typically enough for established posture — but it needs to be assigned. DMARC records that lack an owner drift back toward broken alignment within months as sending infrastructure evolves around them.