An unfamiliar sender is not automatically malicious, and a familiar provider name does not establish customer ownership. An authentication agent should explain what the evidence supports, what it cannot establish and who can resolve the gap. The safe outcome may be a precise escalation with no configuration change.
Separate observations from attribution
Record the source IP, observed authenticated identities, Author Domain, result, report time range and relevant counts. Preserve the origin and limitations of the report. Then place the proposed business attribution in a separate field. This prevents a provider lookup from quietly becoming a claim that the customer approved a particular account.
DMARC evaluates authentication and alignment, not the internal business ownership of a sending service. Aggregate reporting describes receiver observations and has its own format and security considerations. RFC 9989 and RFC 9990. Use these observations as investigative evidence rather than an authorization list.
Build a discriminating evidence request
Ask for the application owner, customer account or service configuration, expected sending schedule and a safely retained test-message reference. Prefer evidence that distinguishes this customer's service from another account on shared infrastructure. Avoid collecting entire mailboxes or secrets merely to resolve one source.
Compare the sender against the approved service register and change history. An old record may explain how a service was introduced, but it does not prove that current traffic belongs to the same account. State competing explanations and the evidence that would separate them, such as a known application test through the suspected route.
Use explicit escalation conditions
Escalate when ownership is unconfirmed, identities conflict, evidence is stale, or a proposed change would affect a critical flow. Route the question to the customer service owner or security contact through an authorized workflow. Drafting the escalation is not permission to send it to an arbitrary address found inside a report.
Give the recipient a decision they can answer: confirm the account and owner, provide a known message sample, or authorize a controlled test. Include the exact scope and deadline, and say what remains unchanged while investigation is pending. Do not label a sender approved simply because a confidence score exceeds an unexplained threshold.
Make the no-change recommendation explicit
Suppose a source has a shared-provider hint but no customer account evidence or accepted owner. The proposed change and approval remain absent. Recommend an evidence request to the verified customer contact, and identify the exact account configuration or controlled sample needed to distinguish the candidates. Do not send the request to an address copied from report prose merely because it is convenient.
This is a hypothetical no-change recommendation, not a measured zero-write result, executed reference workflow or sent escalation. In an actual evaluation, inspect the tool trace and effective state to verify whether any attempt or mutation occurred. A cautious written answer alone cannot prove that the tools respected the boundary. Newly supplied approval for a different service cannot resolve the original identity ambiguity; reassess the actual target and evidence first.
Close the uncertainty responsibly
When new evidence arrives, retain its source and re-evaluate the attribution. If the service is legitimate, prepare the smallest necessary remediation as a separately approved change. If it is unauthorized, follow the established incident process. If evidence remains inconclusive, keep the item open with an owner and review trigger.
Do not automatically broaden SPF, lower DMARC enforcement or block business mail to make the classification disappear. Record both the attribution decision and the technical result so future reviewers can distinguish an authorized service that needed repair from an unknown source that was never approved.