A useful monthly authentication report explains what was observed, why it matters and who will act. A large pass percentage without a denominator or reporting boundary can be more misleading than a small set of well-explained exceptions. Start with the customer's operating scope, not a dashboard export.
Define the reporting population
State the period and timezone, covered domains, report sources and collection cut-off. Distinguish the period messages were evaluated from the time their reports were received. Late arrivals may change a historical total, so version a report when issuing a correction rather than quietly replacing its numbers.
Use RFC 9990 to interpret aggregate report counts and authentication results. Counts represent reported observations, not unique people, delivered messages or the organization's complete outbound traffic. Avoid adding overlapping or duplicate reports twice. Retain the report identity, reporter, domain, period and payload fingerprint so an apparent increase can be investigated.
Calculate a metric someone can audit
Define an aligned-message fraction as aligned observations divided by all included observations, with the exact inclusion rules stated. Do not average percentages across sources without their counts. Separate approved sender failures, unknown sources and expected indirect-flow effects. An unknown source is a triage category, not automatic proof of attack or permission to authorize it.
Suppose a normalized observation dataset includes 100 observations whose evaluation times lie within the stated UTC day, of which 80 pass the declared alignment test. The fraction is 80 / 100 = 80%. Ten observations before the window and 50 exactly at its exclusive end are excluded. These are invented individually timestamped inputs, not an actual export or customer result.
Do not assume raw aggregate reports contain per-message timestamps that permit this same slicing: their date range describes the report interval. If a report straddles a reporting boundary, retain it for a stated whole-report inclusion rule or mark the boundary uncertainty rather than inventing a per-message allocation. For duplicates and partial overlap, document the handling and unresolved ambiguity before claiming an exact denominator. RFC 9990 Section 3.5.4 notes that partially overlapping reports cannot clearly be separated by affected message.
Make the action register the center
For each important finding, list domain, sender owner, evidence reference, business impact, proposed action, responsible person and target review date. Include a status such as investigating, awaiting customer approval or verified complete. State what blocks progress. A DNS proposal waiting on approval should not be described as an MSP fix already delivered.
Compare actions with last month's register. Explain which were completed and the evidence that closed them. Carry overdue items forward visibly, including the person who can unblock them. Where the data are incomplete, make collection recovery an action of its own rather than smoothing the chart or assuming the missing period matched the previous one.
Connect the report to the service lifecycle
Agree the review date, service calendar, dependencies and escalation route with the customer rather than presenting an example deadline as an industry requirement. If late data changes a prior fraction, issue a labelled revision with its new cut-off and explain whether any action priority changed. No lifecycle runbook, service commitment or completed customer review is supplied here.
Have the mail administrator verify the evidence population, the customer owner decide business priorities and the security owner review material exceptions. Close the review with accepted next actions and a correction process for late data. RFC 9989 describes authentication and policy evaluation; a monthly authentication result still cannot guarantee inbox placement or the absence of phishing through other domains.