When you send an email, it's authenticated using standards like SPF and DKIM. However, when that email is forwarded through an intermediary, such as a mailing list or a forwarding service, this authentication can break. The forwarding server's IP address won't match the original sender's SPF record, and any modifications to the email, like adding a subject prefix or a footer, will invalidate the DKIM signature. This is where Authenticated Received Chain (ARC) comes in.
ARC is an email authentication protocol designed to preserve authentication results across the complex paths emails often take. It creates a chain of custody, allowing each server that handles the message to see the original authentication status and add its own layer of verification.
What is the 'd=' tag?
The d= tag in an ARC-Seal header specifies the domain that is cryptographically signing that particular 'hop' in the email's journey. The 'd' stands for 'domain'. This domain is officially known as the Signing Domain Identifier (SDID).
In essence, the domain listed in the d= tag is taking responsibility for the authenticity of the ARC headers it has added. It is vouching for the ARC-Authentication-Results header it generated, which contains the original SPF, DKIM, and DMARC results.
How the 'd=' tag fits into the ARC set
ARC works by adding a 'set' of three headers each time it passes through a supporting intermediary. These headers are all linked by an instance tag (i=), which is a simple counter that increases with each hop.
The final header in this set is the ARC-Seal, which 'seals' the other two headers from its set with a digital signature. The d= tag is a critical component of this seal, alongside other tags:
- i= (instance): The number that links the ARC headers from a single intermediary together.
- s= (selector): The selector used to retrieve the public key from the signing domain's DNS to verify the signature.
- d= (domain): The domain applying the signature and vouching for the results.
- b= (signature): The digital signature of the ARC-Message-Signature and ARC-Authentication-Results headers.
The 'd=' tag's relationship with DKIM
If you are familiar with how DKIM works, the function of the d= tag in an ARC-Seal will be very intuitive. In a DKIM signature, the d= tag also identifies the domain signing the message. The mechanism is nearly identical.
The ARC signing domain (specified in d=) publishes a public key in its DNS records. The location of this key is indicated by the selector (s= tag). A receiving mail server can fetch this public key to verify the signature (b= tag) in the ARC-Seal header. This process confirms that the ARC set was genuinely added by the claimed domain and has not been altered. In fact, it is common practice to use the same cryptographic keys for both DKIM and ARC signing, as noted in discussions by developers working on ARC implementations.
