The DMARC pct tag lets a domain owner apply a policy to only a percentage of failing messages. It is used to roll out enforcement gradually and reduce the risk of blocking legitimate mail too quickly. Defenders should raise the percentage carefully while reviewing reports, because partial enforcement still leaves some spoofed mail untreated.
What the pct tag actually controls in DMARC
The pct tag does not change the underlying dmarc policy choice. Instead, it limits how often that policy is applied to messages that fail DMARC evaluation. In practice, it gives domain owners a rollout dial, so they can move from monitoring to enforcement in smaller steps rather than switching all failing mail to quarantine or rejection at once.
That matters because DMARC policy is only useful if it is enforceable without breaking legitimate mail flows. A low pct value can protect users from immediate spoofing exposure while still allowing the sender to observe whether real mail paths are being impacted by misaligned SPF or DKIM results. A higher value narrows that gap as confidence improves. DMARC, SPF and DKIM Guide
How partial enforcement behaves in the real world
The pct tag is best understood as a probabilistic enforcement control, not a message-by-message trust decision. If a message fails DMARC and the policy is p=quarantine or p=reject, only the configured percentage of those failures should be treated according to that policy. The rest may continue to pass through normally, which is why pct can reduce rollout risk but cannot be treated as full enforcement.
That partial behaviour also means attackers may still succeed during a staged rollout. If pct is set below 100, some spoofed messages can escape the intended treatment even though the domain has technically enabled an enforcement policy. This is why pct is useful for gradual adoption, but weak as a long-term steady state once the domain is ready for full enforcement. For teams working through staged rollout, the safest approach is to pair pct increases with steady monitoring of aggregate reports and alignment failures. Email Identity and BEC Guide
How to use pct without creating avoidable mail risk
The practical value of pct is that it lets a sender test enforcement against real traffic patterns. That makes it useful when a domain has multiple sending systems, third-party mail vendors, or legacy flows that have not yet been aligned cleanly. In those cases, jumping straight to full enforcement can create unnecessary delivery failures, support tickets, or business interruption.
At the same time, pct should not be treated as a substitute for fixing alignment problems. If legitimate sources still fail DMARC, increasing pct too quickly simply spreads the failure across more traffic. The intended workflow is to stabilize SPF and DKIM alignment first, then increase enforcement in controlled increments. The staged rollout guidance in the DMARC, SPF and DKIM Guide reflects that same operational sequence.
Risk and Threat Considerations
Using pct lowers rollout blast radius, but it also leaves a window where spoofed messages are still allowed through. That means the setting is a transition control, not a complete anti-impersonation control. If an organisation leaves pct low for too long, it can create a false sense of enforcement while the attack surface remains partially open.
Failure mechanism: An attacker benefits when the domain is only partially enforcing DMARC, because some percentage of failing spoofed messages will still be treated less strictly than the final policy intends. Operationally, the same weakness can hide lingering alignment defects, making the rollout appear safer than it is.
Impact: Users may still receive a meaningful share of spoofed mail, and defenders may delay full enforcement while believing the policy is already doing most of the work. That can prolong business email compromise exposure and slow the move to reliable rejection of unauthenticated mail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-10 — Integrity of Information | DMARC pct affects integrity of email identity signals and accepted messages. |
| Recommendation — Tune mail enforcement to preserve message integrity while gradually tightening policy. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | DMARC rollout depends on managing authentication material and related email trust signals. |
| Recommendation — Verify email authentication material before raising enforcement percentages. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | DMARC rollout often accompanies broader email identity controls where leaked mail auth material matters. |
| Recommendation — Audit mail authentication material and rotate exposed secrets before stricter enforcement. | ||
| MITRE ATT&CK | T1586 — Compromise Accounts, identities or email systems | DMARC exists to reduce abuse of email identity and impersonation paths. |
| Recommendation — Map spoofing and impersonation attempts to email-abuse techniques and monitor for them. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | DMARC is a key email protection control used to reduce impersonation risk. |
| Recommendation — Harden email protections and tighten enforcement as legitimate senders are validated. | ||
Practitioner Guidance
What to verify: Increase pct only after checking that the legitimate sending population is stable under the intended policy path. The useful question is not whether DMARC passes in general, but whether your known mail streams stay aligned when enforcement pressure rises.
Decision rule: If reports show recurring failures from legitimate systems, hold pct steady and fix alignment before increasing it. If failures are limited to unauthorised or unexpected sources, raise pct in measured steps so you can distinguish control effectiveness from collateral delivery risk.
Practitioner takeaway: pct is a rollout control, not an end-state control, so treat it as a temporary bridge toward full enforcement rather than proof that spoofing risk has been eliminated.