Investigate the route before changing policy
An indirect message can fail even when a directly delivered message from the same sender succeeds. That difference is a reason to investigate the intervening route, not proof that the sender’s entire authentication policy is wrong. Begin with a narrowly stated incident: which message, which recipient path, which time and which observed failure? “Forwarded mail is broken” combines too many possible causes to support a safe change.
The aim is to locate the first meaningful difference between direct and indirect delivery and identify who can correct it. Keep policy changes, routing changes and receiver exceptions as distinct possible decisions. A useful investigation may ultimately support a scoped policy review, but it should not start by weakening protection for unrelated traffic merely because one forwarded message was rejected.
Preserve a pair that can answer the question
Request authorized direct and indirect samples from the same sending stream, ideally using controlled messages with equivalent content. Keep complete headers and the relevant envelope and delivery logs, not only a screenshot of the displayed sender. Record timestamps, message identifiers, final recipient context and known intermediaries. If equivalent samples are unavailable, state that limitation rather than comparing unrelated campaigns as though they were a controlled experiment.
Do not forward the problem message again simply to collect it: another forwarding step can change the evidence. Use an approved export or collection method that preserves the original representation. Restrict access to recipient addresses and message contents. Maintain a redacted working copy separately from the protected original so redaction does not become an unexplained signature-breaking transformation in the evidence packet.
Anchor results inside a trusted boundary
Read Authentication-Results only in the context of who inserted it and which receiving system trusts that source. A header claiming a pass can arrive from an untrusted sender. Compare receiver-added results with the actual evaluation location and message path; do not select whichever header contains the most favorable verdict. RFC 8601, sections 1.2 and 7 explains why these fields need a trust boundary.
For each sample, list the Author Domain, envelope sender domain, connecting IP at the evaluator, DKIM signing domains, verification outcomes and alignment relationships. Keep authentication results separate from disposition. A mailbox accepting a message does not prove DMARC passed, and a message rejected during SMTP may not have a recipient-side stored copy. In that case, server logs and the exact response become essential evidence.
Find the first lost aligned path
SPF evaluates the SMTP client against an identity from the current transaction. Forwarding commonly changes the client IP; envelope rewriting can also change the checked domain. DKIM can survive forwarding when protected content remains intact, but modifications may invalidate the relevant signature. DMARC needs a passing authenticated identifier with the required alignment, not simply a pass somewhere in the header. RFC 7208, section 2.4, RFC 6376, section 6 and RFC 9989, section 4.4.
A fictional incident illustrates the method. Direct mail from billing@sender.example has an aligned signature in the proposed comparison. The indirect route passes through a team list that adds a footer and uses its own return path. The investigation should ask whether the footer invalidated the original signature and whether the replacement envelope aligns. These are hypotheses to test, not captured outcomes. Adding the list’s infrastructure to the original sender’s SPF record without a justified authorization model would not answer both questions.
Evaluate ARC without changing the result label
If ARC appears, preserve every set and the final receiver’s actual chain evaluation. Determine whether the receiver recognizes the relevant intermediary and whether local policy used that information. Do not rewrite a DMARC failure as a pass because an ARC chain validated. The chain can carry earlier assertions; deciding to trust them is a separate receiver action. RFC 8617, sections 7 and 9.
Status matters to recommendations. RFC 8617 remains Experimental as reviewed on 8 November 2026. The active October 2026 draft proposing Historic status is not yet an RFC or a completed status change. It warrants explicit review before recommending a new dependency, while it does not prove a particular installed receiver has stopped using ARC. ARC status proposal.
Match the intervention to the evidence
If a remailer’s optional modification destroys the only surviving aligned signature, investigate that transformation with its owner. If the original stream was never signing correctly, fix the sender configuration. If results disagree because an untrusted header was mistaken for the receiver’s assessment, correct the analysis before changing infrastructure. Google’s forwarding guidance likewise emphasizes preserving DKIM-protected material and describes Gmail’s own authentication evaluation; it does not promise universal delivery. Google forwarding guidance.
Policy still deserves a substantive review when the evidence supports it. RFC 9989’s interoperability discussion cautions domains whose users post to Internet mailing lists about reject policies and requires receivers to consider more than the published policy alone. This is not a command to ignore indirect-mail failures indefinitely. Document the affected population, alternatives, owner approval and expected protection tradeoff before making a scoped recommendation. RFC 9989, section 7.4.
Close with a matched retest, not a new assumption
A proposed retest should preserve the original comparison dimensions and change one relevant condition where practical. Record both delivery disposition and authentication, including any remaining receiver-specific exception. Do not declare success merely because a test reached an inbox once or because a policy record was edited.
Direct and indirect delivery samples with route, envelope, signatures and trusted results compared. This exact catalogue requirement remains open. No original samples, live headers, DNS observations or controlled message tests accompany this draft. The investigation sequence is ready to use only as an approved evidence-collection plan, not as proof that any sender’s policy should change.