A customer operating report should explain what the service did, what the evidence covers and what the customer must decide next. An agent can assemble the report, but it should not turn incomplete observations into a guarantee or infer permission to send the report from permission to draft it.
Define the reporting contract
State the customer, domain scope, period, service responsibilities and known exclusions. Identify who owns DNS approval, sender ownership decisions, incident response and report sign-off. Separate the provider's monitoring work from systems and receivers outside its control.
RFC 9990 aggregate reports summarize participating receiver observations. Report coverage accordingly rather than claiming all customer mail was observed. Use an approved service register as the service-coverage denominator and list quiet or untested services separately. Show authentication outcomes independently from delivery outcomes.
Carry the lifecycle into the report
A proposed reporting lifecycle can cover intake, domain and service inventory, implementation approval, verification, monitoring, escalation, periodic reporting and exit. For each stage, name the responsible role, evidence produced and completion condition. This is a recommended checklist, not a supplied runbook, contractual service target or executed customer operation.
At intake, the customer owner confirms scope. At implementation, a named DNS approver accepts an exact diff. At monitoring, the operator records daily ingestion status and assigns material failures. At exit, authorized operators reconcile retained records, export agreed evidence and revoke access through an approved plan. Do not automatically remove shared DNS dependencies on termination.
Calculate metrics with visible denominators
Suppose a hypothetical report covers four registered services during one declared interval. Three have usable observations and one incident notifier is quiet, giving observed-service coverage of 3/4 or 75%. In the deduplicated received-report population for that same interval, assume 200 message observations, of which eight fail DMARC: the observed failure rate is 8/200 or 4%. This is not a measure of all mail sent, unique customers or business delivery.
The quiet service remains unknown, not healthy. Ask its owner for the scheduled activity or an authorized route test. A pending DNS change belongs under decisions awaiting approval, not completed work. These are stated inputs and hand-worked arithmetic, not a generated report or executed completeness check. Before sharing an actual report, verify period metadata, action owners and the limits of each denominator.
Review before sharing
Have the operator verify factual claims and the customer-facing owner review commitments. State evidence gaps, ageing exceptions and decisions needed using plain language. Do not infer that a passing aligned signature establishes business approval; RFC 9989's authentication result serves a different purpose.
Keep sensitive message content and credentials out of the report. Share only through the authorized recipient and access scope. This article supplies a reporting pattern, not an accepted customer runbook or measured service performance. It makes no product-capability claim and does not authorize delivery to any external recipient.
The final report should make the next action easier without overstating what the service can control.
Primary reading: RFC 9990 DMARC Aggregate Reporting, RFC 9989 DMARC, OWASP LLM06 2025 Excessive Agency.