Forwarding does not automatically break DKIM. A forwarder that preserves the covered message content can leave the original signature valid. A forwarder that rewrites covered headers or body content can invalidate it. Diagnose what the forwarding service actually does rather than treating all indirect delivery as one failure mode.
Trace identities and transformations separately
At the final receiver, SPF evaluates the connecting system and relevant SMTP identity. Forwarding can change the connecting IP even when the message body is untouched. DKIM instead verifies covered message content against the signing domain's key. These mechanisms can therefore diverge on the same forwarded message.
Record the visible From domain, each DKIM signing domain, selector and result, the envelope identity and the forwarding hop. DMARC requires a passing authentication path aligned with the author domain. An intact aligned DKIM signature can supply that path under an applicable policy when forwarding disrupts SPF, as specified in RFC 9989 §4.4.1. A newly added signature under an unrelated forwarding domain does not automatically align.
Compare direct and forwarded samples
Send a controlled message to a direct test inbox and through the forwarding route to another test inbox. Preserve raw messages and trusted receiver results. Use a unique test marker so the samples can be associated without relying solely on Subject. Do not infer equality from the rendered body.
Inspect changes to the body, Subject and other fields selected in h. Check c and any l tag before interpreting differences. Standard canonicalization can tolerate certain formatting changes, while substantive rewriting can change the signed representation. Added transport headers do not inherently invalidate a signature that did not cover those new occurrences; repeated-header selection and oversigning can matter under RFC 6376 §5.4.2.
Work through two paths
Illustrative path A forwards the message without changing covered content. The original signature can remain valid. Path B adds a warning banner to the signed body, causing the original full-body signature to fail. The connection may be identical on both paths, so SPF observations alone cannot explain the DKIM difference.
A forwarder might also rewrite the envelope sender to improve its own SPF authorization. That does not restore a broken DKIM signature or necessarily create SPF alignment with the original visible From domain. Keep the three questions separate: which identity passed SPF, which signature passed DKIM and whether either path aligned.
Select a scoped remedy
If content preservation is compatible with the service's security obligations, review supported settings that avoid unnecessary modification. If modification is required, assess the service's documented signing and indirect-mail handling. Do not grant arbitrary forwarders your signing keys or broadly authorize them in SPF to make a symptom disappear.
An administrative receiver may use additional trusted evidence or local policy for indirect mail, but that is a separate acceptance decision. Do not report such acceptance as restoration of the original signature. Retain business requirements and any exception owner alongside the technical result.
Close with route-specific proof
Repeat the direct-versus-forwarded tests for plain text, HTML and attachments after a change. Record which original signatures survive, whether a new signature appears, and the final DMARC and delivery results. Keep the forwarding route in regression tests because a later banner or scanning change can alter the outcome without any DNS change at the sender.
Read two hypothetical message-level outcomes
Assume an applicable DMARC policy and Author Domain example.com:
- Preserved path: SPF fails after forwarding, but the original d=example.com signature still verifies. That exact aligned DKIM identity supplies DMARC pass.
- Modified path: the original DKIM signature fails; the only new passing signature and SPF identity belong to forwarder.example.net. Assuming that domain is unrelated to example.com, neither supplies alignment, so DMARC fails. The receiver can still make a separate local handling decision.
Do not merge the new signature’s pass with the old signature’s domain. These cases illustrate the conditions in RFC 9989 §5.3.5; they are not captured receiver results or guarantees about every forwarding service.