ARC(Authenticated Received Chain)

ARC

メール転送に弱いSPF/DKIM/DMARC認証を補完

更新日

ARCアーク（Authenticated Received Chain）は、メール転送時に認証情報を保持・伝達するための技術仕様です。
メールが複数のMTA（メール転送エージェント）を経由する際、各段階でのSPF、DKIM、DMARCの認証結果をヘッダーに記録し伝播させます。
これにより、転送やメーリングリスト経由で認証が失敗する問題を回避できます。

ARCでは、各MTAが「認証履歴チェーン」を形成するため、ARC-Seal（AS）、ARC-Message-Signature（AMS）、ARC-Authentication-Results（AAR）の3種類のヘッダーを付加します。
これにより、どのMTAがどのような認証評価を行ったかが追跡可能となり、最終受信者は信頼性の高い情報を基にメールの取扱いを判断できます。

ARCの仕様は、2019年に公開されたRFC8617に詳細が記載されています。

ARCの必要性

要点：SPF・DKIM・DMARCは転送時に認証が失敗する問題があり、ARCはこれを解決するために認証結果を転送経路上で保持・伝達します。

メールのドメイン認証は、SPF、DKIM、DMARCの3方式で行われますが、転送によって認証が失敗する問題があります。
ARCは、転送経路上で認証結果を保持・伝達することでこの問題を解決します。

SPFの転送問題
SPFは、送信ドメインが許可するMTAのIPアドレスリストを基に正当性を確認します。
転送時、再送信MTAのIPアドレスが元のリストに含まれないため、SPFチェックが失敗します。
DKIMの転送問題
DKIMは、ヘッダーと本文から生成したハッシュ値を秘密鍵で署名して認証を行います。
転送時にヘッダー変更、件名への「FW:」追加、本文追記が行われると、署名が無効になります。
メーリングリスト経由ではリスト情報が追加されるため、特に問題が顕著です。
DMARCの転送問題
DMARCは、Envelope FromやDKIM署名ドメインとヘッダーFromの一致を確認します。
転送時にEnvelope Fromが転送者アドレスに変わるため、ドメイン一致が崩れて認証失敗となります。

ARC導入が推奨されるケース

要点：以下に該当する場合、ARC導入を検討してください。

Gmail/Microsoft365のみを使用している場合は、ARCが自動設定されているため追加対応は不要です。

転送メールの認証プロセス

要点：転送時、受信側MTAはメール内の情報を元に認証を実施し、転送元MTAのDNSには問い合わせません。元の送信ドメインのDNSレコードを参照します。

ここで云う「転送」とは、受信箱に入ったメールを別アドレスへ転送することを指します。
MTA間の経由は「SMTPリレー」と呼ばれ、転送とは異なります。

転送時、受信側MTAは転送元MTAのDNSではなく、メール内の情報を元に認証を実施します。

1. メールの送信
送信元MTAは、DKIM署名を付加して認証情報を埋め込みます。
SPFの検証は受信側MTAで行われます。
2. メールの受信
受信側MTAは、SPF、DKIM、DMARCの検証を行います。
日本で普及しているPostfixはDKIM/DMARCに標準対応していないため、別途モジュールのインストールが必要です。
3. メールの転送
転送MTAは、SRS（Sender Rewriting Scheme）によりEnvelope Fromを転送ドメインのアドレスに変更する場合があります。
SPFはSRSで合格できますが、DMARCのアライメントチェックはヘッダーFromとEnvelope Fromが異なるため不一致となります。
DKIM署名は、転送MTAが対応していれば転送ドメインでの再署名が付与されます。
4. 転送メールの最終受信
転送受信側MTAは、メール内のEnvelope FromやDKIM署名を基に、送信ドメインのDNSレコードを問い合わせて認証を再実施します。
転送元MTAのDNSには問い合わせません。

ARCの仕組み

要点：ARC対応MTAは、認証結果をARCセット（i=1, i=2...）として連鎖的に記録し、最終受信者が元の認証情報を参照できるようにします。

ARCの仕組み
ARCの仕組み

ARCを組み込むと、転送と認証の流れが以下のように変化します。
各ステップはARC対応MTAでの処理を前提としています。

1. メールの送信
送信元MTAはDKIM署名を付加し、ARC対応であれば最初のARC署名（i=1）を付与します。
※ Google WorkspaceやMicrosoft365で独自ドメインのDKIM設定が未実施の場合、初回ARC署名が付与されないことがあります。
2. 初回のメール受信
受信側MTAは3方式の検証を行い、ARC対応であれば検証結果を元にARCセット（i=1）を付与します。
3. メールの転送
転送MTAはSRSでEnvelope Fromを変更する場合があります。
SPFはSRSで合格しますが、DMARCアライメントは不一致となる可能性があります。
ARC対応の転送MTAでは、ARCセット（i=2）が追加されます。
4. 転送メールの最終受信
最終受信側MTAは、SPF/DKIMの再検証に加え、ARCヘッダーを検証して転送中の認証情報変化を確認します。
DMARC評価もARCの元認証情報を考慮するため、転送メールでも適切に認証される可能性が高まります。

ARCにより、転送中も認証情報が連鎖的に保持され、元の認証情報に基づく信頼性評価が可能になります。

ARCの前提条件と制約

要点：ARCはDKIM設定が前提であり、経路上の全MTAがARC対応でないと認証チェーンが途切れます。

前提条件
  • 送信ドメインでDKIM署名が設定済みであること
  • ARC署名用の鍵ペア（RSA 2048bit以上またはEd25519）が生成されていること
  • DNSにARC用セレクタの公開鍵がTXTレコードとして登録されていること
制約・限界
  • 経路上のMTAがすべてARC対応でない場合、認証チェーンが途切れる
  • 受信側MTAがARCを信頼するかは受信側ポリシーに依存する
  • ARCは「信頼できる転送経路」を前提とし、未知MTAからのARCヘッダーは信頼性が低い
  • RFC8617ではARCチェーンの最大長は50と規定されている

ARCヘッダの仕様

要点：ARCは3種類のヘッダー（AAR：認証結果記録、AS：完全性保証署名、AMS：改竄検知署名）で転送中の認証情報を維持します。

ARCは以下の3つのヘッダーをメールに追加し、転送時に元の認証情報を維持します。

ARCヘッダー3種の概要
略称正式名役割署名対象
AARARC-Authentication-Results認証結果の記録なし（データのみ）
ASARC-SealARCチェーンの完全性保証AAR + AMS + 前のAS
AMSARC-Message-Signatureメール内容の改竄検知ヘッダー + ボディ

AAR（ARC-Authentication-Results）

AARは、前ホップMTAでの認証結果を記録します。
SPF、DKIM、DMARCの各結果が含まれ、次ホップで元の認証状態を提供します。 


i=1; mx.google.com;
dkim=pass header.i=@domain.com header.s=xyz header.b=Q9TN1jXp;
spf=pass(google.com: domain of user@domain.com designates 101.53.164.222 as permitted sender)
smtp.mailfrom=user@domain.com;
dmarc=pass(p=REJECT dis=NONE) header.from=domain.com

このAARは、domain.comからの正当なメールが全認証に合格したことを記録しています。

i=1; mx.google.com;
ARCセットのインスタンス番号（i=1はチェーンの最初）と、処理したMTA（mx.google.com）を示します。
dkim=pass header.i=@domain.com header.s=xyz header.b=Q9TN1jXp;
DKIM検証が合格。署名ドメインはdomain.com、セレクタはxyz、署名値の先頭部分がQ9TN1jXpです。
spf=pass ... smtp.mailfrom=user@domain.com;
SPF検証が合格。domain.comがIPアドレス101.53.164.222を許可送信元として指定しています。
dmarc=pass(p=REJECT dis=NONE) header.from=domain.com
DMARC検証が合格。ポリシーはREJECT（不合格メールは拒否）、dis=NONEは合格のため処置不要を示します。

AS（ARC-Seal）

ASは、ARCヘッダー全体の完全性を保証する署名です。
AARとAMSが改竄されていないことを確認するために使用され、各ホップで新たに生成されます。 


i=1; a=rsa-sha256; t=1608028598; cv=none;
d=google.com; s=arc-20160816;
b=u1Tiu150Jf7sRT49ZVeFUaBLUbSILgotn8kMYGlzMA5L7sRZmFDv03aiFM0LrNdJ/A+bFlt9A+6gAcGFGYyZGWBSeb+h3WqPMfjVC7GdLdrTQPFUkG19DrazsgHo2/hEbg2WbnqVzBxJB500yYVqwlph1pntaG/YWZSN2Wawr9HHgeQJvb9Ed/BHSM7gfj7zxOBUhvbqXLmp6DaBtTpyMZYh5taAoR8DBdYS7fLuUER7S2fA50S6h7GpCtuWWErlGpop1LXSDH/WHOw1rWzq01tC8P5zbavayZ+YsANKL4By+kqQrlOAPO4N3g+YaDyjxnTiL2eG+eEbLrGqKAD2/g==

このASは、mx.google.comでの認証を電子署名で担保しています。

i=1;
ARCセット番号。チェーンの最初のセットに紐づきます。
a=rsa-sha256;
署名アルゴリズム。RSAとSHA-256ハッシュを使用。
t=1608028598;
署名生成時刻（UNIXタイムスタンプ）。
cv=none;
Chain Validation（チェーン検証状態）。noneは前のARCセットがない、または検証未実施を示します。
d=google.com; s=arc-20160816;
署名ドメイン（google.com）とセレクタ（arc-20160816）。
b=u1Tiu150...
署名本体。AARとAMSを含むメッセージ部分をハッシュ化し、秘密鍵で暗号化したものです。

AMS（ARC-Message-Signature）

AMSは、メール本体とヘッダーのDKIMスタイル署名です。
転送中にメール内容が改竄されていないことを保証します。 


i=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=arc-20160816;
h=mime-version:subject:message-id:cc:to:from:date:dkim-signature;
bh=utFVsQV90imCkfdAbs4rSFF+Hh1llV6Wdr1n2w6XqxA=;
b=L7JNVN7na3akSOKhBXao0YbGpYAootoeq80HHhuHbDsFoZAH47Kjb92JZh8xjcZp32vrtOSBFh+1PLWAwsJX8MOfz8/l1du6HOI1NdF32efp7nOIQOQYWzI3UEaVHEwli2D71SNvNgz/Zx5KaL5NBsqLrlytLaw343MhvFT2vRd9gBV23BIM7ihRe3WsEo2islcLwzxvuTFKgillU6m1vJUDQxFLnjngcYs/URfmV3Zu83VdlV2igAlq2CpWdA4u9jo2gJDGOfselSOZITc9W4sFRcJ/2rbwUaVW4f5TMNhIZ2YpHXOn87lh/yB5/1w6nLXOyVjmp5qp6WE/2ELYIg==

このAMSは、メール内容の改竄有無を署名で担保しています。

i=1;
ARCセット番号（前述）。
a=rsa-sha256;
署名アルゴリズム（前述）。
c=relaxed/relaxed;
正規化ポリシー。ヘッダーと本文の両方に寛容な処理を適用し、空白や行折り返しの差異を許容します。
d=google.com; s=arc-20160816;
署名ドメインとセレクタ（前述）。
h=mime-version:subject:...
署名対象ヘッダーフィールドのリスト。
bh=utFVsQV90...
ボディハッシュ値。本文が署名時点から変更されていないことを保証します。
b=L7JNVN7na...
署名本体。指定ヘッダーと本文ハッシュに基づいて生成されます。

ARCの対応状況

要点：Gmail/Google Workspace、Microsoft365などの主要サービスはARC対応済みです。自社MTAはarc-spec.orgで対応ソフトウェアを確認できます。

ARC対応のMTAやMailing List Managerの一覧は、 "ARC Specification for Email"のResourcesに掲載されています。

PowerDMARCでのARC検証

要点：PowerDMARCでARCチェーンの検証状態を可視化し、転送メールの認証失敗原因を特定できます。

PowerDMARCのフォレンジック機能では、受信メールのARCヘッダーを解析し、以下の情報を確認できます。

DMARCレポートと組み合わせることで、転送メールの認証失敗原因を特定し、対策を検討できます。
特に、メーリングリスト経由のメールや社内転送ルールによる認証失敗の原因調査に有効です。

ARC検証で確認できる情報
項目内容確認ポイント
cv（Chain Validation）ARCチェーン全体の検証結果pass以外の場合、どのホップで問題が発生したか
AAR履歴各転送段階でのSPF/DKIM/DMARC結果どの段階で認証が失敗し始めたか
AS署名各ホップでのARC署名の有効性署名が無効な場合、鍵の問題か改竄か
転送経路メールが通過したMTAの一覧想定外のMTAを経由していないか

まとめ

要点：ARCはSPF/DKIM/DMARCを補完し、転送時の認証問題を解決します。主要サービスは対応済みですが、自社MTAでは手動設定が必要です。

SPF、DKIM、DMARCは広く用いられる認証手法ですが、転送時に認証が失敗することがあります。
ARCはこの問題に対処するために設計された技術で、3方式を補完し、転送中の認証情報を保存・維持します。

Gmail/Google WorkspaceやMicrosoft365ではARCがデフォルト設定されており、ARCヘッダーが自動付与されます。
自社でMTAやメーリングリストシステムを運用している場合は、ARCの設定を手動で行う必要があります。

よくある質問（FAQ）

要点：ARCに関するよくある質問と回答をまとめました。

Q1. ARCとは何ですか？
A. ARC（Authenticated Received Chain）は、メールが複数サーバを経由して転送される際に、各段階での認証結果をヘッダーに記録し伝播させる技術仕様です。 RFC8617で2019年に標準化されました。
Q2. ARCはなぜ必要なのですか？
A. 転送時、以下の理由で認証が失敗することがあります。
  • SPF：転送MTAのIPアドレスが元のSPFレコードに含まれない
  • DKIM：転送時のヘッダー変更や本文追記で署名が無効化
  • DMARC：Envelope Fromが転送者アドレスに変更されアライメント不一致
ARCは転送前の認証結果を保持し、この問題を解決します。
Q3. ARCの3つのヘッダーの役割は？
A. ARCは以下の3種類のヘッダーを使用します。
  • AAR：各転送段階での認証結果（SPF/DKIM/DMARC）を記録
  • AS：ARCヘッダー全体の完全性と信頼性を保証する署名
  • AMS：メール本文とヘッダーが改竄されていないことを保証する署名
Q4. 主要メールサービスはARC対応していますか？
A. はい、以下の主要サービスはデフォルトでARC対応済みです。
  • Gmail / Google Workspace
  • Microsoft 365 / Outlook.com
  • Yahoo! Mail
これらではARCヘッダーが自動付与されます。
Q5. 自社MTAでARCを導入するには？
A. ARC対応のMTAソフトウェアまたはmilterを導入し、DKIM署名と同様の鍵ペアを生成してDNSに公開鍵を登録します。
対応ソフトウェア一覧はarc-spec.org Resourcesで確認できます。
Q6. ARCとDKIMの違いは？
A. DKIMは送信元ドメインがメールに署名を付与し、改竄検知と送信元認証を行います。
ARCは転送経路上の各MTAが認証結果を連鎖的に記録・署名し、転送後も元の認証情報を参照可能にします。
ARCはDKIMの補完技術です。
ARCとDKIMの比較
観点DKIMARC
署名者送信元ドメインのみ各転送MTA
目的送信元認証・改竄検知転送時の認証情報保持
署名対象ヘッダー+ボディ認証結果+ヘッダー+ボディ
チェーンなし（単一署名）あり（連鎖的に蓄積）
転送耐性低い高い
Q7. ARC非対応MTAからのメールはどうなりますか？
A. ARC非対応MTAからのメールでも、従来通りSPF/DKIM/DMARCによる認証は行われます。
ただし、そのメールが転送された場合、ARCヘッダーが付与されないため、転送先で認証が失敗する可能性があります。
受信側MTAがARC対応の場合、ARCヘッダーがないメールは従来の認証結果のみで判断されます。

用語集（Glossary）

要点：本ページで使用する主要技術用語の定義です。

ARC（Authenticated Received Chain）
転送時に認証結果を連鎖的に保持・伝達する技術仕様。RFC8617で標準化。
SPF（Sender Policy Framework）
送信ドメインが許可するメール送信サーバのIPアドレスをDNSに公開し、なりすましを防ぐ認証技術。RFC7208で標準化。
DKIM（DomainKeys Identified Mail）
メールに電子署名を付与し、送信元の正当性と改竄有無を検証する認証技術。RFC6376で標準化。
DMARC（Domain-based Message Authentication, Reporting and Conformance）
SPFとDKIMの認証結果を組み合わせ、なりすましを防ぐポリシーを公開・適用する技術。RFC7489で標準化。
MTA（Mail Transfer Agent）
メールを転送するサーバソフトウェア。Postfix、Sendmail、Microsoft Exchange等が代表例。
Envelope From（エンベロープFrom）
SMTPプロトコルで使用される実際の送信者アドレス。Return-PathやMAIL FROMとも呼ばれる。
Header From（ヘッダーFrom）
メールクライアントに表示される送信者アドレス。メールヘッダーのFromフィールドに記載。
SRS（Sender Rewriting Scheme）
転送時にEnvelope Fromを書き換え、転送先でのSPF検証を通過させる仕組み。
アライメント（Alignment）
DMARCにおいて、Header FromとEnvelope From（SPF）またはDKIM署名ドメインの一致を確認する検証。

関連仕様・参考文献

要点：ARCおよび関連技術の一次情報・公式仕様へのリンクです。

RFC（技術仕様書）

公式リソース