ARCとは

ARCを読むときの前提

ARC（Authenticated Received Chain）は、転送やメーリングリストを経由したメールで、途中の認証結果を引き継ぐための仕組みです。SPFやDKIMが転送後に崩れた場合でも、受信側が転送前の結果を参考にできるようにします。

実務では、ARC-Seal、ARC-Message-Signature、ARC-Authentication-Results、sealのcv、署名者、転送経路、DMARC結果、受信側のARC信頼判断を合わせて確認します。

証跡には、対象メールの全ヘッダー、ARC関連ヘッダー、Authentication-Results、Received、転送元、転送先、DMARC結果、確認時刻を残します。

転送で認証が崩れる理由を見る

メール転送では送信元IPが変わるためSPFが失敗しやすくなります。メーリングリストやゲートウェイが件名、フッター、本文を変更するとDKIM署名が壊れることがあります。

ARCは、転送前にSPF/DKIM/DMARCがどう評価されていたかを残す補助です。ただし、ARCがあるだけで必ず配送が許可されるわけではなく、受信側の信頼判断に依存します。

• 転送前後でSPF/DKIM/DMARC結果を比較する。
• 本文やヘッダーの改変有無を見る。
• ARCを配送許可の保証と扱わない。

ARCヘッダーのつながりを見る

ARCでは、ARC-Authentication-Results、ARC-Message-Signature、ARC-Sealがセットで追加されます。複数の転送を経るとインスタンス番号が増え、どの経路で何が評価されたかを追います。

確認では、i=番号、d=署名ドメイン、s=selector、cv結果、sealの連鎖を見ます。途中で検証がfailになる場合、どの転送段で崩れたかを分けます。

• ARCヘッダーのi=番号を順に確認する。
• 署名者と転送経路を突合する。
• cv=pass/fail/noneの意味を確認する。

DMARC評価との関係を分ける

ARCはDMARCそのものを置き換えるものではありません。Header Fromのalignment、SPF/DKIM結果、DMARC policyは引き続き確認が必要です。

転送後にDMARCが失敗しても、受信側がARCを信頼すれば配送判断を補助できる場合があります。組織のメールゲートウェイでARCを付与する場合は、署名鍵と信頼境界を管理します。

• DMARC結果とARC結果を同じメールで見る。
• 受信側がARCをどう扱うか確認する。
• ゲートウェイのARC署名鍵と所有者を記録する。

変更証跡と引き継ぎ

ARC関連の変更では、付与するゲートウェイ、署名ドメイン、selector、鍵管理、転送経路、テストメールヘッダー、戻し条件を残します。メーリングリストや外部転送の影響確認も必要です。

引き継ぎでは、メール基盤管理者、セキュリティ担当、DNS管理者、関連語としてDMARC、DKIM、SPF、Header From、DMARCアライメントを残すと確認しやすくなります。

• ARC署名者とselectorを記録する。
• 転送経路ごとのヘッダーを保存する。
• 受信側の信頼判断と例外条件を残す。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能