Classify the route before deciding what failed
A receiver can see mail directly from an originating service, after a forwarding hop or after a mailing list has modified it. A source IP and authentication failure do not, by themselves, distinguish these paths from impersonation. The investigator must connect the reported result to a particular route and preserve uncertainty where the route is missing. Otherwise a repair intended for a legitimate sender can authorize unrelated infrastructure.
This guide uses RFC 9989 and RFC 9990 from May 2026, SPF RFC 7208 and the experimental ARC specification RFC 8617. Provider guidance was reviewed on 8 November 2026. All route examples are fictional paper cases. No message was sent, imported or verified, no DNS query was run and no forwarding or receiver-trust setting was changed.
Define direct sending relative to the receiving boundary
For this investigation, direct sending means that the intended outbound service delivers to the receiving boundary without an intervening forwarding service in the route under examination. It does not mean that the originating organization uses only one internal server. Internal relays and outbound gateways can precede the observed connection, so record the boundary used when applying the label.
RFC 7208 evaluates a connecting host against a defined SMTP identity. In a direct route, a failure can indicate a configuration problem, an unexpected path or unauthorized use. It is not sufficient to name the cause from the result alone. Preserve the evaluated domain, connection context and error status before proposing any change to its authorization.
Explain why forwarding can alter SPF evidence
When a forwarder delivers an original message onward, the next receiver sees the forwarder's connecting address. If the original envelope identity is retained, that address may not be authorized by the original domain's SPF policy. If the envelope is rewritten, SPF may instead authenticate the forwarder's identity. Neither circumstance automatically provides an aligned SPF path for the original visible From domain under RFC 9989.
That is why adding every observed forwarder to the original domain's SPF is not a sound default response. It can widen authorization without addressing the actual route or the other authentication path. First establish whether forwarding occurred, whether the recipient expected it and which identities changed. A forwarding-like pattern is a hypothesis until representative route evidence supports it.
Examine whether the original DKIM signature survived
A message can retain a valid aligned DKIM signature through forwarding if the signed material remains compatible with verification. RFC 6376 defines what the signature covers and how it is checked. Changes to signed headers or body content can break that signature; merely moving the message through another server does not necessarily do so. Do not generalize from one forwarding product to all routes.
A mailing list can alter content, add a footer or otherwise transform the message before redistribution. A new valid signature from the list may authenticate the list's domain while remaining unaligned with the original From domain. A reported DKIM pass therefore needs its signing identity and alignment context. It cannot be read as proof that the original author's domain passed DMARC.
Use ARC as evidence whose trust still needs a decision
RFC 8617 is an experimental protocol for carrying authentication assessments across message-handling steps. ARC chain validation and trust in the sealing parties are separate questions. A cryptographically valid chain does not make the message safe or establish that every sealer is trustworthy. A missing or broken chain also does not prove that the message was forged.
Receivers can use ARC information in local disposition decisions. Do not rewrite that into a universal rule that ARC turns an underlying SPF or DKIM alignment failure into a protocol pass. Preserve the observed authentication results and any reported policy override separately. RFC 9990 distinguishes DMARC-evaluated fields from raw authentication results and provides context for policy-override reporting. Receiver acceptance and authentication outcome remain different facts.
Compare four fictional paths without overclassifying
The retained paper exercise contrasts four possibilities: an intended direct service; an unchanged forwarder preserving aligned DKIM; a modifying list whose original signature no longer verifies; and a sender impersonating the From domain without a known authorized route. These are explanatory alternatives, not four tested messages. No real host, account or business owner has been assigned to them.
The first three possibilities require route-specific configuration and message evidence before they can be treated as legitimate observed traffic. The fourth remains suspected spoofing until the available evidence and security review support that classification. Authentication failure alone cannot distinguish the modifying-list case from impersonation. Conversely, passing authentication cannot establish benign content or a currently approved business purpose.
Respect the receiver's actual trust configuration
Microsoft's trusted ARC sealer guidance is a provider-specific example: it describes selecting legitimate, required intermediaries for Microsoft 365 receiving behavior. It does not establish a universal allowlist, another provider's policy or the configuration of a customer tenant. This draft neither adds a sealer nor recommends trusting an intermediary merely because its name is familiar.
For a future investigation, retain the representative message, trusted receiving trace, relevant service configuration and recipient's expected route. Authentication-Results fields must be interpreted within an established receiving trust boundary, as RFC 8601 explains. An untrusted copied header can assert anything. Keep message disclosure, receiver-security changes and production DNS actions subject to their own human approvals.
Require an observed route before calling the remedy proven
The exact intake gate remains open: Validate current primary specifications and retain a worked example before drafting. Primary sources and fictional comparisons have been retained, but the commissioned original evidence is still absent: A route-to-requirement map with current provider evidence and a controlled test message.
An eventual controlled test must use an approved recipient and route, retain the relevant diagnostics and distinguish delivery, authentication and local-policy handling. It should address the specific uncertainty rather than promise universal forwarding compatibility. Until that evidence exists, preserve the candidate classification and next investigation step. Do not claim successful remediation, confirmed spoofing or an approved sender from the documentary examples alone.