Start with what the receiver actually reported
A source IP in an aggregate report identifies a connecting system in the reporter's observation. It does not name the application that composed the message, the customer account that submitted it or the person authorized to use your domain. Treating an IP label as an approved sending service skips those separate decisions. The practical task is to connect a bounded observation to a business record without pretending the missing links are already known.
RFC 9990, published in May 2026, defines the report's connecting address, message count and evaluated policy fields. Its current structure is the reference here. Actual reporters may use different supported report versions; preserve the version and interpretation rather than silently translating every input into the newest schema. No customer report was imported or tested for this guide.
Preserve the observation before enriching it
Retain the reporting organization, report identifier, time interval, policy domain and relevant record. Keep the connecting IP with the identities and results in that same record. A summary grouped only by address can combine different From domains, signing identities or outcomes and hide the distinction that matters. Use the reported count, not the number of XML rows, when describing the volume represented by a record.
An enrichment label should be a separate annotation with its own source and observation time. If a database calls the address a familiar provider, that is a clue about infrastructure. Do not overwrite the raw address or replace an unknown application with the provider's logo. The original report and later interpretation must remain distinguishable so another reviewer can challenge the attribution without losing the underlying evidence. A well-formed report is still an assertion whose provenance needs review, not independent proof of the claimed traffic.
Separate authentication from service permission
The report's raw authentication results and its DMARC evaluation are different layers. RFC 9989 requires an authenticated identifier to align with the Author Domain for the relevant DMARC path. A successful check for an unrelated provider domain is not sufficient merely because the provider is recognizable. Conversely, a reported aligned pass does not establish that the organization's procurement or security owner approved this particular application.
SPF is especially easy to overread. RFC 7208 evaluates host authorization for a defined SMTP identity, not the business legitimacy of every user sharing that mail infrastructure. The intended service may be configured correctly, an obsolete account may still send, or an approved account may have been misused. Those possibilities require different evidence even when an authentication result looks similar.
Work through a fictional report without inventing a finding
Consider a paper example retained before drafting: a fictional receiver reports 24 messages from 192.0.2.40 with header_from=notices.example, DKIM alignment reported as pass and SPF alignment as fail. The address and domain are illustrative, and these are selected field values rather than a complete or validated XML fixture. No query, message delivery or signature verification produced them.
The supported conclusion within the fiction is narrow: this reporter describes an aligned DKIM path for that grouped observation. The unsupported conclusion would be that Atlas Notifications is an approved service, because no account mapping, application evidence or business owner has been supplied. The next action is to seek an authorized representative message and the relevant service-register entry. Adding the address to SPF is not justified by the example.
Connect the address to an accountable service
A proposed attribution record should identify the application, provider, customer account or tenant, intended purpose, permitted sending domains and accountable owner. Compare those entries with the observed envelope identity and DKIM signing domain or selector where available. A domain-verification badge at a provider is technical evidence with a limited scope, not an organizational approval record.
Provider documentation can explain why the IP is not unique. Amazon SES documents shared and dedicated pools, demonstrating that provider infrastructure can serve more than one customer. This does not attribute the fictional address to SES. It explains why an IP-to-provider association would still leave the application and account unresolved. Obtain customer-specific evidence before promoting a candidate attribution into an approved service entry.
Keep report coverage and time limits visible
An aggregate observation is not an inventory of every message sent by the organization. Its scope depends on the reporter, period and reporting coverage. An absent service in a later interval might mean inactivity, delayed reporting or missing visibility rather than successful retirement. A change in source IP can reflect infrastructure movement without proving a new application, while the same IP can support a different account later.
Preserve the date of each supporting artifact. A current DNS answer or registry label cannot automatically recreate the conditions of an older report. If timing differs, state what is historical and what was checked later. A proposed decision record should keep unresolved contradictions, including a business owner who recognizes the application but cannot confirm the account or the observed sending identity.
Make classification an explicit review decision
Use statuses that reveal what is known: observed but unattributed, candidate service, verified service mapping, approved use, or escalated concern. These are proposed workflow labels, not EmailAuth features. Approval should specify the permitted purpose and identities, not just a provider name. Discovery of unfamiliar traffic neither authorizes production DNS changes nor permits sharing a full report with an external party.
The exact intake condition remains visible and open: Validate current primary specifications and retain a worked example before drafting. Primary standards and a fictional paper example were retained, but they do not satisfy the commissioned original evidence: A redacted report-to-decision walkthrough with source fields, classification uncertainty and next action. No customer decision or approval exists in this package. Technical review must assess the eventual evidence, and an authorized owner must accept the service classification before it is treated as operational fact.