A useful authentication metric tells an owner what to fix. A high message pass rate can conceal an untested payroll system, and an attractive average resolution time can conceal one severe open incident. Define the population, clocks and closure rules before calculating numbers, then publish the limitations beside the result.
Measure services as well as messages
Define sender coverage as approved in-scope services with current evidence of an aligned pass divided by all registered in-scope services. This is a proposed operational measure, not a DMARC protocol field. In a hypothetical three-service register, billing and newsletter meet the rule; payroll does not have an observation. Coverage is 2/3, or 66.7% when rounded to one decimal place.
Separately report critical-service coverage: billing and payroll are critical, so that measure is 1/2. An aggregate message pass percentage answers a different question and uses a different denominator. RFC 9990 describes aggregate counts, which depend on received reports and their intervals. Do not equate report coverage with all mail sent.
Keep exception clocks honest
An exception record needs the original reason, opening time, owner, evidence, review date and closure test. Use a consistent time zone. Distinguish time since the original exception opened from time since the latest review. Renewing approval should not reset the original age and erase how long the gap has existed.
A separate hypothetical entry is exception E-1 for payroll: opened 2026-10-01 00:00 UTC, reviewed 2026-11-01 00:00 UTC and measured at 2026-11-07 00:00 UTC. Its original age is 37 days. Its reason is a legacy route awaiting aligned signing, and its closure test is a verified route test with a receiver result. Its recent review does not make it six days old for the original-age measure.
Define resolution before timing it
For an incident, distinguish detection, acknowledgement, mitigation and verified restoration. Calculate time to verified resolution only for incidents with a qualifying restoration timestamp, and show open incidents separately. For example, assume incident A was detected at 08:00 UTC and verified restored at 12:00 UTC on the same day: its duration is four hours. Incident B was detected at 00:00 UTC that day and remains open at the 12:00 cut-off: its elapsed age is twelve hours, with no resolution duration yet. Reporting only the four-hour closed-case average would hide the open case.
A policy change or successful API call is not restoration evidence. Under RFC 9989, an aligned authentication result addresses the DMARC test, not application generation or message delivery. Include the business route's acceptance criteria as well as the authentication criterion.
Validate and act on the numbers
All the examples above use stated hypothetical inputs and hand-worked arithmetic, not executed records or operational benchmarks. The 2/3 coverage rounds to 66.7%; critical coverage is 1/2 or 50%. From 1 October to 7 November at the same UTC time is 37 days; from the 1 November review is six days. Neither a fresh review nor an open incident changes the original clock or supplies a restoration timestamp.
Choose targets after understanding business criticality and data availability. Attach an owner and corrective step to each missing critical-service test or overdue exception. Keep historic snapshots so an improved percentage can be explained by restored evidence, genuine scope changes or newly discovered services. Report each kind of change separately rather than rewarding a smaller inventory.