メールのARCとは？認証失敗を防ぎ信頼性を高める理由もわかりやすく解説

なりすましメールによる被害は拡大するばかりで、その対策の必要性も増している状況です。

従来の送信ドメイン認証技術（SPF/DKIM/DMARC）は、なりすましメール対策として一定の成果をあげています。けれど以前から指摘されている問題点により、なりすましメール対策として十分とはいえません。

ARCはSPF/DKIM/DMARCの問題点を解消することを期待されている技術です。まだ広く普及はしていませんが、今後さらに注目されるでしょう。この記事ではARCは何かやその仕組み、従来の送信ドメイン技術と何が違うかを解説します。この記事を読めばARCの概要や注目される理由を理解できるでしょう。

ARCとは | 送信先サーバーに届くまで認証情報を維持するためのプロトコル

ARC（Authenticated Received Chain）とは、メールが送信先のサーバーへ届くまで認証情報を維持し、正しく評価できるようにするためのプロトコルです。ARCを使うことで送信先が送信ドメイン認証を適切におこなえるようになります。

ARCは2019年7月に、RFC8617にて「Experimental（実験的）」なステータスとして定義され仕様が公開されました。実験的とされますが、GmailやMicrosoft365をはじめ一部ですでに利用が開始されています。

ARCが注目されている理由

ARCの登場以前にも、SPF/DKIM/DMARCといった送信ドメイン認証の技術が使われてきました。そうしたなかで、それらより新しい技術であるARCはなぜ注目されているのでしょうか。

従来の認証技術ではメール転送などで認証が失敗することがあった

SPF/DKIM/DMARCといった認証技術は、なりすましメールの対策として有効ですが大きな弱点があります。

これら従来の認証技術は、メールが送信元サーバーから直接送信先のサーバーへ配信されるのであれば問題ありません。送信元IPアドレスやメールヘッダといった認証に必要な情報から、正しく認証をおこなえるためです。

しかしメール転送やメーリングリストによって、ほかのメールサーバーを経由するとそれら情報が書き換えられます。その結果、認証が失敗してしまうことがあるわけです。

ARCであればメール転送などが発生しても認証の失敗を防げる

ARCでは送信ドメイン認証の失敗を防ぐために、専用のヘッダ情報をメールに記録します。送信元だけでなく送信先サーバーもARCに対応していれば、その専用ヘッダから正確に認証をおこなえるのです。

メールの転送やメーリングリストによって、送信先へメールが配送されるケースも少なくありません。ARCを使えばこういったケースでも、送信ドメイン認証の失敗を防げるので注目を集めているわけです。

ARCでメールの認証失敗を防げると何がよい？ARC導入の主なメリット

ARCを導入することによって、SPF/DKIM/DMARCによる認証の失敗を防ぐことができます。それでは認証の失敗を予防することでどのようなメリットがあるのでしょうか。

なりすましメールと誤解されにくくなり相手にメールが届きやすくなる

ARCを導入することで、メールが送信ドメイン認証の失敗によってなりすましメールなどと誤解され迷惑メールと判定されるのを防げます。その結果、迷惑メールフィルタの誤検知を予防し相手にメールが届きやすくなるのです。

メールのセキュリティが強化される

ARCにはメール転送やメーリングリストのサーバーを経由した際に、メールが改ざんを検出する機能があります。そのためARCを利用することでメールセキュリティを強化できるわけです。

またARCによってドメイン認証の精度をあげられるため、結果的にスパムメール・フィッシングメールも適切に排除しやすくなります。そういった意味でも、メールセキュリティ向上に役立つといえるのです。

ARCによるメール認証の流れ

ARCを用いた送信ドメイン認証の流れをみていきましょう。
ここでは送信されたメールがメーリングリストサーバーに届き、最終的に送信先メールサーバーへ到達するものとします。

ARCは送信ドメイン認証において、以下の様な役割を果たします。

ARCによるメール認証の仕組み | 従来の技術と何が違う？

ARCによる認証は、従来のSPF/DKIM/DMARCによる認証と仕組みが異なっています。以下、従来の技術と何が違うかとあわせてARCによるメール認証の仕組みをみていきましょう。

従来の技術（SPF/DKIM/DMARC）が指摘されている問題点

従来の送信ドメイン認証技術（SPF/DKIM/DMARC）では、どのような問題点が指摘されているのでしょうか。以下、ひとつずつみていきましょう。

【SPFの問題点】

SPFを利用する場合、あらかじめDNSサーバーにSPFレコードとして、正しい送信元メールサーバーのIPアドレスを登録しておきます。そうして送信先サーバーはメールを受け取った際に、SPFレコードが宣言したとおりのIPアドレスから送られたか確認するのです。

本来であれば送信されたメールは、当然正しい送信元メールサーバーから送られているので、SPFの認証は成功します。しかしメーリングリストサーバーを経由すると、送信元のIPアドレスがメーリングリストサーバーのものとなるのです。この場合SPFレコードによって宣言されたIPアドレスとは異なるため、SPFの認証に失敗してしまいます。

【DKIMの問題点】

DKIMによる認証では、おおまかにいうと以下2つのハッシュ値が一致するかを確認します。

本来なら、正しい送信元メールサーバーからメールが送られていれば、上記2つが一致して認証に成功する筈です。しかしメーリングリストサーバーを経由すると、ハッシュ値の作成に使われるメールヘッダー・本文が書き換えられてしまうことがあります。

その結果、送信先メールサーバーで作成されるハッシュ値と、送信元メールサーバーが作成したハッシュ値が一致しなくなるのです。この場合は、DKIMの認証に失敗する可能性が生じます。

【DMARCの問題点】

DMARCは、SPF・DKIMの認証結果を活用し、送信元メールアドレスのドメイン名がなりすまされていないか確認する送信ドメイン認証技術です。メール転送などでSPF・DKIMの認証に失敗すると、DMARCも正確に判定できなくなる場合があります。

ARCはメールに「ARCヘッダ」を追加して従来の問題点を克服

ARCではメールに「ARCヘッダ」を追加することで、メールが転送されても認証結果が保持されるようにします。

具体的にはメールサーバーがメールを中継する際に、その時点での送信ドメイン認証結果などを含むARCヘッダを追加するのです。メーリングリストサーバーなどをメールが経由する前なので、この時点で送信ドメイン認証が失敗してしまう可能性は低くなります。

送信先メールサーバーはSPF/DKIM/DMARCによる認証が失敗しても、ARCヘッダの認証結果を参照し信頼性を評価することができるようになるのです。

ARCヘッダの種類と見方

ARCヘッダは以下にあげる3つの種類で構成されます。

■AAR(ARC-Authentication-Results)
＜サンプル＞

ARC-Authentication-Results: i=1; mx.example.com;
          dkim=pass header.d=example.com;
          spf=pass smtp.mailfrom=sender@example.com;
          dmarc=pass (p=none sp=none dis=none) header.from=example.com

各中継サーバーがSPF/DKIM/DMARCなどの認証結果を記録するヘッダです。送信先サーバーはARCヘッダを辿ることで、メールの認証結果を追跡しメールの信頼性を評価できます。

i＝1	ARC署名をおこなったのが何番目かを示します。 メール転送が続く場合は、この数字が増えていくわけです。
mx.example.com	記載された認証結果を生成・記録したメールサーバーのホスト名です。
dkim=pass/ spf=pass dmarc=pass	DKIM/SPF/DMARCの認証結果です。

■AMS（ARC-Message-Signature）
＜サンプル＞

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
          d=example.com; s=arcselector; t=1695987600;
          h=from:to:subject:date:message-id;
          bh=xyz456...; b=def789...

メール本文やヘッダが改ざんされていないことを保証する電子署名です。このヘッダにより、メールの内容が送信時のまま変わっていないことを確認できます。

i＝1	ARC署名が何番目かを示します。
a=rsa-sha256	使用されている電子署名のアルゴリズムです。
c=relaxed/relaxed	正規化の方法です。
d=example.com	署名をおこなったドメインです。
s=arcselector	使用されているDKIMセレクター（DKIM署名に必要な追加情報）です。
t=1695987600;	署名作成時のタイムスタンプです。
bh=xyz4…	電子署名の本体です。

■AS（ARC-Seal）
＜サンプル＞

ARC-Seal: i=1; a=rsa-sha256; d=example.com; s=arcselector;
          t=1695987600; cv=pass; b=abc123...

ARCヘッダが改ざんされていないことを保証する電子署名です。ASヘッダはメールサーバーを通過する際の認証情報を封印し、その信頼性を担保します。

i＝1	ARC署名が何番目かを示します。
a=rsa-sha256	使用されている電子署名のアルゴリズムです。
d=example.com	署名をおこなったドメインです。
s=arcselector	使用されているDKIMセレクター（DKIM署名に必要な追加情報）です。
cv=pass	ARC認証の結果です。
b=abc123…	電子署名の本体です。

メーラーでARCヘッダを確認する方法

メーラーでARCヘッダを確認するには、対象となるメールを開いたうえでそのメールのヘッダー情報（ソース）を表示させます。具体的な方法については、メーラーによって異なるので付属のマニュアルなどを確認ください。

一例としてGmailであれば、対象のメールを開いたうえで右上の三点リーダーから「原文を表示」をクリックしますと、以下の様にARCヘッダの確認ができます。

メールのARCについてよくある質問

ここではメールのARCを利用するにあたって、よくある質問をみていきましょう。

ARCの導入にあたってDNSレコードの登録は必要ですか？

ARC自体の導入にあたっては、DNSレコードの登録は必要ありません。ARCを導入する場合は、メールサーバー側で対応をおこないます。

なおARCはSPF/DKIM/DMARCの認証結果を利用しますが、SPF/DKIM/DMARCの運用にはDNSレコードが必要です。

arc-authentication-resultsと従来のヘッダとの違いは何ですか？

・arc-authentication-resultsヘッダサンプル

ARC-Authentication-Results: i=1; example.com;
    dkim=pass header.d=example.net;
    spf=pass smtp.mailfrom=sender@example.net;
    dmarc=pass (p=none) header.from=example.net

・従来のauthentication-resultsヘッダサンプル

Authentication-Results: example.com;
    dkim=pass header.d=example.net;
    spf=pass smtp.mailfrom=sender@example.net;
    dmarc=pass (p=none) header.from=example.net

従来のauthentication-resultsヘッダは、最終的に対象のメールを受信するメールサーバー（送信先サーバー）による認証結果が記録されています。一方でarc-authentication-resultsヘッダに記録されているのは、対象メールを中継するメールサーバーによる認証結果です。

また従来のauthentication-resultsヘッダは、そのメールサーバーが直接認証した結果が記載されます。一方でarc-authentication-resultsに記録されるのは、メールが中継される過程で通過した全メールサーバーの認証結果です。

まとめ

従来の送信ドメイン認証技術（SPF/DKIM/DMARC）は、メーリングリストサーバーを経由するなどで失敗することがあるのが弱点でした。ARCは送信先サーバーに届くまでにおこなわれた認証情報を、ARCヘッダに記録することでその弱点をカバーします。メールサーバーがARCに対応していれば、ARCヘッダによる認証を優先させるのです。

従来の送信ドメイン認証に比べ、ARCはまだ普及しているとはいえません。しかし送信ドメイン認証を強化し、なりすましメールを対策するのに有効な技術なので、対応するメールサーバーが増えていくでしょう。