Identify which Microsoft service receives the message
“Microsoft-hosted mail” does not identify one universal forwarding policy. Begin by establishing whether the destination is a Microsoft 365 organization, a consumer Outlook.com account or a route that passes through another security service before reaching a Microsoft mailbox. The administrative controls and evidence available in one environment should not be assumed for another.
This workflow uses current Microsoft 365 documentation for organization-managed mail and requires the actual route to be verified. It is a proposed investigation and change plan, not a report that any tenant settings were inspected or modified. First obtain a direct-versus-forwarded comparison, then choose the smallest change that addresses the demonstrated failure while preserving the organization's security controls.
Locate the boundary where authentication changed
Draw the path from the original sender through every forwarder or gateway to the receiving service. For each boundary, record the connecting host, available envelope sender, Author Domain, DKIM signatures and observed transformations. Distinguish an inbound third-party intermediary from Exchange Online forwarding mail outward. They are different operational cases even when both occur inside the same conversation.
SPF uses the final connecting source for the identity evaluated there, so the original source's authorization may not describe the forwarding connection. RFC 7208 section 10.3 explains that limitation. An analyst should not change the original sender's SPF record until the affected identity and intended authorization are understood.
Compare the original and final signatures using RFC 6376. A gateway's content change can invalidate a signature when it changes covered material after canonicalization. This is conditional, not a claim that all added headers or all forwarding rules destroy DKIM. Preserve raw message copies where authorized so the hypothesis can be tested rather than inferred from a vendor diagram.
Read Microsoft results without renaming them
Microsoft's authentication overview distinguishes SPF, DKIM and DMARC from composite authentication, recorded as compauth. The latter incorporates additional assessment. Keep each field and the final handling action in separate columns. A composite pass should not be rewritten in the incident record as an ordinary DMARC pass.
The current trusted ARC sealer guidance describes using legitimate intermediaries' earlier assessments and provides a diagnostic example with compauth=pass and reason=130 while dmarc=fail remains visible. It also cautions that other filtering can still act. That is a provider-specific interpretation to verify in trusted receiver-generated results, not a promise that the same fields appear in every account.
Do not trust an arbitrary Authentication-Results line simply because it is near the top of a pasted header. Establish which receiving system generated the result and how the trusted boundary is identified. If only a screenshot or stripped excerpt is available, record the missing provenance and request an appropriately redacted full sample through the approved process.
Keep SRS and ARC decisions distinct
Microsoft's SRS documentation concerns applicable forwarding and relay scenarios and explicitly separates the rewritten MAIL FROM from the visible From. It also documents exceptions. Do not assume that every message entering Microsoft 365 receives the same rewrite, or treat an outward SRS behavior as the fix for an unrelated inbound gateway.
A rewritten envelope can support SPF for the rewriting domain without alignment to the original author. The relevant domain relationship is still required by RFC 9989 section 4.4. ARC instead conveys earlier authentication assessments for a receiver to consider. RFC 8617 section 7.2.1 describes local-policy use, not automatic replacement of the ordinary authentication result.
Any proposal to trust a sealer is a security decision. Identify the exact legitimate service, its operational need and an accountable approver; retain the earlier configuration and removal criteria. Do not add broad trust merely because a message carries a syntactically valid ARC set. The current ARC reclassification draft is work in progress, while RFC 8617 remains Experimental at this review date.
Fictional gateway change with a bounded acceptance test
In this fictional example, Example Services receives mail through a content gateway before a Microsoft 365 mailbox. An invented direct sample verifies an aligned DKIM signature; an equivalent gateway-routed sample has a rewritten attachment and no longer verifies that signature. The scenario assumes those observations solely to explain the investigation. No tenant or message was accessed.
The owner would first determine whether the transformation is necessary and whether a less disruptive configuration is supported. If an ARC-based treatment were proposed, the review would require the actual sealer identity, authenticated chain evidence and a specific tenant approval. Acceptance criteria would record ordinary authentication, composite results, security filtering and disposition separately. A successful inbox appearance alone would not demonstrate the intended mechanism.
Recovery criteria should include unexpectedly broad trust, new misclassification or failure to preserve the required evidence. The rollback plan should identify the exact approved configuration, not simply instruct someone to disable security processing until messages arrive.
Close only the route that was verified
After an authorized change, compare new direct and indirect samples with the baseline across representative messages. Preserve the settings version, timestamps and any residual provider or tenant uncertainty. A working path through one gateway does not validate every forwarding rule in the organization.
The original-evidence gate is unchanged and visible: direct and indirect delivery samples with route, envelope, signatures and trusted results compared. No such operational evidence, tenant approval, live test or recovery execution is included here. The deliverable is a reviewable procedure with source-backed distinctions, not a completed Microsoft 365 remediation.