オーセンティケーテッド・レシーブド・チェーン

DMARCでは送信者ドメインごとに、そのドメインの電子メールがSPFやDKIMで保護されていることを示すことができ、いずれの認証方式でも不合格の場合に受信側サービスでとるべき対応 (メッセージを拒否するなど) を指定できる。しかし、DMARC方針に厳格な指定をしていると、正当な電子メールであっても、メーリングリストや転送サービスを通過したものを阻止してしまうことがある。SPFでは、再送する送信者が認可外のものであれば検査が失敗してしまう。DKIMでは、メッセージが改変 (件名にタグが付加される、本文にフッタが追加されるなど) を受ければ署名が無効になってしまう。

ARCでは、中間サーバがメッセージの本来の認証結果に署名を付加できるようにすることで、SPFやDKIM署名が無効になってしまう問題を解決する。受信側のサービスは、SPFやDKIMによる検証が失敗してもARCによる検証結果を使うことができる。つまり、ARCによる検証に合格したということは、元のメッセージはSPFやDKIMの検査に合格しておりかつその後の改変を行ったのは受信側サービスの信頼する中間サービスのみであるということになるので、受信側のサービスではSPF、DKIM、DMARCが検証不合格でもその電子メールを受け付けてもかまわないと言えるのである。なお、どういった中間サービスを信頼するかについては、受信側サービスそれぞれの判断に委ねられる。

ARCは、新たに三つのメールヘッダフィールドを定義している。

• ARC-Authentication-Results (略号 AAR) - インスタンス番号 (i) と、SPF、DKIM、DMARCによる検証の結果。
• ARC-Seal (略号 AS) - インスタンス番号 (i)、以前のARC-Sealヘッダフィールド (一般に複数) に対するDKIM類似の形式の署名 (「封緘」〔seal〕と呼ぶ)、直前のARCエントリの有効性。
• ARC-Message-Signature (略号 AMS) - インスタンス番号 (i) と、メッセージ全体 (ARC-Sealフィールドは除く) に対するDKIM類似の形式の署名。

中間サーバは、次の手順を踏んで改変に署名を付加する。

• Authentication-Resultsヘッダフィールドの内容 (改変前に行われたSPF、DKIM検証の結果) を、メッセージの最初にARC-Authentication-Resultsフィールド として追加 (初めてならインスタンス番号は1)。
• メッセージ (AARを含む) の署名を計算し、メッセージの最初にARC-Message-Signatureフィールドとして追加。
• 以前のArc-Sealヘッダフィールド (一般に複数) から封緘を計算し、メッセージの最初にARC-Sealフィールドとして追加。

受信側は、次の手順を踏んでARCの検証をする。

• ARC-Sealヘッダフィールドの連鎖の検証 (抜けているものがなく、いずれのARC-Sealフィールドでも直前の記載内容が有効とされていることなど)。
• 最新のARC-Message-Signatureヘッダフィールドの検証 (インスタンス番号に基づき最新のものを判別)。

• センダー・ポリシー・フレームワーク (SPF)
• ドメインキー・アイデンティファイド・メール (DKIM)
• Domain-based Message Authentication, Reporting, and Conformance (DMARC)