ARC（Authenticated Received Chain）

概要

ARC（Authenticated Received Chain） は、メールが中間サーバー（メーリングリスト、転送サービスなど）を経由する際に、各ホップの認証結果を保存するチェーン構造です。RFC 8617（2019年）で定義されています。

メールが転送されると、エンベロープ From の書き換えや本文・ヘッダーの改変により SPF や DKIM が fail することがあります。DMARC p=reject のドメインからのメールが転送先で認証失敗すると、正規のメールであっても受信拒否される問題が発生します。

ARC はこの問題を緩和します。中間サーバーが「転送前の認証結果」に署名してヘッダーに残すことで、最終的な受信サーバーが元の認証状態を参照し、信頼できる転送元であればメールを受け入れる判断材料にできます。Gmail、Microsoft 365、Yahoo Mail は ARC に対応しており、信頼できる中間サーバーからの ARC チェーンを DMARC の判定に組み込んでいます。

仕組み

ARC は中間サーバーが各ホップで 3 つの専用ヘッダーを追加し、チェーン構造で認証結果の履歴を保持します。

3 つのヘッダー

ARC は中間サーバーが各ホップで 3 つのヘッダーをメールに追加します。

ARC-Authentication-Results（AAR）は、その中間サーバーが観測した認証結果です。SPF、DKIM、DMARC の各結果を記録します。Authentication-Results ヘッダーと同じ形式です。

ARC-Message-Signature（AMS）は、メールの本文とヘッダーに対する DKIM 形式の署名です。中間サーバーが改変を加えた後の状態で署名するため、次のホップで検証が可能です。

ARC-Seal（AS）は、ARC チェーン全体（直前までの AAR、AMS、AS と自身の AAR、AMS）に対する署名です。チェーンが改ざんされていないことを証明します。

チェーンの構築

メールが複数の中間サーバーを経由するたびに、i= タグのインスタンス番号がインクリメントされます。

ARC-Seal: i=1; ...          ← 1番目の中間サーバー
ARC-Message-Signature: i=1; ...
ARC-Authentication-Results: i=1; ...

ARC-Seal: i=2; ...          ← 2番目の中間サーバー
ARC-Message-Signature: i=2; ...
ARC-Authentication-Results: i=2; ...

最終的な受信サーバーは、チェーン全体を検証します。i=1 から順に ARC-Seal の署名を確認し、チェーンに改ざんがないことを検証します。

受信サーバーの判定

ARC チェーンの検証結果は cv=（chain validation）タグで表現されます。

cv 値	意味
none	ARC チェーンが存在しない（最初のホップ）
pass	チェーン全体の検証に成功
fail	チェーンの検証に失敗（改ざんの可能性）

ARC チェーンが pass であっても、最終判定は受信サーバーのポリシーに委ねられます。Gmail は信頼できる転送元（Google Groups、大学のメール転送など）からの ARC チェーンを DMARC の判定に加味しますが、すべての ARC チェーンを無条件に信頼するわけではありません。

DMARC との関係

ARC は DMARC を置き換えるものではなく、補完する仕組みです。DMARC p=reject のドメインからのメールが転送で認証失敗しても、ARC チェーンに元の認証 pass の記録があり、転送元が信頼できると判断されれば、受信サーバーはメールを受け入れる場合があります。

RFC 8617 は ARC チェーンを DMARC の「ローカルポリシーオーバーライド」として使うことを想定しています。受信プロバイダーが独自の信頼リストに基づいて判断します。

設定例

ARC の設定は中間サーバー（転送サービス）側が担当し、ドメイン所有者側に追加の設定は不要です。

ARC 署名の DNS レコード

ARC の署名検証には DKIM と同じ形式の公開鍵が必要です。中間サーバー（転送サービス）側が _domainkey のサブドメインに公開鍵を公開します。

arc-selector._domainkey.relay.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

送信側（ドメイン所有者）が ARC のために追加設定を行う必要は基本的にありません。ARC は中間サーバー（メーリングリスト運営者や転送サービス提供者）が実装する仕組みです。

DMARC レコードでの対応

ドメイン所有者側の DMARC レコードに ARC 固有のタグはありません。ARC の恩恵を受けるために DMARC 側で特別な設定は不要です。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

受信プロバイダーが ARC 対応していれば、転送経由のメールでも p=reject のドメインからの正規メールを受け入れる判断ができます。

確認方法

ARC ヘッダーはメールのヘッダー情報に含まれます。Gmail でメールを開き「メッセージのソースを表示」でヘッダーを確認できます。

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=google.com; s=arc-20240116; ...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240116; ...
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.d=example.com;
       spf=pass (google.com: domain of user@example.com) smtp.mailfrom=user@example.com;
       dmarc=pass (p=REJECT) header.from=example.com

cv=none は最初のホップを示し、cv=pass はチェーンの検証成功を示します。

ドメインの DMARC レコード自体は dig で確認できます。

dig TXT _dmarc.example.com

;; ANSWER SECTION:
_dmarc.example.com.	3600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た DMARC レコードを取得できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
    "dkim": { "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
    "dmarc": {
      "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

よくある問題

ARC の役割と制約に関する誤解が、設定ミスや期待外れの原因になりやすいケースを整理します。

ARC を設定すれば転送問題が解決すると誤解する

ARC はドメイン所有者が設定するものではなく、中間サーバー（転送サービス）が実装する仕組みです。ドメイン所有者が自分の DMARC レコードに追加する設定はありません。転送問題を解消するには、転送先のプロバイダーが ARC に対応していることと、転送元が ARC 署名を行っていることの両方が必要です。

信頼できない ARC チェーンに依存する

ARC チェーンが pass であっても、受信プロバイダーは転送元サーバーが信頼できるかを独自に判断します。攻撃者が自前のサーバーで ARC 署名を付けてもそのまま信頼されるわけではありません。Gmail は Google Groups や既知の転送サービスを信頼リストに含めていますが、未知のサーバーからの ARC チェーンは無視する場合があります。

メーリングリストで Subject を改変して DKIM が壊れる

メーリングリストが Subject: にプレフィックス（[ML名] など）を追加すると、DKIM 署名の検証が失敗します。ARC が適切に実装されていれば、改変前の DKIM pass の結果がチェーンに記録されているため、受信サーバーは元の認証状態を参照できます。ただし、すべてのメーリングリストが ARC に対応しているわけではありません。