A forwarded message can be legitimate and still fail DMARC. The last receiving server evaluates the connection and message it actually receives, not the sender's intention or an earlier delivery's result. The useful question is which authenticated identity still aligns with the visible From domain after the forwarding hop. Preserve that distinction before considering a policy exception.
Reconstruct the route
References: RFC 8601 §1.2, RFC 8601 §5.
Collect the original raw message, the forwarded raw message, timestamps, forwarding configuration and receiver-generated authentication results. Keep the SMTP envelope separately from the visible headers: a saved message does not necessarily preserve the envelope used at every hop. Obtain trace evidence from the systems responsible for those hops. Do not treat a sender-inserted Authentication-Results field as a trusted receiver observation. RFC 8601 explains that boundary.
Label the original sender, intermediary and final receiver. Then record the connecting IP, envelope domain, visible From domain and every DKIM signing domain at each applicable evaluation point. A route diagram is useful only if it reflects observed transfers. An unknown hop remains unknown rather than being assigned an assumed authentication result.
Identify the surviving path
References: RFC 7208 §2.3, RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 6376 §3.4.
SPF assesses the connecting system against an envelope identity. At the final receiver, a forwarding server may be outside the original envelope domain's authorization. A preserved DKIM signature can still provide an aligned pass because verification is tied to the signed message and signing domain. Content rewriting can remove that remaining path. DMARC needs an aligned authenticated result, not simply any SPF or DKIM pass. RFC 9989, RFC 7208 and RFC 6376 define these separate checks.
An SRS-rewritten envelope may pass SPF for the forwarder's domain without aligning with the original author's From domain. A new signature from that same forwarder has the analogous limitation. Neither observation means that the message is necessarily malicious, and neither automatically repairs the author's aligned authentication.
Run the bounded example
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
The retained strict-alignment model can be inspected separately from the SMTP capture. The direct case supplies aligned SPF and DKIM passes. The preserved-forwarding case supplies SPF failure and aligned DKIM success, so the strict-alignment model still passes. The footer case supplies failures for both paths and fails. The SRS cases isolate how a successful but unaligned SPF identity changes none of that reasoning.
Those booleans are deliberate inputs, not results of live DNS queries or cryptographic signature verification. The generated raw messages are synthetic and were never received. They illustrate a controlled body change but do not satisfy the requirement for real original and forwarded messages with trusted results. The retained SMTP laboratory section below supplies historical locally received evidence; external production evidence remains open.
Repair the narrow cause
References: RFC 9989 §7.4.
Ask the intermediary to preserve signed content where possible, and verify signing placement in the originating service. Test a representative authorized route before changing broad domain policy. If a receiver applies a local exception, retain its scope, owner, expiry and independent filtering requirements. Delivery under an exception is not a DMARC pass.
Close the investigation only when the lost path, change made and observed receiver decision are documented separately. Retest periodic and low-volume workflows as well as the obvious daily path. An organization-wide move to monitoring merely to hide one forwarding defect can reduce protection for unrelated mail without fixing the intermediary.
Retained SMTP laboratory evidence
References: RFC 7208 §4, RFC 6376 §6.
The retained capture dated 7 November 2026 at 21:29:16 UTC records that the loopback receiver captured direct, preserved-forwarding and footer-modified messages over actual SMTP. It observed peer 127.0.0.2 for the originating connection and 127.0.0.3 for the forwarding connection. pyspf evaluated those IPs against isolated fixture DNS; dkimpy verified actual RSA signatures. The direct case passed both checks, the preserved forwarded copy failed SPF but passed aligned DKIM, and the footer copy failed both. Receiver-generated Authentication-Results and complete raw messages are retained together with envelopes and SHA-256 values.
The historical runner and retained messages were inspected for this revision; the network experiment was not rerun. Its original execution used loopback only and sent no Internet mail. Its receiver creates Authentication-Results from its own checks, giving those fields known laboratory provenance. Authentication outcome and disposition remain separate: all six SMTP samples receive 250 under an explicit capture policy, including failing samples. The trust boundary is this controlled laboratory, not a production mailbox provider. The DNS adapter supplies retained fixture answers rather than querying public DNS, and the DMARC evaluator uses strict domain equality only. Full organizational-domain discovery, production policy parsing and live deployment outcomes remain untested.