Under RFC 9989 §4.7, a DMARC policy of p=none expresses no domain-owner handling preference for DMARC failures. When reporting is configured and reviewed, it creates an opportunity to learn which services use the domain, where legitimate messages fail and what a policy change might affect.
Monitoring becomes useful through investigation. Reports need to reach a collection system, sources need owners and unresolved failures need decisions. Elapsed time or one high pass percentage cannot establish that every important service has been covered.
Make reporting collection observable
For a domain beginning monitored deployment, an illustrative policy is:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comThe example assumes the intended _dmarc publication and a working same-domain collection address. If the domain already has a stronger approved policy, do not weaken it just to match an example. Use the record workflow to verify the actual configuration.
Following RFC 9990 §4 for external permission and RFC 9989 §5.3.8 for receiver reporting, check the reporting destination, any required external-destination permission, mail delivery and parsing. Retain reporter identity, period and relevant configuration history. Receiving reports from one provider demonstrates a working path for that observation; it does not prove universal coverage.
Classify services and preserve uncertainty
For each meaningful source pattern, investigate the application, customer-specific account or route, visible From domain, envelope identity, signing identity and owner.
Use clear working categories:
- Category: Approved service with the expected aligned path; Next action: Keep ownership and monitor changes
- Category: Approved service failing authentication or alignment; Next action: Correct and test the supported configuration
- Category: Legitimate indirect route; Next action: Analyse forwarding, modifications and receiver handling
- Category: Unknown source; Next action: Preserve uncertainty and investigate
- Category: Confirmed unauthorised use; Next action: Record the supporting evidence and response
A cloud provider name, ASN or country is not enough to approve a sender. Equally, a failed row is not enough to declare every associated message malicious.
Worked example: a quiet window misses payroll
Consider an illustrative organisation that reviews ten days of employee and marketing mail. The reports look healthy. A monthly payroll service has not sent during that period, and its signing configuration has not been tested.
The correct conclusion is that the observed streams looked healthy over those ten days. It is not that the entire domain is ready for a more restrictive policy.
The team can investigate and test the payroll route directly, identify any other periodic services and expand its evidence. Observation windows should reflect the actual business cycles and the relevant interoperability considerations, rather than a universal number chosen from a dashboard.
Choose a policy that fits the domain
The decision is broader than a pass-rate target. Require critical-service coverage, accountable owners, an assessed indirect-mail population, resolved high-impact failures and a recovery process.
RFC 9989 §7.4 explicitly cautions against p=reject for general-purpose email and discusses domains whose users participate in Internet mailing lists. Its interoperability guidance includes specific observation and comparison steps for those domains. Do not replace that guidance with a generic promise that every monitored domain should eventually reach reject.
A tightly controlled transactional sending domain and a domain used for general staff correspondence can have different operating constraints. Separate identity streams where it serves a real governance purpose, while verifying the resulting configuration and actual messages.
Define the evidence for the next decision
An enforcement review should answer these questions with evidence:
- Are the important legitimate services identified, owned and tested?
- Does each affected service have a supported aligned path?
- Have periodic and low-volume flows been considered?
- Are mailing lists, forwarding and other indirect routes understood?
- Is reporting coverage described without treating it as all email sent?
- Are exceptions scoped, owned and scheduled for review?
- Can the team approve, verify and recover from the proposed change?
The decision may be to improve a sender, alter domain separation, continue monitoring or apply a policy suited to the domain's documented use. Keep the reasoning with the change record.
Assign owners to the findings
Ask what the team expects to learn and who will act on the findings. Which services send for the business? Which critical messages fail? Which apparent senders remain unidentified? What evidence will determine the next step?
Include work outside the IT team's immediate view. A monthly payroll notification or annual renewal notice can be important while contributing very little to the overall message total.
Avoid an automatic countdown to a stronger policy. A week with few visible failures can mean healthy sending, incomplete reporting or a service that has not sent yet. Pay for a maintained inventory and closed findings, not simply elapsed days.
Continue monitoring after a policy change
New software, supplier changes, key rotation and DNS edits can create fresh gaps. Continue investigating new senders and legitimate failures after any policy change.
Explain the residual risk to business leaders: receivers retain their own handling choices under RFC 9989 §5.4, and domain authentication does not prevent every lookalike message, account compromise or fraudulent request. For evidence interpretation, use the aggregate-report walkthrough. For a raw-pass failure, use the alignment guide.
The practical takeaway
The output of monitoring should be an owned sender inventory, verified critical routes and a reasoned policy decision. Keep monitoring as the environment changes so a later application, key or gateway change does not quietly reopen the same gaps.
Record the decision and its limits
For the fictional ten-day window, leave monthly payroll as untested rather than marking it healthy. Add its owner, next representative workflow and evidence needed to close the gap. If collection is working but the application never sent, more analysis of the same reports cannot establish its authentication. No reports or payroll tests were collected for this illustration.