A new source in authentication reports is a lead, not proof that someone bypassed approval. It may be a legitimate service on a new address, an indirect delivery path, a newly reporting receiver or unauthorized use. Establish the sending identity and service relationship before adding permissions or accusing a team of shadow procurement.
Preserve the observation
Retain the report identifier, reporting organization, interval, source address, counts, authentication domains and policy-evaluated results. Distinguish the From domain used for DMARC from a DKIM signing domain or envelope domain. Aggregate rows group observations and are not a mailbox-level transcript. RFC 9990.
Compare the new row with prior comparable intervals and receivers. A first-seen source is only first seen in your dataset. Do not label it globally new or infer a new service from a provider-owned IP alone. Shared infrastructure and changing egress addresses make address-only allowlists weak evidence of business ownership.
Join the service register carefully
A useful register contains purpose, customer-specific service identifier, business owner, criticality, From domain, envelope identity, signing identity, last controlled test and approval reference. Search approved changes and application ownership records using those fields. A known provider name is a clue; require the service instance or account evidence that links it to the business.
DMARC checks authenticated identity alignment, not procurement approval. An unauthorized service can pass when it retains aligned signing authority. Conversely, an approved service can fail because its route is misconfigured. Keep authentication outcome and authorization outcome separate. RFC 9989.
Use an explicit investigation state
Classify a finding as matched and approved, matched but approval missing, attribution pending, or confirmed unauthorized. Reserve the last state for actual evidence and an accountable decision. While attribution is pending, do not automatically add an SPF include, delegate a selector or lower a domain-wide policy. Those actions change authority before the investigation has established need.
Suppose a newly observed survey signer matches a customer-specific service account and a marketing owner confirms its purpose, but no current approval reference is available. Record approval missing and ask the accountable decision maker for the authorization history. For a second identity with no matching account evidence, retain attribution pending and request the relevant configuration records. Neither finding establishes maliciousness or permission to add DNS authority.
These are hypothetical inputs, not joined files, live reports or executed classification. If a later approval record covers only a different domain or account, keep the actual observation unresolved; a familiar vendor label cannot extend the scope of that decision.
Trace how the service obtained access
If the service is real, inspect the authorized configuration history: who created its selector, changed SPF, granted the integration or configured a relay. Use existing read access and approved evidence. Do not sign into an unfamiliar tenant or send test messages on someone else's behalf without authorization. For an approved route test, preserve the final receiver's result and compare it with the intended identities.
Microsoft's application-mail guidance illustrates why delivery method matters: authenticated submission, SMTP relay and Direct Send have different prerequisites and recipient scope. Do not treat all application mail as tenant mailbox traffic. Microsoft guidance.
Resolve the exception at its actual boundary
If the business approves the service, onboard it through the normal process, minimize its authority and test its real path. If the service should stop, coordinate removal with its owner and preserve a rollback path for critical flows. Escalate confirmed malicious or compromised activity through the incident process rather than treating it as ordinary inventory cleanup.
Close the investigation with the observed identities, attribution evidence, decision maker and exact change. Add a maintenance trigger for future identity or provider changes. A quiet report after removal is supporting evidence, not proof of eradication, because reports have limited and variable coverage.
The investigation states and ownership decisions above are a proposed operating workflow. NIST SP 800-53 Rev. 5 CM-8 provides a general inventory and accountability basis; it does not infer a business owner from an authentication result. NIST control catalogue.