A university can have healthy central staff mail while an alumni forwarder or departmental list fails at the recipient. These routes change different parts of a message. A forwarder changes the delivery path and can make SPF unsuitable for the original domain; a list can add a footer or rewrite a subject, potentially breaking a signature. Diagnose the actual transformation rather than granting every campus relay broad authority.
Follow three academic routes
Assign the faculty application to faculty IT, the alumni forwarder to the alumni service lead and the departmental list to its list administrator. Record the original author domain, outbound envelope domain, signing domain, intermediate host and final recipient. Capture an original message and a post-intermediary copy for the same fictional event notice. Retain the final receiver's trusted authentication results where available, not a header copied from an untrusted upstream message.
For a faculty application, test the system itself rather than sending a manual message from a professor's mailbox. Include semester-start automation and service accounts. For alumni, test both direct delivery and forwarding to an account controlled by the test team. For a list, compare an unmodified posting with a posting that receives the configured footer. Do not disable useful list functionality without checking member expectations and accessibility needs.
Explain the surviving authentication path
A preserved aligned DKIM signature can continue to support DMARC after forwarding even when SPF no longer does. If the forwarder changes a signed body or header, that particular signature may fail. SPF success for a rewritten forwarder envelope does not automatically align with the original author's From domain. RFC 7960 documents indirect-mail issues. ARC, defined in RFC 8617, can carry authentication assessments across intermediaries, but acceptance depends on receiver evaluation and trust; it is not a universal override.
For the written footer case below, assume the original signature covers the entire body without an l= limit, and the added non-empty footer changes the canonicalized signed bytes. Under those assumptions the original body hash no longer matches. This is protocol reasoning, not an executed signing test; whitespace-only changes may behave differently under canonicalization.
Choose a mitigation for each route
Where possible, preserve signed content through simple forwarding. If a list must transform the message, evaluate supported list behaviour, including a list-owned From identity and an appropriate Reply-To arrangement. Such rewriting changes the identity visible to readers, so test replies, moderation, archives and accessibility before adopting it. Do not forge an original author's signature or assume that a university-wide SPF entry fixes list modification.
Record an exception with owner, review date and affected recipient population if a supported route cannot yet meet the intended policy. Monitor actual failures separately from direct faculty mail. Student and alumni data access, records retention and consent rules remain a separate institutional review; protocol validation is not legal or educational-policy compliance.
Compare three forwarding states
These are written premises for reviewer@recipient.test, not sent messages or tests. All domains and owners are fictional.
- Direct faculty route: From faculty.campus.test, MAIL FROM faculty.campus.test, DKIM d=faculty.campus.test with selector demo1; assume DKIM pass. SPF unknown. The stipulated DKIM path aligns exactly. Faculty IT owns the actual application test.
- Alumni forward: From alumni.campus.test remains unchanged; final-hop MAIL FROM becomes relay.forwarder.test with stipulated SPF pass. Original DKIM d=alumni.campus.test, selector demo1, is stipulated to remain valid. Rewritten SPF is unrelated to From, but the preserved aligned DKIM still supplies a mechanism path. Alumni service owns final-hop observation and forwarding configuration.
- Department list: From faculty.campus.test, original DKIM d=faculty.campus.test, selector demo1; assume full-body signature without l= and a footer that changes canonicalized bytes. That original signature is expected to fail. MAIL FROM relay.list.test is stipulated SPF pass and is unrelated to From. Other signatures and ARC evidence are unknown, so do not infer the complete receiver decision. The list owner must inspect supported transformations and final trusted results.
No actual policy lookup, key validation, ARC chain or recipient observation is supplied. A valid ARC chain, if later obtained, would still require receiver trust assessment rather than automatically restoring the original DKIM signature.
Choose a bounded mitigation decision
For fictional list EDU-01, compare preserving signed content with a supported list-owned From rewrite. Rewriting to lists.campus.test requires an actual aligned authentication path for that new identity and separate checks for replies, moderation, archives and accessibility. A fresh signature for the rewritten message does not repair the original signature. With recipient evidence absent, label the proposal unverified and keep its owner and review date; do not claim a campus-wide fix.
Keep the evidence boundaries explicit
RFC 9989 Sections 4.4 and 5.3.5 distinguish authentication and alignment; Section 5.4 leaves message handling to receiver policy. Section 7.4 requires valid DKIM rather than SPF alone for domains publishing p=reject and warns against reject for domains whose users post to Internet mailing lists. Covered canonicalized bytes determine DKIM integrity under RFC 6376 Sections 3.4–3.7 and 6.1. Neither mechanism validates clinical, educational or legal authority. Collect authorized current evidence for an actual deployment; the operational checklists here are recommendations, not a jurisdiction-specific compliance assessment.