ARCとは？SPF・DKIM・DMARCの課題を補う仕組みと従来技術との違いをわかりやすく解説

ARCを理解する前提として、まず従来の送信ドメイン認証技術の役割を整理しておきましょう。

技術	概要	主な確認内容
SPF	送信元ドメインが、メール送信を許可するサーバーのIPアドレスをDNSに公開する仕組み	メールを送ってきたサーバーのIPアドレスが、許可リストに含まれているか
DKIM	送信側がメールに電子署名を付与し、受信側が公開鍵で検証する仕組み	署名したドメインの正当性と、メールのヘッダー・本文が改ざんされていないか
DMARC	SPF・DKIMの結果と、差出人（ヘッダーFrom）のドメインが一致するかを評価する仕組み	認証に失敗したメールをどう扱うか(none/quarantine/reject)のポリシー適用とレポート

これらを組み合わせることで、第三者が自社ドメインを詐称して送るなりすましメールを受信側で見分けやすくなり、なりすましメール対策として一定の成果をあげています。

SPF・DKIM・DMARCは、基本的に「送信者のサーバーから受信者のサーバーへ、メールが直接届く」ことを前提に設計されています。

そのため、メーリングリストや自動転送などでメールが別のサーバーを経由すると、正規のメールであっても認証に失敗することがあります。

SPFの問題：送信元IPアドレスが変わる

メールが転送されると、受信側から見た送信元は「転送したサーバー」になります。
転送サーバーのIPアドレスは元の送信ドメインのSPFレコードに登録されていないため、SPFの認証は失敗します。

エンベロープFromを書き換えるSRS(Sender Rewriting Scheme)という対処方法もありますが、既存のメールサーバーへの大きな変更が必要なことなどから、広く普及しているとはいえません。

DKIMの問題：件名や本文の書き換えで署名が無効になる

メーリングリストでは、件名に「[ML名]」などの文字列を付けたり、本文末尾に配信停止の案内を追加したりすることがあります。

DKIMの署名はヘッダーや本文の内容をもとに作られているため、こうした書き換えが行われると署名の検証に失敗します。
なお、件名や本文を変更せずにそのまま転送する場合、DKIM署名は維持されます。

DMARCの問題：SPF・DKIMの失敗が連鎖する

DMARCはSPF・DKIMの結果を利用するため、転送によって両方が失敗すると、DMARCも失敗と判定されます。

送信ドメインのDMARCポリシーが「quarantine（隔離）」や「reject（拒否）」に設定されていると、正規のメールが迷惑メールフォルダーに振り分けられたり、受信拒否されたりする可能性があります。

このように、なりすまし対策を強化しようとDMARCポリシーを厳しくするほど、転送されたメールが届かなくなるリスクも高まります。
この点が、従来の送信ドメイン認証技術だけではなりすましメール対策として十分とはいえない理由の一つです。

ARC(Authenticated Received Chain)とは、メールが中継サーバーを経由する際に、その時点での認証結果を記録し、最終的な受信サーバーまで引き継ぐための仕組みです。

転送や書き換えによって最終的な受信サーバーでのSPF・DKIM・DMARCが失敗しても、受信サーバーはARCに記録された「転送前の認証結果」を参照し、そのメールの信頼性を判断できるようになります。

いわば、中継サーバーが「受け取った時点では認証に成功していました」という証明書を、改ざんできない形で添えて送り出すイメージです。

ARCの仕様は2019年7月にRFC 8617として公開されました。
ただし、ステータスは標準化の途上にあることを示す「Experimental（実験的）」です。

一方で、GmailやMicrosoft 365などの主要なメールサービスでは既にARCが利用されています。
また、Googleのメール送信者ガイドラインでは、メールを定期的に転送する場合にARCヘッダーを追加することが推奨されています。

ここでは、ARCで追加されるヘッダーの役割と、認証結果を引き継ぐ流れを解説します。

ARCで追加される3つのヘッダー

ARCに対応した中継サーバーは、メールを転送する際に次の3種類のヘッダーを追加します。
この3つを1組として「ARCセット」と呼びます。

ヘッダー	役割	ポイント
ARC-Authentication-Results(AAR)	中継サーバーがメールを受け取った時点のSPF・DKIM・DMARCの認証結果を記録する	「転送前は認証に成功していたか」を後から確認するための記録
ARC-Message-Signature(AMS)	メールのヘッダーや本文に対する電子署名	DKIMに似た署名で、その中継サーバー以降に内容が改ざんされていないかを確認できる
ARC-Seal(AS)	AARやAMSを含むARCヘッダー全体に対する電子署名	認証の記録そのものが改ざんされていないことを保証する

「i=」と「cv=」で認証の鎖をつなぐ

各ARCセットには、何番目の中継かを示すインスタンス番号「i=」が付きます。
最初の中継サーバーが付けるセットは「i=1」、次の中継では「i=2」というように、転送を重ねるごとに番号が増えていきます。

また、ARC-Sealには、それまでのARCの連鎖（チェーン）を検証した結果が「cv=」として記録されます。

• cv=none
  前のARCセットが存在しない（最初の中継、i=1のとき）

• cv=pass
  それまでのARCチェーンの検証に成功した

• cv=fail
  検証に失敗した（その時点でARCチェーンは無効となる）

ARCを使った認証の流れ

メーリングリストを経由してメールが届く場合を例に、ARCの流れを見てみましょう。

ARCとSPF・DKIM・DMARCの違いを、表で比較します。

観点	SPF	DKIM	DMARC	ARC
主な目的	送信サーバーの正当性確認	署名による送信ドメインの確認と改ざん検知	差出人ドメインの一致確認とポリシー適用	中継時点の認証結果の保持・引き継ぎ
対応する主体	送信ドメインの管理者	送信ドメインの管理者	送信ドメインの管理者	主に中継サーバー（メーリングリスト・転送サーバーなど）
検証のタイミング	受信時の1回	受信時の1回	受信時の1回	中継のたびに記録し、最終受信時にチェーン全体を検証
転送への耐性	低い	内容の書き換えに弱い	SPF・DKIMに依存	高い（転送を前提に設計）
位置づけ	基本的な認証技術	基本的な認証技術	SPF・DKIMを統合する仕組み	従来技術を補完する仕組み

最大の違いは、従来の技術が「送信者側」の設定をもとに受信時点で一度だけ検証するのに対し、ARCは「中継する側」が経路上で認証結果を記録し、それを鎖のように積み重ねていく点です。

ARCはSPF・DKIM・DMARCの結果を利用して動作するため、従来技術を置き換えるものではなく、あくまで転送時の弱点を補う補完技術として理解しておくことが大切です。

ARCは有効な技術ですが、導入・運用にあたっては次の点に注意が必要です。

• 仕様が実験的な段階にある
  RFC 8617は正式な標準化トラックではないため、受信サービスごとにARCの扱いが細部で異なる可能性があります。

• ARCを信頼するかは受信側の判断
  ARCヘッダーがあれば必ず受信されるわけではなく、どの中継サーバーのARCを信頼するかは受信側のポリシーに依存します。
  悪意ある中継サーバーが偽の認証結果を記録する可能性もあるため、受信側は信頼できる中継者のARCのみを考慮する必要があります。

• 経路上のサーバーが対応している必要がある
  中継サーバーがARCに対応していない場合、ARCセットが追加されず、転送先で認証失敗をカバーできません。

• SPF・DKIM・DMARCの設定が前提
  ARCは中継時点の認証結果を引き継ぐ仕組みのため、送信ドメイン側で従来の認証が正しく設定されていなければ、引き継ぐべき「成功した結果」がありません。

ARCの署名を行うのは主にメールを中継・転送するサーバーであり、メールを送るだけの送信者側で特別な設定が必要になることは通常ありません。
一方、次のような環境を運用している場合は、ARCへの対応を検討するとよいでしょう

• 件名や本文の書き換えを行うメーリングリストサーバーを自社で運用している
• 件名への注意喚起の付与やフッターの追加など、メールを加工するメールゲートウェイを利用している
• 社内のメールサーバーから、外部のメールサービスへ自動転送している
• 自社ドメインのDMARCポリシーをquarantineやrejectに設定しており、転送先での認証失敗が報告されている

ARC署名を行う中継サーバー側では、DKIMと同様に署名用の鍵を用意し、公開鍵をDNSに公開する必要があります。

対応状況はメールサーバーのソフトウェアや利用しているサービスによって異なるため、まずは自社のメール経路でどのような中継・加工が行われているかを把握することから始めましょう。

なお、GmailやMicrosoft 365を利用している場合は、サービス側でARCヘッダーが自動的に付与されます。

SPF・DKIM・DMARCは、なりすましメール対策として欠かせない技術です。しかし、メーリングリストや自動転送などでメールが中継されると、正規のメールでも認証に失敗してしまうという弱点がありました。

ARCは、中継時点の認証結果を署名付きで記録し、最終的な受信サーバーまで引き継ぐことで、この弱点を補う技術です。まだ実験的な仕様であり、受信側の評価方法にも差がありますが、主要なメールサービスでは既に利用が進んでいます。

まずは自社ドメインでSPF・DKIM・DMARCを正しく運用したうえで、メールの転送や加工を行う環境ではARCへの対応状況を確認し、なりすまし対策とメールの確実な到達の両立を図りましょう。

メール設定支援サービスについてはこちらお問い合わせはこちら