A cryptographically valid ARC chain can come from an intermediary the receiver has no reason to trust. Conversely, a familiar service can produce a broken chain that should not be treated as valid evidence. Build the decision as separate stages: protocol verification, confidence in the intermediary, interpretation of earlier results and final message handling. Combining them into a single allow flag makes both troubleshooting and abuse review harder.
Establish what validation proves
References: RFC 8617 §5.2, RFC 8617 §9.
ARC validation checks the chain under the protocol's structural and cryptographic rules. It does not independently reproduce every earlier intermediary's authentication observation. It also does not certify that the intermediary's account controls, filtering or assessment logic are sound. RFC 8617, particularly its security considerations, states the boundary between chain validation and trust.
Retain the verifier implementation and version, evaluation time, signing domains, selectors and failure details. When validation fails, distinguish malformed sets from missing keys, signature failures and other diagnosed causes. A broad failure label is useful for routing but insufficient to justify a configuration change. Do not trust an invalid chain because the brand name is familiar.
Define the trust scope
References: RFC 8617 §7.2.1.
For an actual receiver configuration, document the intermediary's owner, expected route, reason for relying on its assessments, review date and removal procedure. Review its role in message modification and its ability to distinguish authenticated submissions from injected mail. Trusting a domain solely because it appears in a message allows an attacker to nominate the evidence source.
Provider documentation may expose particular controls. Microsoft, for example, documents configuration of trusted ARC sealers, but that does not make an arbitrary domain appropriate for the list. Consult the current tenant-specific feature and permissions before an authorized change. Microsoft trusted ARC sealers is implementation guidance, not a blanket trust recommendation.
Execute negative decision tests
References: RFC 8617 §7.2.1, RFC 8617 §9.3.
The local fixture supplies five combinations. Valid but untrusted evidence is rejected by the example override gate. Invalid but trusted evidence is also rejected. Favorable trust and validity without an earlier aligned pass are insufficient. Favorable inputs qualify for the example override, while malicious-content input still prevents acceptance in the toy policy.
This exercise demonstrates the separation of decisions and records its local outputs. It is not the mandatory policy of ARC or any provider. It does not perform DNS retrieval, verify a real chain or model all reputation and filtering signals. The inputs must remain labeled synthetic so a passing local test cannot be confused with a successful provider deployment.
Bound an operational change
References: RFC 9989 §7.4.
Before adding or removing a trust entry, identify impacted flows and retain the prior configuration. Use authorized test messages with expected negative controls, including an untrusted sealer and an invalid chain. Record current DMARC results separately from final delivery and any override reason. Avoid a change that silently bypasses unrelated malware or impersonation protections.
Schedule a review when the intermediary changes ownership, processing behavior or security posture. Track standards work too: the November 8, 2026 check found RFC 8617 Experimental and the Historic proposal still active draft work. Do not call a proposal completed retirement or ignore its relevance to future dependencies. The retained evidence includes a verified local chain and local decision below; the external deployment case remains open.
Retained laboratory evidence
References: RFC 8617 §5.2.
The retained 7 November 2026 experiment obtained chain validity from actual dkimpy cryptographic verification. The valid signed chain is run through both trusted and untrusted local configurations, producing eligible and ineligible decisions respectively. The tampered message fails validation even with trust enabled. Earlier SPF and DKIM results come from pyspf and dkimpy, and the explicit local policy checks that earlier strict alignment passed. ARC signing and tampering occurred offline after the six-message SMTP capture. The separate decision function used configured trust inputs, not additional SMTP deliveries. This produces bounded decision-model evidence for the controlled lab, without claiming that Microsoft or another provider implements that exact policy.
The retained runner and capture were inspected; no network experiment was rerun for this review. The original experiment 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.
The active Historic reclassification draft recommends against deploying or relying on ARC between disparate senders and receivers. This is a consequential proposal to consider when planning new dependencies, not completed retirement or proof that a current provider has disabled ARC. Retain a dated provider-specific dependency assessment while the standards process continues.