Name the denominator before calculating a rate
A DMARC dashboard may show a large number of message observations, but that number is not automatically the total population of mail sent by the organization. Aggregate reports describe observations reported by participating receivers for particular intervals. Sender systems describe their own attempts and events. These populations differ in origin, timing, grouping and visibility, so dividing one by the other without a defined reconciliation method can produce a misleading coverage claim.
Start by naming the question. Are you measuring the share of an approved sender inventory represented in reports, the share of known recipient services returning reports, or a relationship between reported counts and sender events for a bounded interval? Each requires a different denominator and different evidence. A generic “coverage percentage” obscures those choices. RFC 9990, section 3.1 and 9.1
Separate reporting participation from ingestion health
A missing report can reflect a receiver’s reporting behavior, lack of relevant traffic, delivery problems, processing delays or an ingestion defect. An empty dashboard interval does not distinguish those possibilities. Track the reporting relationship and the collector pipeline separately so an analyst can see whether a file was expected, received, rejected, delayed or simply not evidenced.
Preserve report sender, reporting organization, interval, identifier and processing status. Record any known delivery or parser failure without translating it into zero observed authentication failures. An excluded artifact changes the analyzed population and belongs in an error or exclusion log. If a later report fills the gap, retain the dataset revision rather than silently rewriting the earlier conclusion.
No universal reporting-completeness guarantee is assumed here. The proposed review must use the actual receiver population and available collection evidence. A report from one mailbox provider cannot establish the behavior of other receivers, and repeated observations from a dominant provider should not be mistaken for broad population diversity.
Choose compatible sender-side evidence
Define which sender event belongs in the comparison. An application request, provider acceptance, attempted delivery, receiving-server acceptance and final failure are not interchangeable events. Retries, multiple recipients and application resubmissions can create several records for what a business user thinks of as one message. Preserve the event semantics and aggregation rule before reconciling counts.
The retained SendGrid event reference illustrates the distinction: processed means the provider received the message and it is ready to be delivered; delivered concerns delivery to the receiving server, not proof of inbox placement or human reading. This is a provider-specific example, not a universal event schema. Other systems require their own current definitions. SendGrid Event Webhook Reference
Keep original timestamps and a documented normalized time basis. A report interval and an application’s calendar-day total may not align. Late-arriving reports, queue retries across a boundary and changed stream classifications should be visible in the reconciliation rather than absorbed into a fabricated correction factor.
Map domains and routes without assuming perfect joins
Aggregate observations may not contain the same transaction identifiers as sender logs. Avoid promising a one-to-one message join when the data supports only grouped comparison. Map source addresses, authentication domains and policy context to owned routes with stated confidence, and preserve shared-infrastructure ambiguity. A provider brand alone does not prove which customer account generated the observed traffic.
Keep raw SPF or DKIM results distinct from DMARC alignment. A rate calculated from all raw SPF passes does not necessarily measure aligned authentication coverage for the visible From domain. The core specification’s alignment rules determine which identity relationship matters to that conclusion. An unknown route should remain unknown rather than being added to the approved population merely to improve the rate. RFC 9989, section 4.4
Reconciliation worksheet and dataset contract
Create a dataset contract listing source systems, extraction method, versions, interval boundaries, event definitions, included streams, receiver scope, deduplication rules and exclusions. Retain immutable source references or hashes and the transformation steps needed to recreate the analyzed dataset. If a field cannot be retrieved, state its absence and the conclusion that becomes unsupported.
The worksheet should contain the reporting population, sender population, overlap assumptions, unmatched groups, late data and excluded artifacts. Provide counts only when actual evidence exists. Separate unknown coverage from measured noncoverage. A report that cannot be mapped to an approved route should not be silently dropped, but it also should not automatically increase the count of legitimate mail.
Acceptance requires another analyst to reproduce the population definition and obtain the same bounded comparison from the same dataset version. A chart can summarize that comparison, but it should disclose material gaps and the last complete interval. A higher observed authentication rate is not necessarily evidence that total organizational coverage improved if the reporting mix changed.
Fictional diagnosis: a quieter dashboard after a pipeline gap
Imagine a fictional organization whose collector receives reports from several receiver groups. During one interval, a large group’s report fails parsing and is excluded. The remaining reports show fewer failures. No actual dataset or parser execution was used for this example; the situation is invented to illustrate denominator risk.
The analyst should not announce improved authentication merely because the surviving records look healthier. The analyzed population changed. The appropriate output is a limited result for the retained receiver groups plus an explicit collection-quality gap. Sender-side events may help establish continued activity toward the missing group, but they do not reconstruct its unreceived authentication observations.
If the report is later recovered under an authorized process, the dataset should receive a new version and the comparison should be recalculated. Preserve both the initial limited conclusion and the revised one. This makes the change explainable and prevents an apparent trend from being manufactured by silent backfilling.
Original evidence and release boundary
The catalogue requires a versioned dataset, query method and error/exclusion log that another analyst can reproduce. This manuscript supplies a method and fictional example only. No sender logs, reports, recipient lists or live queries were collected, and no coverage percentage is claimed.
Original evidence, human review, source applicability, production routes, visual accessibility and owner release remain open. Before operational publication, obtain authorized data, minimize unnecessary identifiers and confirm the event definitions for every included system. The final conclusion should state the observed population and its limits rather than imply that aggregate reporting is a complete census of all email sent.