Partial DMARC coverage

It asks receivers to apply the declared policy to the stated share of failing messages, and to treat the remainder as though the policy were less strict.

So a reject policy at twenty-five per cent means three quarters of forged mail is still delivered.

The point is to observe the effect on a slice before committing to all of it, which is a sound idea during a transition.

It applies to messages that fail authentication, not to all mail, so it does not reduce the protection for messages that pass.

Receivers apply it independently, so the share is approximate rather than a precise quota.

The first steps produce visible progress and the last one produces nothing visible at all, because by then the legitimate senders already pass.

Raising the share requires someone to decide the reports look clean, and nobody owns that decision once the urgency has passed.

The configuration keeps working, mail keeps flowing, and no alert fires for a partial policy.

The domain then appears in any tool as having enforcement configured, which removes the last prompt to look at it.

Years later the record still reads as a transition that ended without anyone noticing.

Read the last few weeks of aggregate reports and confirm that every recurring legitimate source passes with alignment.

Ignore the long tail of sources that will never authenticate — that traffic is the reason for the policy, not a blocker to it.

Raise the share in steps if the volume makes you cautious, checking reports between each step.

Remove the percentage tag entirely once you reach full coverage, since its absence means full coverage and leaving it explicitly set invites a future edit to lower it.

Confirm the subdomain policy separately, because a domain at full coverage with no subdomain policy still leaves unused subdomains forgeable.

A policy of reject with no aggregate reporting address, which is enforcement with no way to see what it is catching.

A policy at full coverage on the apex with nothing declared for subdomains, where the inheritance is usually what you want and is worth making explicit.

Strict alignment set during testing and left in place, which rejects mail sent through a provider's subdomain.

Each of these is the same shape of problem: a setting chosen for a transition that outlived it.

Query the TXT record at the DMARC name and read the percentage tag.

No tag means full coverage, which is the target state — its absence is not a defect.

Read the policy tag alongside, since a partial share on a policy of none changes nothing either way.

Check the subdomain tag, which is a separate decision and is frequently absent.

Confirm aggregate reports are arriving, because finishing the rollout without them is guesswork.

`email.dmarc.pct` reports the share the policy is applied to, which is this problem directly.

`email.dmarc.policy` reports the enforcement level, since a partial share only matters where the policy would otherwise act.

`email.dmarc.subdomain` reports the subdomain policy and `email.dmarc.alignment` the alignment modes, which are the neighbouring half-finished settings.

`email.dmarc.rua` reports the aggregate destination, whose presence is what makes finishing the rollout possible.

`email.spoofing_exposure` reflects the combined position across SPF, DKIM and DMARC.

Aggregate reports include the policy that was published when the mail was evaluated, so a report read against a changed record is misleading.

They also report the disposition actually applied, which for a partial share differs between messages from the same source.

That variation is expected and is not evidence of a problem — it is the share being applied independently by each receiver.

What matters in the reports is whether recurring sources pass with alignment, which is independent of the share.

Raising the share therefore changes what happens to failures, and changes nothing about which sources pass.