オーセンティケーテッド・レシーブド・チェーン
DMARC(英語版)では送信者ドメインごとに、そのドメインの電子メールがSPFやDKIMで保護されていることを示すことができ、いずれの認証方式でも不合格の場合に受信側サービスでとるべき対応 (メッセージを拒否するなど) を指定できる。しかし、DMARC方針に厳格な指定をしていると、正当な電子メールであっても、メーリングリストや転送サービスを通過したものを阻止してしまうことがある。SPFでは、再送する送信者が認可外のものであれば検査が失敗してしまう。DKIMでは、メッセージが改変 (件名にタグが付加される、本文にフッタが追加されるなど) を受ければ署名が無効になってしまう。
ARCでは、中間サーバがメッセージの本来の認証結果に署名を付加できるようにすることで、SPFやDKIM署名が無効になってしまう問題を解決する。受信側のサービスは、SPFやDKIMによる検証が失敗してもARCによる検証結果を使うことができる。つまり、ARCによる検証に合格したということは、元のメッセージはSPFやDKIMの検査に合格しておりかつその後の改変を行ったのは受信側サービスの信頼する中間サービスのみであるということになるので、受信側のサービスではSPF、DKIM、DMARCが検証不合格でもその電子メールを受け付けてもかまわないと言えるのである。なお、どういった中間サービスを信頼するかについては、受信側サービスそれぞれの判断に委ねられる。
Authentication-Resultsヘッダフィールドの内容 (改変前に行われたSPF、DKIM検証の結果) を、メッセージの最初にARC-Authentication-Resultsフィールド として追加 (初めてならインスタンス番号は1)。
メッセージ (AARを含む) の署名を計算し、メッセージの最初にARC-Message-Signatureフィールドとして追加。
以前のArc-Sealヘッダフィールド (一般に複数) から封緘を計算し、メッセージの最初にARC-Sealフィールドとして追加。
受信側は、次の手順を踏んでARCの検証をする。
ARC-Sealヘッダフィールドの連鎖の検証 (抜けているものがなく、いずれのARC-Sealフィールドでも直前の記載内容が有効とされていることなど)。
最新のARC-Message-Signatureヘッダフィールドの検証 (インスタンス番号に基づき最新のものを判別)。