Begin with report fields
Retain the reporter, time interval, policy domain, source IP, message count, evaluated alignment and raw authentication identifiers. These fields describe observations, not an organizational ownership certificate. A shared cloud address can host unrelated customers, and a known provider name does not establish which internal department authorized the mail.
Separate infrastructure operator, authenticated domain, business service and accountable owner. A reverse-DNS name or network allocation can support an infrastructure hypothesis but cannot by itself prove the service behind a particular message. Avoid promoting a familiar network label into approved sender status. Record what is known, inferred and still unverified.
Walk through a shared-address example
The fictional normalized walkthrough uses one documentation IP for two services. The receipt service has an aligned signing identity and an owner-approved test reference. The second route has a different signer and no accountable owner. A third observation has only a source IP and count. The proposed labels are confirmed-example, provisional and unknown respectively because the stipulated evidence differs, not because the IP changed.
The approval assumption in the example is invented input, not actual authorization. No customer data or live provider report is included. The example demonstrates the information needed to avoid conflating services on shared infrastructure. In a real investigation, retain a controlled received sample and obtain the service owner's confirmation through an authorized process before recording approval.
Choose the next evidence request
For a provisional service, ask the suspected owner for the application purpose, sending account, visible From, return path, signing domain and a recent controlled sample. Reconcile the sample with the report's time and identity context. If the owner cannot substantiate the route, preserve uncertainty and involve the appropriate security or operations reviewer. Do not send arbitrary probes or expose report data to a third party without authorization.
Use attribution to support a decision, not to bypass its approval. Legitimate but misaligned mail may need configuration changes. Unknown aligned mail may involve an authorized signing path used unexpectedly and deserves investigation. Policy failure alone does not establish malicious intent, and alignment alone does not make message content trustworthy. RFC 9989 supplies the domain-authentication boundary; RFC 9990 explains the reporting fields and their privacy implications. Keep those boundaries visible in every export and incident note.
Follow the evidence into a decision
The following three-row written ledger stipulates reporter receiver.test, policy domain brand.test, window 2026-11-01T00:00:00Z to 2026-11-02T00:00:00Z and documentation IP 192.0.2.10 for every row. All identities, counts, owner decisions and test references are invented teaching assumptions. The word null means evidence not supplied, not an observed failure. These are not XML records, receiver logs or executed tests.
- Receipt row: count 40; visible From domain receipts.brand.test; DKIM d=receipts.brand.test, signature validity stipulated pass and exact alignment stipulated pass; SPF domain null and SPF result null. Owner assumption: fictional receipts owner approves this purpose. Test assumption: DEMO-RECEIPT-01 is an invented controlled-test reference, not an executed test. Proposed label: confirmed-example only. Next action: retain the stipulated basis in this exercise; in a real investigation obtain actual owner confirmation and received evidence.
- Service row: count 12; visible From domain notices.brand.test; DKIM d=service.vendor.test, validity stipulated pass but unaligned with notices.brand.test; SPF domain null and SPF result null. Owner assumption null; test reference null. Proposed label: provisional service attribution, not a complete DMARC verdict. Next action: request application purpose, tenant, owner confirmation and a controlled received sample.
- Unknown row: count 3; visible From domain brand.test; DKIM d=null, validity null and alignment null; SPF domain null and SPF result null. Owner assumption null; test reference null. Proposed label: unknown. Next action: request trusted received evidence and inspect routing; do not infer a provider or approve a change from the shared IP.
The forty-message receipt row has a stipulated owner decision and controlled-test reference. Its confidence is confirmed only within this invented example, and its next action is to retain that decision and monitor identity changes. The twelve-message service row has a signing identity but no owner confirmation. It remains provisional; request the suspected owner's purpose, tenant and controlled sample. The three-message row has no authentication identity evidence. It remains unknown; request a trusted received sample and inspect routing evidence. The decision ledger preserves the basis and next action alongside the source row. None of these invented records authorizes a production change or demonstrates a real sender's legitimacy.
Record a bounded attribution decision
If the provisional owner cannot identify the service tenant, keep that row unresolved even if another approved service uses the same IP. Do not inherit the other service’s approval. Correlating an aggregate row with a controlled message is contextual evidence, not a universal one-to-one join. Preserve the reporter, window and identities and describe the remaining uncertainty. No classifier, real approval, message test or provider probe was executed for this written walkthrough.
Protocol scope and evaluation limits
RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish authenticated identifiers, alignment and receiver handling. A valid signature alone is not a complete DMARC verdict, and a pass does not validate business content. RFC 9990 Sections 3.1, 3.5.1, 3.5.4 and 7 describe aggregate evidence, report identity, duplicates and privacy. Proposed commercial evaluation, staffing and authority gates here are editorial recommendations, not RFC-mandated product features. No absent executable supplement is required to read these written examples; operational claims require separately authorized observed tests.