ARC（Authenticated Received Chain）

ARC が重要な理由

ARC が解決する問題は次のとおりです。あなたが送信したメールが、すべての認証チェック（SPF、DKIM、DMARC）を通過したとします。 完璧です。 ところが、その後で誰かがそのメールを会社のメールサーバー経由で転送したり、フッターを追加するメーリングリストを通したりします。 そうした変更によって、元の認証署名が無効になることがあります。

その次に何が起こるでしょうか？ 受信サーバーには、あなたから送られたと主張しているのに、もはや認証を通過しないメッセージとして見えてしまいます。 スパムフォルダ行きです。 あるいはさらに悪いことに、完全に拒否されます。

ARC は、信頼の連鎖を作ることでこの問題を解決します。 メッセージを扱う各サーバーは独自の ARC 署名を追加し、「このメールはここに到着した時点では正当なものであり、転送前に少し変更を加えた」ということを記録します。 これは、各走者が正当にバトンを受け取ったことを確認して署名するリレー競走のようなものだと考えるとわかりやすいでしょう。

Google のメール送信者向けガイドラインによると、転送メールは ARC がない場合、認証チェックに失敗する可能性が大幅に高くなります。 つまり、多くの正当なメールがブロックされてしまうのです。

ARC はどのように機能するのですか？

このプロトコルは、メールがサーバーを経由していく際に、3つの主要なヘッダーを追加します：

ARC-Authentication-Results は、どの認証チェックが実行され、通過したかどうかを記録します。 これは、このサーバーに最初に到着した時点で、あなたのメールが有効な DKIM と SPF を持っていたことを示す成績表のようなものです。

ARC-Message-Signature は、その時点でのメッセージ内容に対する暗号署名を作成します。 これにより、経路の途中でメッセージが悪意をもって改ざんされていないことを証明できます（転送のための小さな変更は想定内であり問題ありません）。

ARC-Seal は、連鎖全体を検証する別の署名によって、すべてを結び付けます。 各サーバーは独自のシールを追加し、連結されたシーケンスを作成します。 チェーン内のいずれかのリンクが壊れていたり不審だったりすれば、受信サーバーはそれを検出できます。

巧妙なことに、このチェーンには番号が振られています。 ARC-Seal: i=1、次に i=2、そして i=3。 受信サーバーは、欠落がないこと、そして正当な各中継サーバーが前の段階を適切に認証していることを確認できます。

また、内容が変わると壊れてしまう古いプロトコルとは異なり、ARC は変更が加わることを前提としています。 それがまさに要点です。 これは、そうした変更が、あなたのメールを傍受した攻撃者によるものではなく、信頼できるサーバーで発生したことを記録するだけです。

ARC の設定

ARC では、中継サーバー（メッセージを転送または変更するサーバー）と受信サーバー（ARC チェーンを検証するサーバー）の両方で設定が必要です。 ほとんどのユーザーは、自分でメールインフラを運用していない限り、何もする必要はありません。

Gmail の場合：

Gmail は、転送メッセージを受信する際に ARC 署名を検証します。 Gmail にメールを転送する場合は、中継サーバーが ARC ヘッダーを追加する必要があります。 Google Workspace を使用していて、自社サーバー経由で他の宛先にメールを転送している場合は、メールサーバーが ARC ヘッダーを追加するよう設定してください。 Google は、転送サービスを管理する管理者向けに、メール送信者向けガイドラインで詳細な案内を提供しています。

Outlook の場合：

Exchange Online は ARC 検証をサポートしていますが、管理者は信頼する ARC sealer を設定する必要があります。 Microsoft Defender ポータルを開き、Email & Collaboration > Policies & Rules > Threat policies > Email Authentication Settings > ARC に移動します。 メールを処理する中継サービスのドメインを追加します（これらは ARC-Seal ヘッダー内の "d" タグと一致している必要があります）。 朗報です。Microsoft 365 組織は、他の Microsoft 365 組織からの ARC 署名を自動的に信頼するため、この部分はすでに処理されています。

Spark の場合：

Spark は、メールプロバイダー（Gmail、Outlook、カスタム IMAP サーバー、または Microsoft 365 のような EWS アカウント）で設定されたメール認証設定に依存します。 Spark はメールクライアントであるため、ARC の署名や検証を直接行いません。 それは、メッセージが受信トレイに届く前にサーバーレベルで行われます。

カスタムメールサーバーの場合：

独自のインフラを運用している場合は、SMTP サーバーに ARC サポートを追加する必要があります。 Postfix と Sendmail で最も一般的な実装は OpenARC です。 OpenARC をインストールし、送信メールに署名し、受信チェーンを検証するよう設定したうえで、必要な構成を追加します（DKIM の設定に似ていますが、ARC には DNS レコードは不要です）。

難しい点は何でしょうか？ ARC が役立つのは、中継サーバーと最終受信サーバーの両方がこれをサポートしている場合だけです。 宛先側が ARC を検証しなければ、そのチェーンに意味はありません。 しかし、導入は急速に広がっています。 現在では、Gmail、Yahoo、Microsoft、およびほとんどの主要プロバイダーが ARC チェーンを検証しています。

ARC のベストプラクティス

まず中核となるプロトコルを設定しましょう。 ARC は SPF、DKIM、DMARC を補完するものであり、それらを置き換えるものではありません。 ARC を気にする前に、まずそれらの認証方式を設定してください。 適切な基本認証がなければ、ARC が保持すべき有用な情報はありません。

認証結果を監視しましょう。 多くのメールサービスプロバイダーは、メッセージがどの程度認証チェックを通過しているかを示すレポートを提供しています。 ARC を導入していても転送メールの失敗率が高い場合は、何かが誤って設定されています。 ヘッダーを確認してください。

DKIM キーを安全に保ちましょう。 ARC は DKIM 署名の上に成り立っているため、DKIM キーが侵害されると ARC チェーンも信頼できなくなります。 キーは定期的にローテーションしてください（6〜12か月ごとが一般的です）。

転送シナリオをテストしましょう。 メーリングリスト、転送サービス、さまざまなメールクライアントを経由してテストメールを送信し、ARC が正しく機能していることを確認してください。 MXToolbox のようなツールは、設定の検証やヘッダーの確認に役立ちます。

信頼する sealer を文書化しましょう。 ARC 検証を設定する場合は、どの中継サービスを信頼するのかの一覧を維持してください。 この一覧は四半期ごとに見直しましょう。 サービスは所有者が変わったり、侵害されたり、終了したりすることがあります。 すでに使用していないサービスからの ARC 署名は信頼しないでください。

まだ全員が対応しているわけではないことを受け入れましょう。 一部の小規模なメールプロバイダーは、まだ ARC 検証を実装していません。 そうした相手では、転送メールが引き続きフラグ付けされる可能性があります。 とはいえ、大手各社はすべて対応しており、受信者の大半はこれでカバーできます。

関連用語

• DKIM
• SPF（Sender Policy Framework）
• DMARC レコード
• メール認証