ARC（Authenticated Received Chain）

この用語をシェア

ARCとは

ARC（Authenticated Received Chain）は、メール転送時の認証情報を保護するプロトコルです。RFC 8617で標準化され、メーリングリストや転送サービスを経由したメールでも、元のSPF、DKIM、DMARC認証結果を保持することができます。

ARCが登場した背景には、DMARCの普及に伴う「正当な転送メールが弾かれる」という副作用があります。DMARCはなりすまし対策として非常に有効ですが、SPF・DKIMという認証の仕組みは「メールの経路が変わる」ことを想定していません。社内メーリングリストや.forwardによる転送、Microsoft 365・Google Workspaceのエイリアス転送など、日常的に使われる転送機能がDMARC p=reject環境では正規メールごと弾かれてしまう――この矛盾を緩和するために、中継サーバーが「自分は誰から受け取り、その時点でSPF/DKIMはどう判定されたか」を署名付きで記録し、受信側に申告する仕組みとして設計されたのがARCです。あくまで送信ドメインを保証するSPF/DKIM/DMARCとは異なり、ARCは「転送の経路と認証履歴」を証明する補助的な仕組みである点が最大の特徴です。

ARCの仕組み

メール転送時の認証問題

従来のメール認証では、転送時に以下の問題が発生していました：

• SPF失敗: 転送元IPアドレスが変わるため、SPFチェックが失敗
• DKIM失敗: メール内容が変更されると、DKIM署名が無効化
• DMARC失敗: SPF/DKIMの失敗により、DMARC認証も失敗

ARCによる解決

ARCは、各転送サーバーで認証結果をチェーン形式で記録します：

ARC-Seal: i=2; a=rsa-sha256; d=forwarder.com; s=arc;
ARC-Message-Signature: i=2; a=rsa-sha256; d=forwarder.com;
ARC-Authentication-Results: i=2;
  dkim=pass header.d=example.com;
  spf=pass smtp.mailfrom=user@example.com;

チェーンの検証プロセス

ARCの検証は、以下の流れで行われます。各中継サーバー（ARC Sealer）はメールを転送するたびに、ヘッダーセットにインスタンス番号（i=）を1つずつ増やしながら自分の署名を追加していきます。

1. 送信元がメールを送信（この時点ではARCヘッダーは存在しない）
2. 1つ目の中継サーバー（例：メーリングリストサーバー）が受信し、その時点でのSPF/DKIM/DMARC結果をARC-Authentication-Results（i=1）に記録
3. メール本文とヘッダーに対してARC-Message-Signature（i=1）で署名し、直前までのチェーン全体をARC-Seal（i=1）で封印
4. 2つ目の中継サーバーが受信した場合、i=2として同様にチェーンを1段追加（cv=passでこれまでのチェーンが有効であることを示す）
5. 最終的な受信サーバー（ARC Evaluator）が、チェーン全体の署名を末尾から遡って検証し、途中経路の認証結果を信頼するかどうかを判断

この「chain validation（cv=）」の値はnone（ARCヘッダーなし）、pass（チェーン検証成功）、fail（署名不正やヘッダー改ざんの疑い）のいずれかを取り、受信側のフィルタリングポリシーの重要な判断材料になります。

ARCの構成要素

3つのヘッダー

ARCは以下の3種類のヘッダーが1セットとなり、転送1回ごとにこのセットが1つ追加されます。同じインスタンス番号（i=）を持つ3つのヘッダーで1つの「署名の輪（Seal）」を構成するイメージです。

ヘッダー名	役割	DKIMとの対応関係
ARC-Authentication-Results (AAR)	その中継サーバーが受信した時点でのSPF/DKIM/DMARC判定結果を記録する。既存のAuthentication-Resultsヘッダーとほぼ同じ内容だが、後から改ざんされないようARC-Sealで保護される	なし（認証結果のログ）
ARC-Message-Signature (AMS)	その時点のメール本文・ヘッダーに対する電子署名。仕組みはDKIM署名とほぼ同一	DKIM-Signatureとほぼ同じ形式（同じ暗号方式・DNS公開鍵の仕組みを流用）
ARC-Seal (AS)	AARとAMS、および1つ前のARC-Sealを含めたチェーン全体に対する署名。cv=（chain validation）でこれまでのチェーンが有効か（pass/fail/none）を示す	DKIM署名を「積み重ねて封印する」役割で、DKIMには存在しない概念

実際のメールヘッダーには、転送回数分だけこの3点セットが積み重なります。例えば2回転送されたメールには、i=1（最初の中継）とi=2（2番目の中継）の2セット、合計6本のARCヘッダーが付与されます。

具体例・ユースケース

ケース1: 社内メーリングリスト運用

典型的なユースケースは、Postfix上に構築した社内メーリングリスト（例：sales-ml@example.com）です。取引先から届いたメールをメーリングリストが全員に再送する際、送信者アドレス（Envelope From）はそのままか、あるいはメーリングリスト自身のアドレスに書き換えられます。前者の場合、受信側のSPFチェックは中継サーバーのIPアドレスで検証されるため、ほぼ確実に失敗します。ここで送信元ドメインがDMARC p=rejectを設定していると、メーリングリスト配信メール自体が受信者側で拒否される事態になります。ARCに対応したメーリングリストサーバー（OpenARCなどをmilterとして組み込む）が、受信時点のSPF/DKIM結果をARCヘッダーとして記録し署名することで、Gmail・Microsoft 365など主要な受信側はARCの検証結果を参考にDMARC失敗を「救済」し、配信を継続できます。

ケース2: 自動転送（.forward）とヘルプデスク集約

問い合わせ窓口用アドレスに届いたメールを、Postfixのvirtual_alias_mapsや個人の.forward設定で別の受信箱（例：Gmailやチケット管理システム）に自動転送している運用も多く見られます。この場合も転送元IPが変わるためSPFが失敗し、転送時にヘッダーが書き換わるとDKIMも失敗します。転送元のメールサーバーがARC署名を付与していれば、転送先の受信サーバーは「本来の送信者ではSPF/DKIMが成功していた」という履歴を確認でき、迷惑メール判定の材料として活用できます。

ケース3: セキュリティゲートウェイ経由の配送

スパムフィルタやサンドボックス型のセキュリティゲートウェイ（Proofpoint、Mimecastなど）を経由してから社内メールサーバーに配送する構成でも、ゲートウェイが中継点となるためSPF/DKIMの検証結果がそのままでは伝わりません。多くの商用ゲートウェイはARC Sealerとして機能し、自ドメインの署名を付けて次段に転送する。これにより社内側のスパムフィルタ（Rspamdなど）はARCの検証結果を加点・減点要素としてスコアリングに利用できます。

実際のARCヘッダー例（3段階の転送）

取引先 → メーリングリストサーバー（forwarder.com） → セキュリティゲートウェイ（gateway.example.net）と2回転送された場合、受信メールのヘッダーには以下のようにi=1とi=2の2セットが積み重なって記録されます。

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arc; cv=none;
  b=abc123...
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=arc;
  h=from:to:subject:date; bh=def456...; b=ghi789...
ARC-Authentication-Results: i=1; forwarder.com;
  dkim=pass header.d=example.com;
  spf=pass smtp.mailfrom=user@example.com;
  dmarc=pass header.from=example.com

ARC-Seal: i=2; a=rsa-sha256; d=gateway.example.net; s=arc; cv=pass;
  b=jkl012...
ARC-Message-Signature: i=2; a=rsa-sha256; d=gateway.example.net; s=arc;
  h=from:to:subject:date; bh=def456...; b=mno345...
ARC-Authentication-Results: i=2; gateway.example.net;
  arc=pass (i=1 spf=pass dkim=pass dmarc=pass);
  dkim=pass header.d=example.com;
  spf=fail smtp.mailfrom=user@example.com

2段目のARC-Authentication-Resultsにあるspf=failは「ゲートウェイ自身が受信した時点でのSPF結果」であり、中継元IPが変わったことで失敗している。しかし同じヘッダー内のarc=passにより、1段目（i=1）の時点では正規の送信者からSPF/DKIM/DMARCすべて成功していたことが検証できる、という点がARCの価値を端的に表しています。

メリット・デメリット

メリット

• 転送メールの配達率向上: メーリングリスト経由のメールが届きやすくなる
• 認証の信頼性向上: 転送チェーンの検証が可能
• DMARC互換性: DMARC Policyとの併用が可能
• 既存インフラとの親和性: DKIMと同じ公開鍵暗号・DNS TXTレコードの仕組みを流用できるため、証明書管理や鍵運用のノウハウがそのまま使える

デメリット・限界

• 「認証」ではなく「参考情報」: ARCはDMARCのように合否を強制するものではなく、あくまで受信側が独自ポリシーで「信頼するかどうか」を判断する参考情報にすぎない。ARCがpassだからといって必ず受信される保証はない
• 受信側の対応状況に依存: ARCの恩恵を受けられるのは、受信メールサーバー側がARC検証ロジックを実装している場合のみ。Gmail・Microsoft 365・Yahoo!などの主要プロバイダは対応済みだが、中小規模のメールサービスやオンプレミスのPostfix単体では、milterを追加導入しない限りARCを評価しない
• 信頼の連鎖が前提: 途中の中継サーバーが悪意を持ってARCヘッダーを偽装した場合、理論上は不正な認証結果を「保証」してしまうリスクがある。そのためARC Sealerとなる中継サーバー自体の信頼性・セキュリティ管理が重要になる
• 運用コストの増加: 鍵生成・DNSレコード管理・milterの死活監視など、SPF/DKIM/DMARCに加えてもう1つ運用対象が増える

混同されやすい用語・類似技術との違い

ARC vs DKIM

DKIMは「送信ドメインの管理者がメールに署名し、改ざんされていないことと送信元の正当性を証明する」ための技術です。ARCはこのDKIMの署名の仕組みをそのまま流用していますが、目的が異なります。DKIMは最初の送信者が1回だけ署名するのに対し、ARCは転送のたびに中継サーバーが署名を積み重ねる点が根本的な違いです。DKIM単体では転送によって署名が壊れる（本文やヘッダーが変更されると検証失敗する）問題を、ARCが「その時点までの検証結果」として保存することで補完します。

ARC vs SPF

SPFは送信元IPアドレスがドメイン管理者の許可したサーバーかどうかを検証する仕組みで、DNSのTXTレコードで許可リストを公開します。転送が発生すると、受信側から見た送信元IPは中継サーバーのIPになるため、SPFは原理的に転送に弱い認証方式です。ARCはSPFの代替ではなく、「転送前の時点でSPFが成功していた」という事実を後段に伝える補助的な記録係の役割を果たします。

ARC vs DMARC

DMARCはSPFとDKIMの結果を組み合わせ、認証に失敗したメールをどう扱うか（none/quarantine/reject）を送信ドメイン側がポリシーとして宣言する仕組みです。ARCはDMARCを置き換えるものではなく、DMARCが転送メールを誤って弾いてしまう副作用を緩和するための補助プロトコルという位置づけになります。DMARCは「送信者側の意思表示」、ARCは「中継者側の証言」と捉えると整理しやすいでしょう。

ARC vs Sender Rewriting Scheme（SRS）

SRSは、転送時にEnvelope From（MAIL FROM）を中継サーバー自身のドメインに書き換えることでSPFチェックそのものを通過させる技術です。ARCとは異なるアプローチで転送問題に対処しますが、SRSはEnvelope Fromを書き換えてしまうためDKIM署名やヘッダーFromのDMARCアライメントには関与しません。実務ではSRS（SPF救済）とARC（検証履歴の保存）を併用することが多く、どちらか一方で十分というわけではない点に注意が必要です。

ARC vs Authentication-Results（既存ヘッダー）

従来から使われているAuthentication-Resultsヘッダーも、受信サーバーがSPF/DKIM/DMARCの判定結果を記録する点ではARCと似ています。しかしAuthentication-Resultsには署名による改ざん防止機能がなく、悪意のある中継者が内容を書き換えたり偽装したりできてしまいます。ARCはこの弱点を補うため、認証結果（AAR）に署名（AMS）とチェーン封印（AS）を組み合わせ、途中経路での改ざんを検知可能にした「強化版」と位置づけられます。

自社メールサーバー運用への応用

Postfixでの設定例

OpenARCを使用したARC対応：

# main.cf
smtpd_milters = unix:/run/openarc/openarc.sock
non_smtpd_milters = unix:/run/openarc/openarc.sock
milter_default_action = accept

# /etc/openarc/openarc.conf
Mode sv
Socket unix:/run/openarc/openarc.sock
Syslog yes
Domain example.com
Selector arc
KeyFile /etc/openarc/arc-key.private

ARC用DNSレコードの例

ARC-Message-Signatureの検証にはDKIMと同様、セレクタ単位で公開鍵をDNSのTXTレコードに公開する必要があります。既存のDKIMセレクタとは別に、ARC専用のセレクタ（例ではarc）を用意するのが一般的です。

; DNSゾーンファイルの設定例
; セレクタ: arc、ドメイン: example.com
arc._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

OpenARCの鍵ペアはopenarc-genkeyコマンドで生成できます。生成後は秘密鍵をopenarcが読み取れるパーミッションで配置し、公開鍵部分をDNSに登録します。

# 鍵ペアの生成例
openarc-genkey -d example.com -s arc -b 2048
# arc.private（秘密鍵）と arc.txt（DNS登録用の公開鍵）が生成される

Dovecotとの関係

ARCの付与・検証はSMTP受信経路（Postfix + milter）で完結する処理であり、IMAP/POP3でメールボックスを提供するDovecot自体はARCの検証ロジックに直接関与しません。ただしDovecotのSieveフィルタ（Sieve）と組み合わせて、ARC検証結果を反映したAuthentication-Resultsヘッダーの値をもとに振り分けルールを作る、といった連携は可能です。ARCの検証結果を迷惑メールスコアに反映させたい場合は、PostfixのmilterチェーンにOpenARCとRspamdを並べ、Rspamd側でARC検証結果を加点・減点要素として設定するのが実務上の定石です。

運用・セキュリティ上の注意点

• 秘密鍵の管理: ARCの秘密鍵はDKIMの秘密鍵と同様に扱い、ファイルパーミッションを厳格化する（例：chmod 600、openarc実行ユーザーのみ読み取り可）。鍵が漏洩すると第三者が任意のチェーンを偽装できてしまう
• 鍵ローテーション: DKIM同様、定期的なセレクタ切り替え・鍵の更新（一般に半年〜1年に一度程度）を検討する。切り替え時は新旧セレクタを一定期間並行運用し、DNSの反映漏れによる検証失敗を防ぐ
• milterのタイムアウト設定: OpenARCがフリーズ・応答遅延した場合に配送が全面停止しないよう、Postfix側のmilter_default_actionや各種タイムアウト値を適切に設定しておく
• 信頼できる中継のみをARC Sealerにする: 社内の複数拠点間中継やSaaS連携など、ARCヘッダーを付与するサーバーは組織として管理・信頼できる範囲に限定する。外部の得体のしれない中継サーバーが付与したARCヘッダーを無条件に信頼するのは避けるべき
• ログの保全: OpenARCのSyslog出力を残し、ARC署名・検証の失敗が続く場合に原因（DNS設定ミス、鍵の不整合など）を追跡できるようにしておく

関連ブログ記事

• メール認証技術SPF/DKIM/DMARC
• Docker Mailserver完全ガイド

2025-2026年の最新動向

Gmail・Microsoft 365でのARC検証強化が進んでいます。2024年以降、GmailはDMARC p=rejectポリシーのドメインからの転送メールに対してARC検証を重視するようになり、ARC対応が配達率に直結する状況になっています。

DMARC p=rejectの普及に伴い、ARCの重要性が急上昇しています。金融機関・政府機関でのDMARC厳格化により、メーリングリスト運営者にとってARC対応は必須要件となりました。

OpenARC 2.0の開発が進行中で、Ed25519署名のサポートやパフォーマンス改善が予定されています。従来のRSA署名に加え、より軽量で高速な署名アルゴリズムの選択肢が広がります。

外部リンク

• RFC 8617 - The Authenticated Received Chain (ARC) Protocol
• DMARC.org - ARC FAQ
• Google Workspace - メール認証のベストプラクティス

関連用語

• SPF - 送信元IPアドレスを検証するメール認証
• DKIM - 電子署名によるメール認証
• DMARC - SPF/DKIMに基づくメール認証ポリシー
• Postfix - 高性能メール転送エージェント
• STARTTLS - メール通信の暗号化プロトコル

まとめ

ARCは、メール転送時の認証情報を保護する重要なプロトコルです。メーリングリストや転送サービスを運用する場合、ARCの導入により、配達率の向上と認証の信頼性確保が可能になります。SPF/DKIM/DMARCと組み合わせることで、より堅牢なメールセキュリティを実現できます。

AIエンジニアとしての実務経験

ARCの重要性を実感したのは、社内メーリングリストからの転送メールがGmailで迷惑メール判定されるようになった時でした。DMARC policy がrejectに設定されたドメインからのメールが、メーリングリスト経由で転送されると、DKIMが破損しDMARCが失敗するという問題でした。

OpenARC（OpenDKIMの姉妹プロジェクト）を導入し、転送サーバーでARC署名を追加するように設定しました。ARC-Seal、ARC-Message-Signature、ARC-Authentication-Resultsの3つのヘッダーが正しく追加されるようになり、Gmailでも正常に配信されるようになりました。

ARCチェーン（i=パラメータでインクリメントされる番号）の検証は、転送経路が信頼できるかどうかの判断に使われます。Googleのサーバーを経由した転送や、信頼されたメーリングリストプロバイダからのARCは、より高く評価されます。

ARCの最新動向（2025年）

• Gmail/Outlook採用拡大: 大手メールプロバイダでのARC検証が標準化
• DMARC連携強化: ARC結果をDMARC判定に組み込む実装の普及
• 信頼チェーン: 信頼できるARC署名者のホワイトリスト共有の動き
• 自動化ツール: ARC設定の自動検証・デバッグツールの充実
• RFC更新: ARC仕様の改良版が議論中

よくあるトラブルと失敗例

• 鍵ペアの不整合: DNS公開鍵と秘密鍵が一致しない。digで確認
• セレクター設定ミス: DKIMとは別のセレクターが必要。arc._domainkey等
• ヘッダー順序: ARC-*ヘッダーの順序が間違っていると検証失敗
• チェーン番号: i=値を正しくインクリメントしていない
• cv値の誤り: 前段ARCの検証結果（cv=pass/fail）を正しく記録していない
• milter設定: OpenARCとOpenDKIMの両方を使う場合、milterの順序に注意

権威ある外部リソース

• RFC 8617 - ARC仕様書
• OpenARC - GitHub
• dmarcian - ARC解説
• MXToolbox - ARC検証ツール
• Google - 一括送信ガイドライン（ARC言及）

この用語についてもっと詳しく

ARCに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。