A business-critical forwarded message can fail authentication without being fraudulent. That does not make every message on the same route trustworthy. An exception should identify the exact workflow, the reason the normal control fails, the remaining safeguards and the person who will remove it. Treat the exception as a temporary risk decision supported by evidence, not as a permanent declaration that the sender is safe.
Trace the legitimate path
References: RFC 7208 §4.1, RFC 6376 §3.4, RFC 9989 §5.3.5.
Start with a named service and business owner. Record the original sender, forwarding service, final receiver and intended recipients. Obtain an authorized direct sample and an indirect sample, retaining the SMTP envelope separately from the visible From field. Compare the connecting IP, SPF identity, each DKIM signing domain and trusted receiver results at each boundary. Minimize personal content in the retained message.
SPF evaluates the connecting host against an envelope identity; an ordinary forwarder can change that host without changing the original envelope domain. DKIM can survive forwarding when signed material is preserved, but a footer or subject alteration can invalidate it. DMARC needs a passing aligned mechanism. These distinctions follow RFC 7208, RFC 6376 and RFC 9989. An exception does not change their protocol results.
Describe the smallest decision
References: RFC 9989 §7.4.
Write the affected route, recipients, message purpose, expected volume and observed failure. Include an owner, approval reference, start and expiry, review trigger, compensating controls, rollback and removal criteria. These are operational recommendations, not protocol-mandated fields. Prefer a repair that preserves aligned authentication over an allowance that suppresses inspection. A sender-domain-only allowance is particularly weak because that is the identity an attacker may imitate.
If the receiving platform offers scoped controls, verify the exact matching and precedence in its current documentation. Do not assume a connector label, source IP or ARC pass uniquely identifies the legitimate application. Shared infrastructure can carry other customers' mail. Retain anti-malware and account-protection controls unless an explicitly reviewed policy says otherwise; an authentication exception should not silently become a universal filtering bypass.
Work the exception example
References: RFC 9989 §4.4.
The retained isolated lab created a signed message from author.test. Its direct case passes the bounded SPF model and actual DKIM verification. Forwarding through forwarder.test preserves DKIM. An SRS-style envelope change leaves DKIM intact but makes the SPF domain different from the visible From domain. Appending a footer then breaks DKIM, leaving no aligned passing mechanism in this exact-domain model.
The proposed exception applies only to that last fictional workflow while the list operator removes the modification or adopts an agreed sender design. The evidence packet contains message bytes, public verification material and computed results. It is not a customer incident or an observed production delivery. The SPF and alignment logic is deliberately limited; the DKIM verification is real. Production route samples and receiver-specific rule testing remain necessary before approving an actual allowance.
Review and remove
References: RFC 9989 §7.4.
Set the review date around the repair plan rather than leaving the exception open indefinitely. Compare fresh samples after a service migration, forwarding change or provider update. Test the repaired route with the allowance disabled in a controlled scope, and verify both legitimate delivery and continued rejection or scrutiny of unrelated traffic.
Close the record only when the responsible owner confirms the business flow and the security owner accepts the evidence. Preserve the reason for removal and the final configuration reference. If the repair fails, renew through a deliberate decision with a new expiry instead of allowing silent drift.
Retained controlled forwarding route
References: RFC 7208 §4, RFC 6376 §6, RFC 8601 §5.
The retained 7 November 2026 capture at 21:32:53 UTC records a separate fixture sending the signed message through real loopback SMTP connections. These network sessions were inspected, not rerun for this review. The origin binds to 127.0.0.2, the forwarder sends onward from 127.0.0.3, and the final receiver stores each message. These addresses are confined to the local machine. The direct, unchanged-forward, rewritten-envelope and footer cases each have an actual transaction trace with timestamps, envelope identities and final acceptance. The rewrite is an SRS-style domain substitution for this lab, not a complete SRS implementation.
Each receiving boundary computes SPF using pyspf 2.0.14 with explicitly injected local TXT answers, and DKIM using dkimpy with the retained public key. The receiver adds its own Authentication-Results and Received fields after evaluation. Those results are trusted only within this controlled fixture, where the inserting code and boundary are known. It does not accept arbitrary embedded pass text as its own verdict. DNS policy is static local input, not a claim about public DNS.
At the final receiver, SPF results are pass, fail, pass and pass respectively. DKIM results are pass, pass, pass and fail. The exact-domain alignment model therefore preserves DMARC authentication for the first three cases and fails the footer case. This is not full DMARC policy discovery. The lab deliberately stores even the failing message for inspection, so its 250 response is not evidence that an enforcing production provider would deliver it.
The exception example and rollout hold are tied to that historical footer route: the unchanged route preserves the signature, while the controlled intermediary's footer breaks it. Keep any allowance unapproved until its real scope, owner, expiry and receiver behavior are reviewed. These historical controlled transactions document the local route comparison; production mailbox-provider compatibility, real business-flow authorization and any operational exception approval remain unperformed.