This help section describes the ARC Signing feature and the related settings available under the page in the navigation.
Emails that pass through mailing lists, email gateways, and other message-modifying agents (even just Microsoft® Exchange), often fail to authenticate afterwards. Sender Policy Framework (SPF) breaks under most forwarding scenarios, and DomainKeys Identified Mail (DKIM) breaks when messages pass through services that modify content protected by the DKIM signature. These in turn may break the Domain-based Message Authentication, Reporting, & Conformance (DMARC) alignment validation and get a legitimate email blacklisted.
The Authenticated Received Chain (ARC), a new protocol coming down the standards pipeline, solves this problem by allowing intermediaries to attest to the validity of the email by signing the original SPF, DKIM, DMARC test results when forwarding the email. Downstream message handlers can verify the validity of this chain of attestations and choose to accept the email even if the message fails the email authentication checks.
ARC uses the same signatures and keys as DKIM, so if you have DKIM set up already, you can import the same private key, and use the same Selector and Domain parameters in the ARC Signing settings.
Enter the selector prefix here which is an arbitrary name under the "_domainkey" namespace, indicating the location of the signing domain's public key in DNS.
Enter the domain name of the signing entity under which the public key record will be (or is) published.
Click the Add button to generate a new domain key pair, or import (or export) an existing private key. When importing a private key, the following formats are accepted: .PEM (RSA, Ed25519), .KEY (RSA, Ed25519), .DER (Ed25519).
Click this button to display the generated (DNS TXT) public key record and add it to the DNS server authoritative for your domain.
Once you have have filled in the Selector and Domain fields, have chosen an ARC key to use, and published the (DNS TXT) public key record, click the Verify button to validate your settings.
Enter the list of message header fields that should be protected by the signature. If you are unsure, use the default settings.
There are two canonicalitazion methods used for signing (and verification): Relaxed and Simple. We recommend using Relaxed as it tolerates common modifications such as whitespace replacement and header field line rewrapping, while Simple tolerates almost no modifications to the message header and body - which means the signature can break much easier.
Visit the ARC website at https://arc-spec.org/.
ORF implements RFC8617, published in July 2019.