Publishing p=reject is a policy milestone, not the end of DMARC operations. Sending services change, new applications appear and receivers retain their own handling decisions. Aggregate reporting still helps identify authentication regressions, newly observed sources and differences between the requested policy and reported treatment.
Keep reporting configured and monitored after the policy change. Suitability still depends on domain use: RFC 9989 §7.4 cautions against reject for domains whose users may post to Internet mailing lists and requires reject domains to use valid DKIM rather than rely solely on SPF. The evidence remains bounded by participating receivers and their observations. A reject policy is not proof that every impersonation attempt was blocked or that every legitimate message was delivered.
Read policy, evaluation and disposition separately
References: RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
The published policy expresses the domain owner's requested treatment for mail that fails DMARC. Evaluation asks whether an authenticated SPF or DKIM identifier aligns with the author domain. Reported disposition describes the receiver's reported DMARC-related treatment, with override information where supplied.
These fields should not be collapsed into one status. A record showing p=reject alongside disposition none is not automatically malformed: a message may have passed, or receiver handling may have differed from the requested action. Examine the aligned results and available reason rather than guessing from the policy alone. RFC 9989 preserves receiver discretion, and RFC 9990 defines the aggregate fields.
Watch for legitimate-route regressions
References: RFC 9989 §5.3.5.
Keep a maintained inventory of applications and owners. Compare current observations with their expected identities, and investigate a changed selector, return-path or author domain before users report missing mail. Include low-volume and seasonal routes that can remain invisible for long periods.
Illustrative case: a previously verified billing application moves to a new platform and loses its aligned DKIM signature. SPF still passes under an unrelated service domain. Assume an applicable valid policy and completed checks. Without another aligned passing path, the message fails DMARC in this synthetic example. The useful response is to repair the supported sender identity, not to assume enforcement has made future onboarding unnecessary.
Interpret continuing unauthorized failures
Unauthorized senders may continue to use the domain in From even after enforcement. Reports can show observed failed authentication and receiver treatment for that traffic. Persistent failure volume does not alone prove enforcement is ineffective; a control may be rejecting traffic that continues to arrive.
Conversely, do not count every failure as a confirmed prevented attack. Attribution, intent, receiver coverage and actual handling need evidence. A report count is an observation count, and reported disposition is not a complete downstream delivery audit.
Reconcile exceptions and missing coverage
References: RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
Review records where failing mail received different treatment from the requested policy. Investigate supplied override reasons and relevant forwarding or intermediary behavior. Do not assume every receiver applies the same local policy or that every exception has enough explanation in an aggregate report.
Check the reporting pipeline itself: destination ownership, external authorization where required, ingestion errors and changes in contributing receivers. A silent dashboard after enforcement may reflect a collection problem. Keep a controlled test for critical routes and compare receiver evidence with application logs when investigating delivery.
Maintain a post-enforcement operating rhythm
Assign responsibility for new-sender onboarding, periodic inventory review, DNS changes and report triage. Use an approval and expiry process for any temporary policy relaxation. Verify that the proposed change addresses a supported cause and does not unnecessarily affect unrelated senders.
Close each review with the legitimate routes tested, unknown sources investigated, receiver deviations examined and reporting gaps still present. The objective after p=reject is maintained, explainable authentication coverage. The policy string alone cannot provide that assurance.
Bound the conclusion and next action
For the fictional platform move, retain raw SPF pass under the unrelated service identity separately from missing aligned DKIM. A later supported signing repair must be tested on the affected route. A reported none disposition remains handling evidence, not proof that authentication recovered or an inbox received the message.