メール転送のARC認証結果を監視する方法｜チェーン検証・DMARC失敗・中継経路を切り分ける
メールをメーリングリスト、セキュリティゲートウェイ、転送サービスへ通すと、送信元IPが変わってSPFが失敗したり、件名・本文・MIME構造の変更でDKIM署名が壊れたりします。その結果、元の送信者が正しく認証されていたメールでも、最終受信側ではDMARCが失敗することがあります。
Authenticated Received Chain（ARC）は、中継者が受信時に確認した認証結果と、その後のメッセージ状態を署名付きの連鎖として次の受信者へ渡す仕組みです。ただし、ARCが付いていることやarc=passだけでメールを許可してよいわけではありません。チェーン構造、署名、記録した中継者、元の認証結果、最終受信側の判定を順に照合する必要があります。
ARCの監視では、まず各instanceにARC-Authentication-Results、ARC-Message-Signature、ARC-Sealが1組ずつあり、i=1から連番になっているかを確認します。次にチェーン検証結果、シーラーのd=、各中継時点のSPF・DKIM・DMARC結果、最終Authentication-Resultsを照合します。 failはチェーンを証拠として使わず原因を調べ、noneはARC未付与・非対応経路と区別します。
本記事のポイント
- ARCはSPF・DKIM・DMARCを再実行する仕組みではなく、中継者が受信時に確認した認証結果とメッセージ状態を署名付きで引き継ぐ仕組みです。
- 監視ではAAR・AMS・ASの3ヘッダーをinstanceごとにそろえ、連番、cv、署名、シーラーの署名ドメインを一つのチェーンとして検証します。
- arc=passは自動許可の根拠にせず、信頼する中継サービス、元認証結果、最終DMARC判定、迷惑メール判定を分けて運用します。
ARCは転送前の認証結果を「証拠の連鎖」として残す
RFC 8617はARCを、メッセージを扱った主体と各段階の認証評価を確認できる「chain of custody」として定義しています。ARCは2019年公開のExperimental RFCであり、SPF・DKIM・DMARCを置き換えるものではありません。転送やメーリングリストで現在の認証が壊れたときに、上流で何が確認されていたかを判断材料として残します。
ARCを使う中継者は、同じi=を持つ3つのヘッダーをARC Setとして追加します。instanceは1から始まり、中継者がセットを追加するたびに1ずつ増えます。RFC上は1から50までで、各instanceには3種類がちょうど1つずつ必要です。
| ヘッダー | 記録する内容 | 監視で見る項目 | 役割 |
|---|---|---|---|
ARC-Authentication-Results（AAR） | その中継者が到着時に確認した認証結果 | i=、認証サーバー名、SPF・DKIM・DMARC | 受信時点の評価を残す |
ARC-Message-Signature（AMS） | 中継者が扱った後のメッセージ状態への署名 | i=、d=、s=、署名検証 | 内容と主要ヘッダーの完全性を示す |
ARC-Seal（AS） | 同じinstanceのAAR・AMSと、それ以前のARC Setへの封印 | i=、d=、s=、cv=、署名検証 | セットの順序とチェーンを結ぶ |
AARは通常のAuthentication-Resultsに近い構文で、中継者が受信した時点の認証結果をまとめます。AMSはDKIM署名に似ていますが、ARC固有のinstanceを使い、その中継者による変更後のメッセージを次の処理者が検証できるようにします。ASは本文ではなく、ARC Setのヘッダー群を順序付きで署名し、チェーン全体の連続性を確認できるようにします。
転送でSPFが失敗する理由や本文変更でDKIMが壊れる理由は、DMARC集計レポートの読み方と共通します。ARCの役割は失敗を消すことではなく、「上流では何がpassしており、どの中継で状態が変わったか」を署名付きで残すことです。
チェーンは連番・3点セット・署名・信頼の順で読む
ヘッダーを上から眺めてarc=passを探すだけでは、どの中継者の結果を信頼したのか分かりません。最終受信側のAuthentication-Resultsと、各ARC Setを分け、次の順で確認します。
- 最終受信側の認証結果を固定する。最終
Authentication-ResultsからSPF、DKIM、DMARC、ARCの結果を採取します。どの受信サーバーが付与した行かも記録し、転送前のAARと混ぜません。 - ARC Setをinstance単位に並べる。
i=1から最大値までを昇順にし、各instanceにAAR、AMS、ASが1つずつあるかを確認します。欠番、重複、3種類の不足があれば構造上のfail候補です。 cvの意味を位置と一緒に読む。i=1のASは以前のチェーンがないためcv=noneが正常です。i>1では、それ以前のチェーンを検証できた場合にcv=passとなります。途中にcv=failがあれば、後段の結果だけで正常化しません。- 最新AMSと全ASの署名を検証する。公開鍵DNS、selector、署名対象、本文ハッシュ、時刻、鍵ローテーションを確認します。DNS応答不能もARCチェーンの検証ではfailとして扱われます。
- シーラーの
d=を契約・経路へ照合する。自社ドメインを想像で登録せず、実メールのASとAMSにある署名ドメインが、実際に利用しているゲートウェイや転送サービスのものかを確認します。 - AARの元認証結果と現在結果を比較する。上流AARでDKIMまたは整合したSPFがpassし、最終側で中継によるIP変更・本文変更の後にfailしたのかを確認します。最初から認証がfailしているメールをARCで正当化しません。
- 最終処置を認証と迷惑メール判定に分ける。ARCがDMARC失敗の評価に使われても、コンテンツ判定、苦情率、送信者評価、ポリシールールは別に残ります。
Microsoft 365で信頼済みARCシーラーを使う場合、Microsoft Learnは最終AARのarc=passとoda=1、最終Authentication-Resultsのcompauth=pass reason=130を確認例として示しています。これはMicrosoft 365固有の表示です。RFC共通のcv、AAR・AMS・AS、d=の確認と混同せず、製品固有フィールドは受信基盤別の監視条件として管理します。
シーラーの信頼設定は最小限にします。Microsoft Learnも、実際に利用し信頼するサービスだけを登録し、ASのd=と一致するベンダー署名ドメインを指定するよう案内しています。不要なシーラーを増やすと、そのサービスが侵害された場合に偽装メールを正当化する経路を広げます。
fail・none・DMARC失敗を原因別に切り分ける
ARCの状態は、メールを配送するかどうかの最終判定ではありません。RFC 8617では、チェーン検証がfailしたARCは、ARCチェーンがないメールと同じように扱う必要があるとしています。一方で、ARCがない・壊れていることだけを理由に即時拒否するのではなく、通常のSPF・DKIM・DMARC、送信者評価、コンテンツ判定を継続します。
| 観測結果 | 主な意味 | 確認する証拠 | 初動 |
|---|---|---|---|
arc=none | 受信側が検証するARCチェーンを確認できない | ARCヘッダー有無、中継サービスのARC対応、経路変更 | 元送信側のSPF・DKIM・DMARCを通常どおり評価する |
i=1; cv=none | 最初のARC Setであり、検証対象となる以前のチェーンがない | AAR・AMS・ASの3点、最新AMS・ASの署名 | 正常な初回セットとして次の検証へ進む |
arc=failまたはcv=fail | 欠番・重複・署名不一致・DNS・後続変更などでチェーン検証に失敗 | 壊れたinstance、selectorのDNS、署名後の変更時点 | ARCを判定材料から外し、元認証と経路を調査する |
| ARC pass、DMARC fail | 正規中継で元認証が保持された可能性がある | 信頼済みd=、上流AAR、最終From、現在のSPF・DKIM | 信頼ポリシーに沿ってDMARC override可否を判断する |
| ARC passでも迷惑メール扱い | 認証以外のコンテンツ・評判・苦情・受信ポリシーが作用 | スパム判定ヘッダー、苦情率、送信者評価、ルール | ARC設定ではなく配信品質と受信ポリシーを調べる |
arc=failの代表原因は、途中のinstance欠落、同じinstanceの重複、3ヘッダーの不足、ASまたはAMSの署名不一致、公開鍵DNSの欠落、鍵ローテーション直後のキャッシュ、ARC sealing後のメッセージ変更です。どのinstanceで壊れたかを特定し、Receivedヘッダーの経路と突き合わせます。
arc=noneは、直接配送、ARC非対応の中継、ARC無効化、経路からのヘッダー削除で起こります。ARCが必要な正規経路なのに突然noneへ変わった場合は、ゲートウェイ設定、経路変更、製品更新を確認します。GoogleのGmail向け転送ベストプラクティスでも、転送はSPFに影響しやすく、DKIMを壊す本文・ヘッダー変更を避けることが案内されています。ARC以前に、元送信者のSPF・DKIMを整え、不要な変更を減らすことが前提です。
SPFの転送影響を調べる場合はSPFのDNS評価とPermError監視、署名鍵やselectorを確認する場合はDKIM鍵ローテーションを参照します。ARCの問題と元認証の問題を別チケットにすると、転送サービスへ問い合わせる範囲を絞れます。
ARC監視をテストメール・台帳・アラートへ落とし込む
ARCは設定画面だけでは監視できません。実際の配送経路を通ったメッセージ原文を保存し、期待するARC Setと最終認証結果を機械的に比較します。メーリングリスト、受信ゲートウェイ、チケットシステム、転送サービスなど、メッセージを変更する経路ごとにテストケースを作ります。
| 監視対象 | 正常条件 | アラート条件 | 記録するキー |
|---|---|---|---|
| ARC Set構造 | i=1..Nが連続し各3ヘッダー | 欠番、重複、AAR・AMS・AS不足、50超 | Message-ID、最大instance、受信時刻 |
| チェーン検証 | 必要経路でpass、初回ASはcv=none | fail増加、passからnoneへの変化 | 受信基盤、arc結果、壊れたinstance |
| シーラー | 承認済みのd=・s= | 未知の署名ドメイン、selector変更、鍵DNS欠落 | ベンダー、契約、所有者、変更日 |
| 元認証 | 上流AARの認証結果が想定と一致 | 正規送信なのに元からSPF・DKIM・DMARC fail | header.from、smtp.mailfrom、header.d |
| 最終処置 | 認証とスパム判定の理由を説明可能 | ARC override急増、正規経路の隔離、未知経路の許可 | disposition、CompAuth等の製品固有結果 |
導入は、まず正規経路のサンプルを採取し、通常時のヘッダーを固定するところから始めます。各サービスのシーラーd=、selector、期待instance数、上流AARの認証結果、最終受信側のARC・DMARC結果、迷惑メール処置を台帳化します。その後、テスト送信を定期実行し、前回値との差分を監視します。
アラートは「ARC failが1件あった」だけでなく、正規経路に対するfail率、none率、未知のシーラー、instance欠落、公開鍵DNSエラー、ARC override件数、ARC pass後の隔離件数を分けます。送信量が少ない経路は件数、定常経路は割合と連続時間の両方でしきい値を決めます。
メーリングリストでは、系列識別にList-IDヘッダーを併用すると、どの配信系列がどの中継経路を通ったかを照合しやすくなります。ただしList-IDも真正性を証明しないため、ARCのシーラー、DKIM、DMARC、送信ログと組み合わせます。
変更管理では、中継サービスの追加・削除、シーラー署名ドメインの変更、ARC selectorの鍵更新、メッセージ変換ルール、信頼済みシーラー一覧を同じ変更票で扱います。変更前後に同じテストメールを通し、上流AAR、instance、cv、最終DMARC処置の差分を保存します。ロールバック条件は、正規メールのfail率、未知シーラーの出現、隔離増加など、受信者影響で決めます。
ARC監視が完了するのは、arc=passを見つけた時ではなく、どの中継者がどの認証結果を記録し、現在のDMARC失敗を信頼してよい理由を説明できた時です。
よくある質問
ARCはメール転送時のどの認証結果を引き継ぎますか？
各ARC対応中継者が受信時に評価したSPF、DKIM、DMARCなどをAARへ記録し、AMSとASでそのメッセージ状態とARC Setを署名します。最終受信側は、現在の認証が転送で失敗しても、上流の評価を検証可能な判断材料として参照できます。
ARC-SealとARC-Authentication-Resultsをどう確認しますか？
同じi=のAAR、AMS、ASを1組にし、instanceが1から連続しているかを確認します。ASではd=、s=、cv=と署名検証を、AARでは中継時点のSPF・DKIM・DMARC結果を読みます。
ARCチェーンがfailまたはnoneのとき何を切り分けますか？
failでは欠番、重複、3ヘッダー不足、AS・AMS署名、公開鍵DNS、署名後変更をinstance順に調べます。noneではARCヘッダーの有無、中継サービスのARC対応、機能設定、経路変更を確認し、ARCを使わず元のSPF・DKIM・DMARCで評価します。
ARC結果をDMARC判定や配信許可へどう使いますか？
信頼する中継者のチェーンがpassし、上流AARに整合した認証成功があり、現在の失敗が正規中継によるものと説明できる場合に限り、受信基盤のローカルポリシーで参照します。ARC passだけで許可リストへ入れず、スパム・評判・苦情の判定を残します。
i=1; cv=noneは障害ですか？
障害ではありません。最初のARC Setには検証する以前のチェーンがないため、RFC 8617ではi=1のASをcv=noneとします。最終受信側のarc=noneとは意味が異なります。
ARCがpassしても迷惑メールに入ることはありますか？
あります。ARCは主に認証結果を引き継ぐ仕組みで、コンテンツ判定、送信者評価、苦情率、受信側ルールを無効にしません。到達全体はメール到達率の原因切り分けと、受信基盤のスパム判定ヘッダーを合わせて確認します。
参照した公式仕様・資料
ARCを有効にするだけでは、転送メールの正当性を説明できる状態にはなりません。正規の中継経路を決め、3つのARCヘッダーをinstance単位で検証し、信頼するシーラーと元認証結果を台帳へ結び付けることで、転送によるDMARC失敗と偽装・設定不備を分けて判断できます。
