Separate the module’s current checks from a complete DMARC policy evaluation. This is especially important when an older warning is interpreted against newer DMARC guidance.

Review the result and settings

1. Open PD Modules → Deliverability → Needs attention and find the DMARC result.
2. Choose How to fix and review the domain, currently observed policy and suggested value.
3. In Settings, distinguish Treat a DMARC policy of none as a problem from DMARC policy to recommend. The first changes finding behaviour; the second changes a generated recommendation.
4. Review Send DMARC reports to before using a suggested record. The module does not establish that the reporting destination is authorised or receiving reports.

Apply current context

The released checker still flags a pct value below 100 and does not evaluate the newer testing tag. The current IANA DMARC tag registry marks pct historic. RFC 9989 replaced the earlier DMARC specification and defines current policy discovery and testing behaviour.

Consequently, do not change a working policy solely to remove a legacy pct warning or assume that a good grade recognises current testing behaviour. The module reads the domain’s queried policy record; it does not implement a complete receiver policy-discovery walk, message authentication or alignment test.

Before changing policy

Review legitimate sender authentication and reporting evidence with the mail administrator. A generated rejecting policy is not proof that all legitimate mail is ready for it. Policy changes and reports can affect real traffic and disclose mail metadata to the reporting recipient.

Recheck the DNS observation after an authorised change, while also reviewing actual mail results. Compare a conflicting warning with the current standard rather than editing DNS merely to improve the score.

See the PD Email Deliverability Blesta guide for related tasks, or explore PD Email Deliverability.