DMARC record still carries a pct tag
What this check looks for
Your policy is enforcing, but it still carries the old pct tag asking receivers to apply it to only some messages. Some mail servers obey that and let the rest through as if you had no policy; newer ones ignore the tag. Either way it is not doing anything useful.
Why it matters
Wherever the tag is still honoured, an attacker only needs the messages that fall outside the sample. Partial enforcement was always a rollout step rather than a destination, and the 2026 revision of DMARC removed the tag that expressed it.
When the check passes, your report says: “The policy applies to all mail, with no pct tag holding it back”.
What it costs your score
When this check fails it removes 6 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.
It shares the email-auth.dmarc family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 6 points
- Family cap
- email-auth.dmarc · 40
- Category
- Email authentication
- Module
- Email dmarc
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Delete the pct tag so the policy applies to all of your mail everywhere.
Receivers that still honour pct leave that share of spoofed mail unaffected, and receivers that follow RFC 9989 ignore the tag — so you cannot predict which of your mail is enforced.
Confirm the aggregate reports show no legitimate sender failing in the enforced sample. Removing the tag raises enforcement to 100% at the receivers that were sampling, so any sender still failing alignment will start being quarantined or rejected there.
Delete the
pct=‹pct›tag from the record. Do not replace it withpct=100: RFC 9989 removed the tag, and full application is what you get when it is absent.
How to confirm it worked
dig +short TXT _dmarc.‹domain› — the record must not contain a pct tag
Watch a week of aggregate reports for a legitimate source that has started failing.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
_dmarc.‹domain› sets p=‹policy› with pct=‹pct›. RFC 7489 §6.3 defined pct as the percentage of messages the policy is applied to, the remainder receiving the next lower policy; RFC 9989 removed the tag entirely (Appendix A.6) and a receiver following the current specification ignores it. Deployed receivers are split between the two behaviours, so pct=‹pct› now means your policy is applied in full by some receivers and to ‹pct›% of messages by others. Either way the tag no longer does anything you can rely on.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other email dmarc checks
- DMARC reports are sent to an unauthorised external domain
- DMARC requests forensic reports (ruf)
- Subdomain has no DMARC record and inherits the parent policy
- More than one DMARC record published
- No DMARC record published
- DMARC record requests no aggregate reports
- DMARC policy is p=none (monitor only)
- Subdomains are exempt from an enforcing DMARC policy
- DMARC record has a syntax error
- DMARC is in test mode, so the policy is not applied