ARC — 認証済み受信チェーン
このRFCが存在する理由
メール転送はSPFとDKIMのアキレス腱です。メッセージがメーリングリスト、エイリアス、または.forwardルールを通じて転送されると:
- SPFが失敗します。転送サーバーのIPが元の送信者のSPFレコードで承認されていません。
- DKIMが失敗します。中間者がメッセージを変更した場合（リストフッター追加、ヘッダー書き換え、エンコーディング変更）。
最終目的地でSPFとDKIMの両方が失敗すると、DMARCも失敗し、メッセージは正当に送信されて信頼できるインフラストラクチャを通じて転送されたにもかかわらず、拒否または隔離される場合があります。
RFC 8617で定義されているARC（Authenticated Received Chain）は、各中間者が観察した認証結果のスナップショットを記録してそれに署名することでこれを解決します。最終受信者はチェーンを検査して、直接的なSPFおよびDKIMチェックが現在失敗していても、メッセージが発信元で認証されたことを判断できます。
動作方法
3つのARCヘッダーセット
メッセージを処理する各中間者は、インスタンスカウンター（i=）でナンバリングされた3つのヘッダーのセットを追加し、各ホップで増加します:
| ヘッダー | 目的 |
|---|---|
ARC-Authentication-Results (AAR) |
この中間者が観察した認証結果（SPF、DKIM、DMARC）を記録します。標準的なAuthentication-Resultsヘッダーと同じフォーマットに従います。 |
ARC-Message-Signature (AMS) |
中間者が見たメッセージヘッダーと本文に対するDKIMのような署名。DKIMと同じ署名構文を使用します。 |
ARC-Seal (AS) |
すべての前のARCヘッダーセットと現在のAARに対する署名。このチェーンを封印し、誰も前のエントリを改ざんまたは並び替えるのを防ぎます。 |
管理の連鎖の例
# SPF: pass、DKIM: pass、DMARC: pass
# ホップ1: lists.orgのメーリングリストがメッセージを受け取る
ARC-Authentication-Results: i=1; lists.org;
dkim=pass header.d=example.com;
spf=pass smtp.mailfrom=example.com;
dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.org; s=arc; ...
ARC-Seal: i=1; a=rsa-sha256; d=lists.org; s=arc; cv=none; ...
# lists.orgがフッターを追加し、Subjectを変更して、再送信
# 元のDKIM署名は現在無効です（本文が変更されました）
# SPFはexample.comではなくlists.org IPを参照するようになります
# ホップ2: 最終目的地mx.receiver.com
直接DKIMチェック: FAIL（本文がリストによって変更されました）
直接SPFチェック: FAIL（IPはexample.comではなくlists.orgです）
直接DMARCチェック: FAIL（どちらも配置されていません）
ARCチェーン検証:
i=1 ARC-Seal: 有効（lists.orgによって署名されました）
i=1 AAR: lists.orgでdkim=pass、spf=pass、dmarc=pass
チェーン判定: cv=pass
受信者がlists.orgを信頼 => DMARC失敗をオーバーライド
主要な技術詳細
チェーン検証（cv）タグ
ARC-Sealヘッダーには、3つの値のいずれかを持つcv=（チェーン検証）タグが含まれています:
-
cv=none— これはチェーン内の最初のARCセットです（i=1）。検証する前のチェーンがありません。 -
cv=pass— チェーン内のすべての前のARCセットが検証されており、そのシールは無傷です。 -
cv=fail— チェーンが壊れています。前のARCセットの検証に失敗しました。チェーンがfailとマークされると、修復することはできません。
ARCとDMARCのオーバーライド
ARCはDMARCに置き換わるものではありません。代わりに、受信者がDMARCオーバーライド決定を下すときに使用できる追加情報を提供します。受信者のロジックは次のようになります:
- DMARCを直接チェックします。成功した場合は、通常どおり配信します。
- DMARCが失敗した場合、ARCチェーンをチェックします。チェーンが有効（
cv=pass）であり、受信者がチェーン内の中間者を信頼している場合は、DMARC失敗をオーバーライドします。 - ARCチェーンが無効であるか、中間者が信頼されていない場合は、通常どおりDMARCポリシーを適用します。
中間者を信頼する決定はローカルポリシーです。例えば、Gmailは信頼できるARCサイナー（主要なメーリングリストプロバイダー、大学メールシステムなど）のリストを維持しています。
署名要件
ARC署名はDKIM（RSA-SHA256またはEd25519）と同じ暗号形式を使用します。署名ドメインはDKIM公開鍵発行と同じく、_domainkey下のセレクターでDNSのARC公開鍵を発行します:
インスタンスナンバリング
ARCセットはi=1から始まり、順番にナンバリングされます。各中間者は次の番号でセットを追加します。最終受信者は、すべてのシールを順番にチェックしてチェーンを検証します。シールが失敗した場合、またはインスタンスが見つからない場合、チェーン全体は無効です。
ARCが行わないこと
- ARCは元の送信者を直接認証しません — 前のホップから認証結果を記録して伝えます。
- ARCは中間者への信頼を構築しません — 受信者は独立してどのARCサイナーを信頼するかを決定する必要があります。
- ARCはメッセージ変更を防ぎません — 変更が発生する前の認証状態を記録します。
一般的な誤り
- ARCが普遍的に尊重されると想定する: ARCはまだ実験的です（Standards Trackではありません）。Gmail、Microsoftおよび他の主要プロバイダーはそれをサポートしていますが、すべての受信者がサポートしているわけではありません。配信性のためにARC単独に依存すべきではありません。
- チェーンを壊す: ARCをサポートしない中間者がARCをサポートする2つの間に位置する場合、チェーンにギャップがあります。次のARC対応ホップはインスタンス番号がない場合に気付き、チェーンを失敗とマークします。
- ARC DNSキーを発行しない: メーリングリストまたは転送サービスを運用し、ARCヘッダーを追加してもDNSで対応する公開鍵を発行しない場合、検証者はARC-Sealを検証できず、チェーンが壊れます。
- ARCとDKIMを混同する: ARCはDKIMの署名フォーマットを再利用しますが、目的が異なります。DKIMはメッセージの責任があるドメインに署名します。ARCは各ホップでの認証状態を文書化する管理の連鎖を記録します。
- ドメイン所有者としてARCを無視する: ドメイン所有者はARCヘッダーを生成しませんが、ARCを理解することはメッセージがメーリングリストまたは転送サービスを通じて通過するときの配信性の問題を診断するのに役立ちます。
配信性への影響
- 転送メールの救出: ARCの主な価値は、転送後の正当なメールが拒否されるのを防ぐことです。メーリングリスト、大学エイリアス、企業転送ルールすべてがARCの恩恵を受けます。
- GmailのARC信頼: GmailはARCを使用してDMARCオーバーライド決定を下します。メッセージがDMARCに失敗したが、信頼できる中間者からの有効なARCチェーンを持っている場合、Gmailはメッセージを拒否する代わりにメッセージボックスに配信する場合があります。
- Microsoftサポート: Microsoft 365もARCチェーンを評価し、特に信頼できるメーリングリストからのメッセージについて、DMARCオーバーライドロジックでそれを使用します。
-
より厳しいDMARCポリシーを有効にする: ARCなしで、
p=noneからp=rejectに移動すると、正当な転送メールをブロックするリスクがあります。ARCはこのリスクを軽減し、ドメイン所有者が強力なDMARCポリシーを採用することをより安全にします。 - 将来への対応: より多くの中間者がARCを採用するにつれて、メールエコシステムはより回復力がつきます。ARCのサポートは、ますます信頼される転送チェーンから利益を得る準備ができたインフラストラクチャに位置付けます。