Compare observations at the same stage and time
Sender logs, receiver diagnostics and DMARC aggregate reports describe different parts of the mail path. They can disagree without any source being wrong. A sender may record acceptance by the next hop, a receiver may apply a later policy, and a DMARC report may summarize authentication across a reporting interval. Start by naming the event, observer and time basis for each source rather than forcing them into a single delivered-or-failed label.
This article uses primary SMTP, DSN, authentication and aggregate-reporting specifications retained on 8 November 2026. It provides a proposed reconciliation workflow, not an analysis of real logs or reports. The catalogue requires a report-delivery trace from published request through mailbox receipt to parsed observation. No such operational chain has been supplied or executed here.
State what the sender log actually establishes
Record the sending system, queue identifier, recipient, attempt time, destination host and complete SMTP response. Distinguish a temporary refusal from a permanent refusal and an accepted transfer. SMTP acceptance is a transfer-stage observation; it does not establish that the recipient read the message or that it appeared in the inbox. Preserve later queue and delivery-status events separately. RFC 5321
A message with several recipients can have different outcomes. RFC 3464 defines per-recipient DSN information including Action, Status and Diagnostic-Code. Keep those fields associated with the correct recipient rather than copying one refusal onto the entire message or campaign. Also distinguish the reporting system from a remote server quoted in the diagnostic. RFC 3464
Read receiver evidence within its trust boundary
Receiver diagnostics may include policy decisions, accepted-message headers or administrative traces. Establish which system produced the evidence and whether it concerns the same message and route. A forwarded copy can have different authentication results from the original delivery path. Do not combine a direct-path pass with a forwarded-path refusal and call the difference random until the route is understood.
Authentication-Results assertions require a trusted producing context. An arbitrary header inserted outside that boundary can claim any result. Preserve the verifier identity and original-message relationship when using headers to reconcile an incident. If the sender never received the original accepted message, mark that receiver-side evidence unavailable rather than inventing a result from the SMTP text. RFC 8601
Keep aggregate reports distinct from message traces
RFC 9990 defines DMARC aggregate reporting, including report metadata, policy context and grouped observations. Such a report is not a complete per-message delivery log. Its counts and interval can help identify an authentication pattern, but they do not automatically identify a particular business message, prove inbox placement or cover every receiver. Keep the report's own time range and identifiers alongside the parsed data. RFC 9990
DMARC evaluates aligned authentication and policy under its protocol rules. A report showing authentication success can coexist with a content or recipient-policy rejection. Conversely, a receiver can handle an authentication failure according to local policy or other evidence. Reconciliation should preserve the distinct questions rather than assume that a DMARC result is the final delivery disposition. RFC 9989
Trace reporting as a separate delivery path
A missing aggregate report needs its own investigation. The proposed chain begins with the published reporting request and any applicable external-destination authorization, continues through report generation and transport, then reaches the collection mailbox or service and parser. A correct request does not prove that the collector received a usable report. A received attachment does not prove that the dashboard parsed and attributed it correctly. RFC 9990 report discovery and delivery
Retain the original report file, receipt metadata and parser outcome under appropriate access controls. Record whether a failure occurred during receipt, decompression, schema handling, deduplication or domain attribution. These are proposed investigation stages, not findings about a particular collector. Do not infer that reporting is universally broken because one dashboard is empty, or that it is universally complete because one report arrived.
Normalize time and identifiers without destroying evidence
Choose a common time zone for comparison while preserving each source's original timestamp and interval. A daily aggregate interval and a local-time queue log can appear to fall on different dates. Record transformations explicitly. Keep message identifiers, queue identifiers and report identifiers separate; they belong to different systems and should not be treated as interchangeable keys.
Where direct correlation is impossible, state the level of inference. A sending IP, domain and interval may support a population-level comparison without proving a one-to-one message match. Do not manufacture a match from similar subject lines or counts. If a supplier needs exact identifiers, approve the necessary disclosure and preserve an untouched internal original before preparing a redacted copy.
Original reconciliation worksheet
Use this proposed worksheet to distinguish evidence, interpretation and missing links. It is not populated with a real message or report.
- Sender event: queue identifier, recipient, route, timestamp and exact response.
- Receiver event: trusted producer, message reference, policy result and observation time.
- Aggregate event: reporting organization, report identifier, interval, policy domain and grouped counts.
- Reporting request: published location, observed value and applicable destination authorization evidence.
- Collection trace: mailbox or endpoint receipt, retained file and transport metadata.
- Parsing trace: schema outcome, deduplication, attribution and dashboard import status.
- Correlation: exact match, population-level inference or unresolved relationship.
- Conclusion: supported failure stage, next owner and limits of the finding.
A useful reconciliation can conclude that sender acceptance and aggregate authentication success are established while inbox placement remains unknown. Another can identify a collector parsing problem without blaming the sending domain's authentication. These narrower statements are more actionable than a single red or green delivery label.
Fictional example: the report arrives but the chart stays empty
Fictional Lantern Ledger sees successful sender handoff logs and expects its DMARC dashboard to populate. In the invented exercise, the collection mailbox has a report attachment, but the proposed parser review has not yet established whether it was imported. The team should not change DNS merely because the chart is blank; the missing link may be between receipt and parsed observation.
The planned investigation would preserve the attachment, record its report identifier and interval, and inspect the authorized collector's processing result. It would also keep the original business-message delivery question separate from report transport. Lantern Ledger is fictional: no mailbox, log, attachment or parser was accessed, and no failure has been verified.
Close the precise evidence chain
After a real authorized correction, retain a new observation at the previously failing stage. If the parser now imports a report, that closes the parsing issue for the observed file, not every delivery or authentication problem. If a later SMTP attempt succeeds, it does not establish report collection or recipient reading. Keep each outcome tied to its evidence and scope.
The required report-delivery trace remains open. Human SME, source applicability, production routes, visual accessibility and owner release also remain open, and publication readiness is false. This manuscript supplies a structured comparison method rather than operational proof or a universal deliverability conclusion.