The final receiver sees the intermediary’s hand-off
Direct mail has a simple shape: the sender’s service connects to the recipient’s service. Forwarding adds another hand-off. A mailbox forwards to another account, a security gateway relays into a tenant, or a mailing list receives one message and redistributes new copies to members.
The useful reframe is that authentication is evaluated at observation points. The first receiver may see the original sending IP and unchanged signed content. The final receiver sees the forwarder’s IP and whatever message emerges from the intermediary. Both can report accurately from their positions.
SPF is tied to the connecting host and an SMTP identity, as defined by RFC 7208. RFC 7208 DKIM validates selected signed content using the signer’s domain and public key. RFC 6376 DMARC asks whether a current passing result aligns with the visible From domain. RFC 9989 Once an intermediary is named, apparently inconsistent results become a route investigation rather than a reason to edit all DNS.
Forwarding changes the host SPF evaluates
At original delivery, the sender’s IP may be authorised by the envelope domain’s SPF policy. When a forwarder later connects to the final receiver, the connecting IP belongs to the forwarder. If it preserves the original envelope sender, that new IP may not be authorised by the original domain, so SPF can fail.
Adding every forwarder IP to the original sender’s SPF record is not a sound repair. The sender may not know all forwarding paths, and it should not authorise infrastructure it does not control. Some intermediaries rewrite the envelope sender to a domain they control, which can let SPF pass for that new identity. Whether it aligns with the visible From domain is a separate DMARC question.
Use headers from the final mailbox to record smtp.mailfrom, connecting hand-off and SPF result. If possible, compare evidence from the intermediary’s first receipt. Preserve the domains exactly. ‘SPF failed after forwarding’ does not mean the original SPF record is broken.
Stop before changing SPF if the observed IP belongs to a forwarding or list service. Establish its role and supported behaviour first. A domain-wide authorisation made to fix one indirect route can expand who may send using your envelope identity.
Message changes can invalidate a previously good signature
DKIM signs selected headers and a canonicalised body representation. Ordinary relaying that leaves signed content intact can preserve a valid signature even though the connecting IP changes. This is why DKIM often provides the surviving aligned path through a simple forwarder.
Mailing lists and gateways may alter the Subject, add a footer, rewrite links, change MIME structure or modify other signed fields. Depending on what was signed and the canonicalisation used, that can produce a header-signature or body-hash failure. RFC 6376 defines the signature tags, body hash and canonicalisation process. DKIM verification
Do not assume every footer breaks every signature or that relaxed canonicalisation permits arbitrary edits. Collect the original and redistributed copies where authorised, then compare signed fields and body treatment. Multiple signatures may exist, and one may survive while another fails.
The trade-off is functionality versus preservation. Lists add subject labels and footers for member context and management, but those edits can damage end-to-end authentication. Removing all modification may preserve signatures while losing list features. The list operator must choose a supported design based on its users and receiver behaviour.
When the failure identifies a selector or key, use the DKIM selector troubleshooting guide to separate DNS faults from changes made after signing.
DMARC needs a passing aligned result at final receipt
At the final receiver, DMARC succeeds when at least one current SPF or DKIM result both passes and aligns with the visible From domain. A forwarded message may lose SPF because the connecting IP changed. If aligned DKIM survives, DMARC can still pass. If a list modifies signed content and DKIM fails too, DMARC can fail.
A list might use its own envelope domain and add its own valid DKIM signature. Those results can authenticate the list’s infrastructure without aligning with the original author’s From domain. They are useful signals, but they do not automatically satisfy DMARC for the original domain.
RFC 9989 documents identifier alignment and discusses indirect mail flows. Current DMARC specification Do not respond by weakening the original domain’s policy solely for every possible forwarder. Policy applies across traffic claiming that From domain, while the observed problem may belong to one intermediary.
Record which mechanism survived, which domain it represented and where it was evaluated. The aim is not to force SPF to pass after every relay; it is to understand whether the final receiver has reliable evidence for the original message and how the intermediary handles that evidence.
To see which identity needs to align, start with how DMARC alignment works.
ARC carries handling evidence, not a guaranteed pass
Authenticated Received Chain, or ARC, lets participating intermediaries record authentication results observed when they received a message, then seal those results and subsequent handling into a chain. RFC 8617 defines the ARC message signature, seal and authentication-results fields. RFC 8617
A final receiver can evaluate the chain and apply local policy using information about the earlier state. This can help when forwarding or list modification breaks current SPF or DKIM. It does not make a failing DMARC result become a passing result, and it does not require a receiver to accept the message.
ARC also depends on trust. A cryptographically valid chain shows that seals verify; the receiver still decides whether it trusts the intermediaries and their handling. A malicious or poorly operated sealer should not gain authority merely by publishing keys.
Do not add an ARC header yourself or copy one from another message. ARC is produced by participating mail systems with signing keys and chain-state handling. If a gateway claims to support ARC, capture the final header and ask the receiving administrator whether it trusts that sealer. Treat ARC as additional evidence, not a universal repair switch.
Trace the message before and after the intermediary
Use a plain, non-sensitive test message through the real indirect route. Where authorised, deliver a direct control to one mailbox and an indirect copy through the forwarder or list to another mailbox at the same final provider. Keep the original sender, content and timing comparable.
From each copy, record trusted authentication results, return path, DKIM d= and s=, relevant Received hand-offs, DMARC result and any ARC fields. Note whether subject, footer, links or MIME boundaries changed. Store full headers privately and use stable redaction before sharing because addresses, member identifiers and internal hosts can appear.
Compare the evidence in order: original SPF identity and IP; forwarder envelope behaviour; surviving or failed original DKIM; intermediary signature; final DMARC; ARC chain status if present. This reveals the mechanism without guessing from an inbox icon.
Do not use a real mailing list with many members for testing. Create a controlled list or route with recipients you manage. Stop if the list cannot limit distribution, if the message contains personal data, or if collecting headers would breach member expectations. Involve the list owner and privacy owner.
Choose the remedy owned by the intermediary or sender
For simple forwarding, preserving the original message helps DKIM survive. The forwarding provider may also use a supported envelope-rewriting scheme and ARC. Follow its documented design rather than adding its network to the sender’s SPF.
For a mailing list, the operator may preserve signed content, change how the author identity is presented, sign redistributed mail, use ARC, or combine measures. Each has trade-offs in user clarity, reply behaviour, archives and authentication. There is no single choice that fixes every receiver and list style.
For the original sender, stable aligned DKIM provides a route-independent authentication path when content remains intact. Use selectors and canonicalisation recommended by the sending platform; do not deliberately omit important headers from signing merely to tolerate uncontrolled modification. For the final receiver, configure trusted ARC sealers only through the mail platform’s supported controls and only after assessing the intermediary.
Make one owned change and record it. Never lower DMARC policy across a domain as the first response to one list. Never authorise a forwarder’s IP without confirming the SPF identity it will use. Escalate to the intermediary when its transformation is the observed breaking point.
Verify the indirect route and stop at the trust boundary
Repeat the same controlled direct and indirect sends after the change. At the final receiver, confirm the expected route, current SPF identity, original and intermediary DKIM results, DMARC result and ARC chain status. If acceptance or placement was the symptom, record it separately from authentication.
Success might mean aligned DKIM now survives, the list presents a different accountable From identity, or the receiver uses a trusted ARC chain according to local policy. State which mechanism produced the result. Do not report ‘forwarding fixed’ from one unrelated mailbox or from DNS alone.
Stop and escalate if the intermediary rewrites messages without documenting it, ARC seals fail or come from an untrusted service, a list design would misrepresent the author, or the only proposed remedy weakens every sender on the domain. Send the operator redacted before-and-after headers, UTC times, list or forwarding route, changed fields and exact authentication outcomes.
Indirect mail is not broken because one mechanism changes. It becomes diagnosable when you preserve evidence from both observation points. The durable answer is an owned combination of identity, message preservation, intermediary handling and receiver trust, followed by proof on the same route.
Sources and further reading
- RFC 8617: The Authenticated Received Chain Protocol
- RFC 6376: DomainKeys Identified Mail
- RFC 7208: Sender Policy Framework
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance