DMARC pct Tag is the policy percentage that tells receivers to apply a DMARC policy to only part of the failing mail for a domain. It is used to roll out enforcement gradually and limit disruption. Defenders should monitor reports carefully, because partial application can hide failing sources if the percentage stays too low for too long.
How the DMARC pct Tag Works
The pct tag is a rollout control, not a separate enforcement mode. It tells receiving systems to apply the requested dmarc policy to only a percentage of messages that fail authentication, which lets a domain owner phase in enforcement instead of switching all at once.
That gradual approach is useful when you are moving from monitoring to enforcement, because mail ecosystems often contain legacy senders, forwarding paths, or third-party services that have not yet been fully aligned.
Why the pct Tag Matters in DMARC Rollouts
pct exists to reduce the operational shock of a policy change. A domain can keep the same underlying DMARC decision, such as quarantine or reject, while limiting how often receivers apply it during an early rollout period.
Used well, it supports change control by letting defenders observe how much unauthorized or misconfigured mail would be affected before full enforcement. Used poorly, it can leave an exposure window open if the percentage stays low for too long.
How Receivers Interpret Partial Policy Application
pct is evaluated by receivers as part of policy handling for failing mail. The intended policy still matters, but only a subset of failures may receive the full treatment, which means some unauthenticated messages can continue to be delivered or filtered less aggressively during the transition.
This makes reporting essential. Aggregate reports and related telemetry help you confirm whether the failing mail you see is expected, whether it comes from known services, and whether the rollout percentage is masking a real authentication problem rather than easing a controlled transition. See the broader guidance in the DMARC, SPF and DKIM Guide.
Common Failure Modes and What pct Does Not Solve
pct does not fix alignment, signing, or SPF authorisation problems. If a sender is failing DMARC because SPF and DKIM are misconfigured, reducing the percentage only reduces the immediate impact, it does not repair the source of the failure.
It also does not guarantee a perfectly random sample across all receivers or all messages, so security teams should treat it as a gradual rollout aid rather than a precision control. If the percentage remains low, failing sources can stay hidden in normal traffic and delayed enforcement can become a governance problem. The Email Identity and BEC Guide shows why partial enforcement still needs active monitoring when spoofing and impersonation are the threat.
Risk and Threat Considerations
pct reduces disruption, but it can also delay visibility into how much unauthorised mail is still reaching recipients. That matters because attackers benefit when a domain treats enforcement as “in progress” for too long, especially where lookalike senders or compromised third-party systems are already in circulation.
Failure mechanism: A low rollout percentage can allow failing messages to continue passing often enough that weak sources, misconfigured vendors, or spoofing activity remain operationally effective while defenders assume enforcement is already working.
Impact: Organisations may miss spoofed mail, underestimate the scale of failing sources, and postpone the cleanup needed before full DMARC enforcement becomes safe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | DMARC rollout depends on reviewing mail authentication reports. |
| Recommendation — Review authentication telemetry to confirm which senders fail before tightening enforcement. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | DMARC pct requires monitoring email authentication events during phased enforcement. |
| Recommendation — Monitor mail authentication failures to verify rollout impact as pct changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | DMARC protects domain sending identity, which is part of identity governance for email senders. |
| Recommendation — Tighten sender identity controls before moving from partial to full DMARC enforcement. | ||
Practitioner Guidance
Why practitioners should care: pct is best treated as a temporary transition setting with an owner, a target end state, and a review cadence. It should shrink as confidence in sender alignment improves, not remain in place by default.
What to watch for: If reports still show failing sources after the rollout begins, investigate whether they are legitimate business senders, forwarding paths, or abusive sources before increasing enforcement pressure. A staged rollout works only when the reporting loop is active enough to tell the difference.
Practitioner takeaway: Use pct to stage change, not to defer it indefinitely.