メールのARCとは？ ARCの仕組み、設定が必要なケースを解説

Last Updated on 2024.08.1

送信ドメイン認証のSPFやDKIM、DMARCはメールの信頼性を高めるメリットがありますが、一方で正当なメールであっても、認証プロセスに失敗してしまうこともあります。このような課題に対応するために考案された仕組みがARC認証です。Gmailの送信者ガイドラインにおいても、メールを定期的に転送する場合はARCヘッダを追加することが推奨されています。本記事ではARCの概要や仕組み、設定方法について詳しく解説します。

ARCとは

ARC（Authenticated Received Chain）とは、転送経路上での認証結果を保持し、最終的な受信者がそのメールの信頼性を判断できるようにする仕組みです。

ARCが必要とされる背景

ARCは、主にメールが転送される過程で生じる認証の問題に対処するために考案されました。従来のSPF・DKIM・DMARCといった送信ドメイン認証技術は、送信者から受信者へメールが変更されずに直接配信されることを想定しています。
しかし、メーリングリストや自動転送ルールなど、メールが複数のサーバーを経由して転送される場合、SPFやDKIMの検証が失敗することがあります。

例えば、SPFはメール送信者のドメインによって許可されたIPアドレスからメールが送信されたかどうかを検証しますが、メールの転送によりIPアドレスが変更されると、SPFの認証に失敗してしまいます。
DKIMは、電子署名を利用してメールが送信時からメールが改ざんされていないか検証を行うため、メールが転送される際にヘッダ情報や件名などが変更されると、DKIM認証に失敗することになります。
DMARCはSPFとDKIMの認証結果を使用するため、両者が認証に失敗してしまえば当然DMARCも認証に失敗することになります。

ARCは、メールが受信者に届くまでの間に中継された各サーバーにおける認証結果を保持するため、最終的な受信者が認証履歴を元にそのメールの信頼性を判断できるようになるのです。

ARCのメリット

誤検知の防止

転送やメーリングリスト、中継サーバーによる要因で正当なメールがSPF・DKIM・DMARCの認証に失敗してしまうことを防止するのに有効です。認証失敗のリスクを軽減することで、スパムとして誤検知されることを防ぎます。

到達率の向上

上記とも関連して、認証失敗を防止することでメール到達率の改善が期待できるでしょう。2024年2月から適用されたGmailの新しい送信者ガイドラインにおいても、メーリングリストや受信ゲートウェイを利用する場合など、定期的にメールを転送する環境ではARCヘッダの追加を推奨しています。Google以外のメールサービスプロバイダもこの基準に追随することが想定されるため、該当する場合は対応するのが望ましいでしょう。

参考：Google Workspace管理者ヘルプ「メール送信者のガイドライン」https://support.google.com/a/answer/81126?hl=ja

セキュリティの強化

ARCは転送中のメールの改ざんや変更の検出に役立ち、メールに追加の保護を提供します。SPF・DKIM・DMARCと併せて使用することで、包括的なメールセキュリティを確保できます。

ARCの普及状況

ARCの仕様は2019年7月に公開されたRFC 8617で定義されていますが、ステータスは「Experimental」（試験・実験・評価のための公開）となっており、まだ広く普及しているわけではありません。現状はGmailやMicrosoft 365でホストされるメールボックスではARCが有効になっています。今後はRFCのステータスがどのように変更されるかにもよりますが、おそらく多くのメールシステムでARCの実装が進むのではないかと考えられます。

ARCのプロセス

ここでは、ARCが活用される具体的なプロセスを解説します。

1. メールの送信

yumi@test.jpからメーリングリストのgroup@example.com宛にメールを送信します。このメールはSPF・DKIM・DMARCによって認証されています。

2. メーリングリストサーバーでの認証

メーリングリストサーバーがメールを受信し、受け取ったメールがSPF・DKIM・DMARCに合格していることを確認します。

3. メーリングリストサーバーでの処理

受け取ったメールをメンバーであるkenji@sample.jp宛に転送する際に、メールの件名に”Community Member”という文字列を追加し、フッターに購読解除リンクを追加します。
この操作ではメールの内容が変更されるため、通常はDKIM署名の検証が失敗する原因になります。

4.ARCヘッダの追加

メーリングリストサーバーは、メールが最初に受信された際のSPF・DKIM・DMARC認証の結果をAARヘッダに記録し、AMSヘッダおよびASヘッダのARCセットを追加してメールを再署名します。

5. メールの再配送

メーリングリストサーバーは、ARCヘッダを追加したメールをkenji@sample.jp宛に転送します。

6.最終受信先での認証

kenji@sample.jpのメールサーバーでは、受信したメールの認証を行います。もとのSPF・DKIM・DMARCはメーリングリストサーバーによる変更のために認証に失敗してしまいます。
しかし、ARCヘッダがあるため、ARCチェーンを検証します。チェーン内のすべてのARC署名が信頼できる場合、認証失敗によるDMARCの指示も無効にして、メールを受信することができます。

ARCの仕組み

ここでは、ARCを実現するための技術的な仕組みについて解説します。

Receivedヘッダとの違い

メールの配信経路を追跡するためには、「Received:」ヘッダを確認するという手段もあります。Receivedヘッダはメールが転送されるたびに、メールが通過した各サーバーの情報（例: IPアドレス、ホスト名、タイムスタンプ）が追加されるものです。

Receivedヘッダはメールの経路追跡、デバッグ、スパム検出の手がかりとして使用されていましたが、その情報が正しいのか検証する仕組みはないため信頼性が低いという課題がありました。

ARCヘッダとは

ARCではメールの配信経路の記録を保証するために、サーバーを経由する際に次の3つの新しいメールヘッダを追加します。以下の3つのARCヘッダをまとめて1つの「ARCセット」と呼びます。

ARC-Authentication-Results（AAR）
ARC-Message-Signature（AMS）
ARC-Seal（AS）

ARC-Authentication-Results（AAR）

各中継サーバーがメールを受け取った際のSPF・DKIM・DMARCなどの認証結果を記録するために使用されます。

サンプル：

ARC-Authentication-Results: i=1; example.org; spf=pass (example.org: domain of sender@example.com designates 192.0.2.43 as permitted sender) smtp.mailfrom=sender@example.com; dkim=pass header.d=example.com header.s=selector1 header.b=ABC123; dmarc=pass (p=NONE sp=NONE) d=example.com;

i=1：ARC署名が何番目かを示し、メールが複数回転送される場合この値は増加します。また、同じARCセットのヘッダは全て同じ値が記載されます。
example.org：この認証結果を生成したドメイン名。
spf=pass：SPFによる認証結果。この例では、送信者のドメインがメールの送信に許可されているIPアドレスから送信されたことを示しています。
dkim=pass：DKIMによる認証結果。送信者ドメインの署名が確認され、有効であることを示しています。
dmarc=pass：DMARCによる認証結果。DMARCポリシーに基づいて、メールが正しく認証されたことを示しています。

ARC-Message-Signature（AMS）

メールの認証情報（SPF、DKIMの結果など）とともに、メールの具体的な内容（本文や一部ヘッダ）が変更されていないことを保証するための電子署名です。これにより、メールが中継される各ステップで、メッセージの信頼性が保たれるようにします。

サンプル：

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; h=message-id:date:from:to:subject; s=selector1; t=1516809275; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b= XYZ...;

i=1：ARC署名が何番目かを示します。
a=rsa-sha256：使用される電子署名のハッシュ化アルゴリズム。
c=relaxed/relaxed：正規化方法を示しています。ここではrelaxed（緩和された）正規化方法が使用されています。
d=example.org：メールを送信したドメイン。
s=selector1：セレクター。署名に使用される公開鍵をDNSから取得する際に使用されるラベル。
t=1516809275：署名が生成されたタイムスタンプ（UNIX時間）。
h=from:to:subject:date:message-id:content-type:mime-version：電子署名が適用されるヘッダフィールドのリスト。
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=：メール本文（body）のハッシュ値。ここではBase64エンコードされています。
b=XYZ…：デジタル署名本体。実際にはBase64エンコードされた長い文字列です。

ARC-Seal（AS）

そのメールに対するARCヘッダの信頼性を保証するためのデジタル署名です。ARC-Sealは、メールが各中継ポイントを通過する際の認証状態を「封緘」することで、認証情報（ARCチェーン）の完全性を保証します。

サンプル：

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=example.org; s=selector1; t=1516809275; b=XYZ...;

i=1：ARC署名が何番目かを示します。
a=rsa-sha256：使用される電子署名のハッシュ化アルゴリズム。ここではrsa-sha256が使用されています。
d=example.org：メールを送信したドメインを示します。
s=selector1：セレクター。署名に使用される公開鍵をDNSから取得する際に使用されるラベルです。
t=1516809275：署名が生成されたタイムスタンプ（UNIX時間）。
cv=none：前のARC認証プロセスの結果。ここではnoneが示されていますが、他にfailやpassなどがあります。
b=XYZ…：デジタル署名本体。実際にはBase64エンコードされた長い文字列になります。

ARCチェーン検証結果

特定のステップにおけるARCの検証結果は、ASヘッダのcv= (chain validation status) のフィールドに以下の値で示されます。

none：ARC情報が存在しない
pass：検証成功
fail：検証失敗

ARCチェーンの検証結果は、そのメールの1つめのARCセット（i=1）の場合は必ず「none」となります。これは検証済みのARCヘッダが含まれていないことを示し、元の送信者から直接受け取った場合、またはARCの検証に参加しない上流のサーバーから受け取った場合に発生します。

それ以降のARCセット（i=2以上）の場合は必ず「pass」となる必要があり、もし「fail」となった場合はそこでARCチェーンの検証は失敗し、そこでARCは終了します。

ARCの設定が必要なケース

最後に、ARCの設定が必要なケースについて解説します。

ARCのプロセスを見れば分かる通り、ARCの署名を行うのはメーリングリストや転送を行うサーバーであり、元の送信者はARC署名を行わないため設定の必要はありません。メーリングリストや転送などを行うサーバーを管理している場合は、ARCに対応することをお勧めします。

ARCを設定した方が良いケース

送信元や件名、本文の書き換えが発生するメーリングリストサーバー
送信元や件名、本文の書き換えが発生するメールゲートウェイサーバー
メインのメールサーバーから、別のメールサーバやメールサービスに転送するケース
※ 会社のメールサーバーからGmailに転送しているなど

メーリングリストマネージャーのソフトウェアによっては、既にARCに対応しているものもあります。その他、ARCを実装するためのライブラリやパッケージなども公開されています。

「OpenARC」というARC署名および検証を行うためのオープンソースのソフトウェアをインストールし、PostfixなどのMTAと紐付けを行うことでARCの設定が可能です。詳細な設定手順については、検証後ブログにて別途公開いたします。

参考：ARC SPECIFICATION FOR EMAIL「Resources」https://arc-spec.org/?page_id=79 （2024/3/26確認）

まとめ

ARCは、メールが転送される過程での認証情報を保持し、そのメールが最終的な受信者に届いたときにその信頼性を判断できるようにする仕組みです。再配送が原因でDKIMやDMARCの認証に失敗したメールでも、ARCヘッダによりそれより前の段階での認証結果を確認できるため、正当なメールがブロックされることを防止できます。
Gmailも定期的な転送を行う場合にはARCヘッダの追加を推奨しているため、メーリングリストサーバーなど中継を行うサーバーを運用している場合は、ARCの対応を検討してみてはいかがでしょうか。