Approval answers a different question
An organization may approve a supplier to send newsletters, receipts or operational notices. That business decision establishes an intended relationship; it does not prove that every message claiming the supplier’s identity came from the approved account or that its authentication configuration is correct. A dashboard label such as known sender should therefore be treated as inventory context, not a replacement for technical evidence.
Start with the exact product, account and route that the owner approved. A single vendor may send through default domains, custom domains, delegated infrastructure and several distinct workflows. The report row being investigated must be mapped to one of those routes with an explicit confidence level. A familiar IP range or brand name alone is insufficient to make the mapping definitive. DMARC evaluates aligned authentication, not a business allowlist. RFC 9989, section 4.4
Read the identities before deciding what failed
DMARC uses the RFC5322.From domain as the reference for alignment with successful SPF or DKIM authentication. A raw SPF pass on a supplier’s envelope domain does not necessarily align with the visible From domain. Similarly, a valid DKIM signature can use a signing domain that is not aligned. Explain raw protocol success and DMARC alignment in separate fields rather than labeling the whole message authenticated without qualification.
A DMARC pass can be supported by an aligned passing mechanism; it does not require every observed authentication check to pass. Conversely, a sender can be legitimate and still fail DMARC because its configuration or intermediary handling prevents aligned authentication. The review should identify what is known about SPF, DKIM and alignment individually before recommending a DNS or supplier-side change. RFC 9989, section 4.4 and 5
Treat reports as observations with limits
Aggregate reports provide grouped observations, not necessarily the complete original messages or every fact needed to reconstruct a transaction. Preserve the reporting organization, report identifier, reporting interval, policy information, source address, count, evaluated results and available authentication domains. Do not fill absent fields with assumptions taken from a separate report or a current configuration screen.
RFC 9990 explicitly warns that aggregate report data can be forged. A report should therefore not be treated as self-authenticating proof of the business relationship it appears to describe. Retain ingestion provenance and corroborate consequential decisions with authorized route or message evidence where needed. A large count can justify investigation, but it does not by itself prove malicious activity, compromised accounts or a particular financial impact. RFC 9990, section 3.1 and 8.2
Classify the failure without collapsing uncertainty
Use a practical classification set: confirmed approved route with a configuration problem; likely approved route awaiting corroboration; intermediary-related behavior requiring message evidence; unknown source; and insufficient or unreliable reporting evidence. These are proposed workflow categories, not new DMARC protocol results. Preserve the underlying standards-based results alongside them.
For a confirmed route, identify the responsible configuration owner and the exact identity mismatch or signature issue supported by evidence. For an uncertain route, gather only the missing ownership or message details needed to distinguish it. For an unknown source, avoid adding authorization simply because it appears in a report. An include or signing-domain change can authorize more than intended if the account relationship has not been established.
Do not use one classification indefinitely. A supplier migration, product change or account offboarding can make yesterday’s mapping stale. Record who approved the route, when the mapping was last verified and what evidence would trigger reevaluation. This is an inventory and review proposal, not a claim that an automated classification system exists or was executed.
Report-to-decision worksheet
Create a worksheet that preserves the original source fields and separates interpretation from action. The first section should identify the report artifact, interval, row, count and ingestion provenance. The second should record the claimed sender route, business owner, supported product scope and confidence in the mapping. The third should distinguish raw SPF, raw DKIM, aligned results and the resulting DMARC evaluation.
Add a decision section containing the narrow proposed action, rationale, owner and evidence still required. Possible actions include asking the approved supplier to confirm its current custom-domain configuration, obtaining a redacted received-message sample through an authorized process, or leaving the source unclassified pending further evidence. Drafting an action plan does not authorize external contact or production DNS changes.
Acceptance requires a reviewer to follow the chain from report fields to classification to next action without relying on an undocumented leap. If the data cannot distinguish an approved account from another account using shared infrastructure, say so. If original message evidence is unavailable, keep signature-level explanations provisional rather than inventing a broken selector or altered body.
Fictional diagnosis: approved receipts, unaligned envelope
A fictional company has approved a receipt service. A fictional aggregate row reports SPF pass for the supplier’s envelope domain, a DKIM failure and DMARC failure for the company’s From domain. Assume the business owner confirms that this specific product route is intended, but no original message has been obtained. These are illustrative assumptions, not a retained report or a real supplier diagnosis.
The supported interpretation is that raw SPF success did not establish aligned authentication for the displayed company domain, while the reported DKIM result also did not provide a passing aligned path. The next action is to confirm the product’s actual supported custom-domain and signing configuration and obtain an authorized redacted sample if required. The report alone does not justify inventing a selector or adding a generic SPF include to the visible From domain.
If later evidence shows that the row belonged to another tenant on shared infrastructure, the mapping must change. The organization’s approval of its own supplier account would not authorize that other traffic. This possibility is why the worksheet records confidence and account scope instead of treating a provider name as permanent proof of legitimacy.
Missing evidence and release status
No real report, account, message or DNS result was inspected for this worked example. The catalogue requires a redacted report-to-decision walkthrough containing source fields, classification uncertainty and the next action. That original evidence remains open, and the fictional walkthrough is not counted as a completed operational requirement.
All six release gates remain open. Human review should check identity terminology, source applicability and the proposed decision’s scope before any change is approved. A corrected authentication route would still not guarantee inbox placement or prove that a business request is safe. Keep deliverability, content risk and business verification separate from the narrow authentication finding.