The ARC protocol uses three headers that are inserted in the order described below:
ARC-Authentication-Results (AAR) header: records the contents of the Authentication-Results header from DMARC. The purpose of this header is to record whether any previous authentication passed or failed.
ARC-Message-Signature (AMS) header: includes a cryptographic signature of the message itself up to this point.
ARC-Seal (AS) header: includes a cryptographic signature of the message headers. It does not sign the body contents of the message. This header contains a tag called chain validation “cv=”, which contains the outcome of evaluating the existing ARC chain. The “cv=” tag can be one of three values: none, fail or pass. The values are explained by the table below.
All of the above explained headers together are called an ARC set. Multiple ARC sets - if present - represent an ARC chain. Each of the headers within an ARC set contains a tag “i=” which represents the sequence number starting from 1 and it is the same for each ARC header within a set.
With the information above, let's look at a typical scenario:
Initial Email Sending
Sender Creation: Alice sends an email. Her email server (Server A) adds SPF, DKIM, and DMARC records. The email is correctly authenticated at this point.
First Recipient: Bob receives this email at his email server (Server B). Server B checks the SPF, DKIM, and DMARC, and finds them valid. The email is accepted.
Forwarding Scenario
Forwarding Initiated: Bob has set up an automatic forward from his email account to another account he owns, hosted on a different email server (Server C).
Email Modification: When Server B forwards the email to Server C, some changes are made to the email (like adding a forwarding notice). This breaks the original DKIM signature because DKIM is sensitive to changes in the email content.
ARC in Action
ARC Implementation by Server B:
ARC-Authentication-Results (AAR): Server B adds an AAR header to the email. This header records the original email's SPF, DKIM, and DMARC authentication results.
ARC-Message-Signature (AMS): Server B creates an AMS header, which is a new DKIM-like signature covering the email's headers and body, including the newly added AAR header.
ARC-Seal (AS): Server B also adds an ARC-Seal, which is a digital signature covering the entire set of ARC headers.
Receiving by Server C:
When the email arrives at Server C, the SPF check may pass (if the forwarding is done correctly), but the DKIM check will fail due to the modifications made by Server B.
Server C then looks at the ARC headers. It sees the AAR header, which shows that the email was originally authenticated correctly.
The AMS and AS headers confirm that the ARC information has not been tampered with since being added by Server B.
Decision by Server C: Instead of rejecting the email due to the broken DKIM, Server C uses the ARC headers to understand that the email was legitimate and authenticated before it was forwarded. This allows Server C to accept the email and deliver it to the final recipient.
Who needs to set up ARC?
Email Intermediaries are the primary entities that need to implement ARC, as they are the ones modifying emails.
Receiving Email Servers should be able to understand and use ARC headers for improved email authentication and validation inbound.
Email Senders and Originating Servers should maintain good SPF, DKIM, and DMARC practices, which complement the ARC protocol.