技術解説 · 出典付きの回答
ARC(Authenticated Received Chain)とは?仕組みを解説
ARC(Authenticated Received Chain)は、中継するメールサーバーがSPF、DKIM、DMARCのチェック結果に署名できるようにする送信ドメイン認証の標準規格です。これにより、メールが転送された場合でも、転送処理によって元のSPFやDKIMの署名が壊れていたとしても、最終的な受信サーバーは元の認証ステータスを信頼できます。
ARCの具体的な仕組み
ARCは、メールが中継サーバーを通過する際に3つの特定のヘッダーを追加することで動作します。ARC-Seal(認証)はARC-Message-Sealに対するデジタル署名を提供し、ARC-Message-SealにはARC-Authentication-Resultsが含まれます。このチェーンにより、各ホップでの認証ステータスを検証可能な形で記録できます。メッセージが転送された場合、次のサーバーはARCチェーンを検証することで、転送者がエンベロープやヘッダーを変更する前の時点でメッセージが正当だったことを確認できます。
メール送信者にとっての重要性
ARCは、ユーザーやメーリングリストによってメールが頻繁に転送される送信者にとって非常に重要です。ARCがない場合、転送者が送信元アドレスを変更したりメッセージ本文を書き換えたりすることが多く、その結果SPFやDKIMが失敗します。送信者が厳格なDMARCのrejectポリシーを設定していると、こうした正当な転送メールがブロックされてしまいます。ARCは、信頼できる中継サーバーがすでにメッセージを検証済みであれば、最終的な受信者がDMARCの失敗を無視できる仕組みを提供します。
運用上の注意点とよくある間違い
よくある間違いは、ARCがDKIMやSPFの代わりになると考えることです。ARCはこれらのプロトコルに依存する補助的なレイヤーです。中継サーバーがARCに対応しており、かつ最終的な受信サーバーがARCのシーラーを信頼している場合にのみ機能します。転送のシナリオでARCに頼る前に、SendHQの無料ツール(https://sendhq.cc/tools)を使って、主要なDKIMレコードとSPFレコードが正しく設定されていることを確認してください。
具体的な実装例
ユーザーが仕事用のメールを個人のGmailアカウントに転送するケースを考えてみましょう。職場のサーバーはメールにDKIMで署名します。転送サーバーはそのメールを受け取り、DKIMを検証してARCシールを追加します。Gmailがメールを受信すると、転送サーバーは認可された送信者ではないため、元のSPFは失敗します。しかしGmailは信頼できる転送者のARCシールを確認し、ARCヘッダーに保存された元のDKIMの結果を検証して、メールを拒否せずに配信します。
ARCとDMARCの関係
ARCはDMARCのセーフティネットとして機能します。DMARCがメッセージの現在の状態を評価するのに対し、ARCは認証の履歴を記録します。現在のDMARCチェックが失敗しても、信頼できる送信元からの有効なARCチェーンが存在すれば、受信側のメール転送エージェント(MTA)はDMARCポリシーを上書きしてメッセージを受け入れることができ、迷惑メールフィルターの誤検知を減らせます。
よく寄せられる質問
ARCはDMARCの代わりになりますか?
いいえ、ARCはDMARCの代わりにはなりません。ARCは認証結果を保持する手段を提供し、メッセージが転送された後でもDMARCをより正確に評価できるようにするものです。
ARCを実装する必要があるのは誰ですか?
ARCを実装するのは主にメールの仲介者で、メーリングリストの管理システム、転送サービス、企業向けメールゲートウェイなどが該当します。
ARCですべての迷惑メールを止められますか?
いいえ、ARCは正当な転送メールが迷惑メールと判定されるのを防ぐためのもので、迷惑メールそのものを止めるためのものではありません。ARCはシーラーと受信者の間の信頼関係に依存します。
ARCはすべてのメールプロバイダーで対応していますか?
GmailやMicrosoft 365など主要なプロバイダーの多くはARCに対応していますが、小規模なメールサーバーやレガシーシステムでは対応状況がまちまちです。
一次情報源
- RFC 8617:認証済み受信チェーン(ARC) — RFC Editor
- RFC 7489:ドメインベースのメッセージ認証・レポート・適合(DMARC) — RFC Editor
- RFC 6376:DomainKeys Identified Mail(DKIM)の仕様 — RFC Editor