<domain>
Sets the attestation algorithm. There is one value — rsa-sha256, which is also the default: the manual says plainly that others are not supported.
The difference from the ordinary signature is telling here. dkim-algorithm formally has two values, and the second is obsolete, which is why it manages to migrate from old configurations and devalue the signature. Here there is no such possibility at all: the mechanism appeared after the old algorithm was recognized as unfit.
The line exists so that the arc- set mirrors the dkim- set line for line.
Do not set it. The default matches the only allowed value.
The difference from the ordinary signature is that there is nothing to inherit here. This mechanism never had an old algorithm.
If the line is already there — it can be removed. The behavior will not change.
# the line is redundant: the value matches the only possible one <domain *> arc-sign yes arc-algorithm rsa-sha256</domain>
what people get wrong and how it ends1 mistake▶
our experience
2 relations
arc-sign<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.31
pmta show settings gmail.com/vmta1 | grep -i arc-algorithm
3 articles
◇Do not send what will fail the check at the receiverThe node checks the SPF of its own mail before sending: if it fails, it bounces the message without waiting for someone else’s refusal.◇How the node signs messages and chooses a keyThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.◇A message header with which the submitting side adjusts the signatureFive parameters in X-DKIM-Options: selector, domain, signing identity, query method and key list.