要約

  • RFC 9990 は、メール受信側が一定期間の認証結果、DMARC整合、評価した disposition、例外理由、送信元と件数を集計して伝える形式を定める。
  • 集計行は一通ごとの履歴ではない。一つの期間に旧方針と新方針が混在し、部分重複を切り分けられない場合があり、報告データが偽造され得ることも明記されている。
  • Daniel Kade は、本文や個人アドレスを残さず、生成者、期間、方針エポック、ファイルダイジェスト、重複判断、利用決定だけを結ぶ「集計利用受領証」を提案する。

受信した報告の総和は、世界全体の分母ではない

ドメイン所有者にとって集計報告は、外部からしか見えない現実を知らせる。想定外の IP から自ドメインを名乗るメールが出ていないか、DKIM の鍵更新が失敗していないか、SPF と From の整合がどこで崩れているかを把握できる。

ただし、画面に現れるのは報告を生成し、届けた受信者の観測である。すべての受信者が参加する保証はない。配信先が受け取れなければ、データを後で再送することも破棄することもあり得る。欠けた報告はゼロ件を意味しない。

集計はプライバシーと規模のために必要な圧縮である。その圧縮を、完全な国勢調査へ読み替えないことが制度側の仕事になる。

RFC が規定する観測の器

RFC 9990 は 2026 年 5 月に IETF Standards Track として公開され、RFC 7489 の集計報告部分を新しい DMARC 文書群とともに置き換えた。所有者が方針レコードに rua を示し、受信側がメッセージを評価して XML を作り、許可された宛先へ送る。

報告には組織名、Report-ID、UTC の期間、観測した方針設定が入る。行には送信元 IP、件数、評価した disposition、整合結果、From などの識別子がまとまる。DKIM と SPF の結果は区別される。要求方針と異なる扱いなら、ローカル方針、メーリングリスト、テスト、信頼済み転送元などの理由を示せる。

件数は、別のフィルターが最終的に遮断したメールも含め、受信したメッセージを基礎にする。従って disposition は配達、受信箱配置、閲覧を証明しない。DMARC 評価は受信システム全体の一工程である。

一行にまとめると、一通ごとの接続は消える

大量のメールを同じタプルにまとめるから、所有者は傾向を発見できる。代わりに、各メッセージの安定したイベント ID、順序、後段フィルター、最終結果は残らない。これは仕様の失敗ではなく、集計という設計の意味である。

危険なのは、その一行から自動的に高い権限の操作へ飛ぶときだ。失敗件数の増加は未許可送信者かもしれないし、新しい報告者、遅延ファイル、グルーピング変更、重複期間かもしれない。調査開始には十分でも、原因確定とは限らない。

証拠の主体は「この受信側が、この期間をこう要約した」である。「実際のメール流は完全にこうだった」と言い換えれば、報告者に仕様外の権威を与える。

最終方針が、期間全体の方針とは限らない

報告期間中に DNS の DMARC 方針が変わると、受信側が変化を見る時刻は揃わない。RFC 9990 は方針ごとに別報告を出す方法と、旧方針と新方針による処理を一つの報告に混ぜる方法の両方を許す。後者でも policy_published は一つしかない。

各受信側に常時の方針遷移追跡を要求すれば、Internet 規模で重い負担になる。そこで消費者と所有者が混在を想定する。この現実的な選択は、表示された方針を全行の時刻証明に使えないことも意味する。

正午に監視から拒否へ変えた日の集計を、最終設定だけで過去へ投影してはならない。追加情報がなければ「混在」または「不明」として扱う方が正確だ。

報告メールの正当性と、観測内容の真実性

報告を運ぶメール流は整合した DMARC pass を得なければならない。安全な輸送も推奨される。外部ドメインの処理先は DNS で受領の意思を示し、確認できなければ送信対象から外される。

これらは偽装と第三者への大量送付を抑える重要な境界である。ただし、送信ドメインの整合、外部処理先の同意、ファイルの完全性、個々の観測の正確さは別々の事実だ。

RFC 9990 は、集計データが偽造され、大量投入によって方針やプラットフォーム設計を動かそうとする可能性を記す。だからといって既知の受信者を信用できないのではない。信用の根拠と限界を記録し、一つの入力だけで不可逆な判断をしないということである。

Report-ID は重複処理の入口にすぎない

同一ドメイン向けの Report-ID は一意でなければならず、再送では元のファイル名を再利用する。完全な再送を認識する助けになる。しかし異なる ID の報告同士でもデータは重なり得る。

仕様は、重複を拒否、破棄、調査、受理する選択を消費者に残す。期間が一部だけ重なると、その影響を明確に分離できず、ファイル全体を採るか捨てるかの判断になることもある。

したがって、ID の一意性を母集団の排他性に置き換えてはいけない。ダッシュボードがどの重複方針で数字を作ったかは、業務上の証拠である。

外部処理先の同意は、分析手法への保証ではない

専門サービスへ報告を届ける仕組みは不可欠だ。外部宛先の DNS 記録は、そのサービスが当該ドメインの報告を受け取る意思を証明し、削除すれば将来の受領を止められる。ただしキャッシュの間は遅延がある。

この同意は、サービスの正規化、帰属、保存、ダッシュボード、推奨判断を認証しない。所有者は、どのファイルが採用され、どの行が落ち、重複がどう処理され、誰が方針変更を承認したかを別に把握する必要がある。

受領業務は委託できる。証拠の意味を理解する責任は委託契約だけでは移らない。

監査を強くしても、個人メールを再収集しない

集計報告は本文や個人を特定するメールアドレスを含めない。それでも通信量のパターンは機微情報になり、仲介者や Public Suffix への報告で漏えいの懸念が生じる。

欠けたイベント接続を埋めるために、全メールを保存するのは誤った修復だ。必要なのは報告ファイルから判断までの来歴であり、通信内容ではない。

また GZIP と XML は不信入力として隔離して処理すべきだ。展開や解析の資源枯渇があり得る。構文上読めることと、証拠として採用できることを別の状態にする。

集計を使った瞬間の受領証

Daniel Kade の提案は、集計が具体的な決定を支える時点で、小さな「集計利用受領証」を作ることだ。RFC 9990 を変更する提案ではない。

まず Report-ID、元のファイル名、ダイジェスト、サイズ、受領時刻、輸送認証結果、生成者の識別根拠を結ぶ。次に方針ドメイン、UTC の開始と終了、スキーマ版、完全・遅延・部分的という期間状態を記す。

方針文脈では policy_published とともに、単一、混在、不明のエポック状態を残す。重複欄では関連ファイルと交差期間を結び、置換、統合、拒否、受理、隔離の判断と担当者を示す。

変換欄はパーサー版、正規化後の行集合ダイジェスト、拒否行数、無視した拡張、異常検査を記録する。最後に、調査、送信者連絡、鍵更新、方針変更、保留、ロールバックなど実際の利用結果と訂正先を保存する。

メール本文を残さなくても、数字がなぜ権限を得たのかは残せる。

証拠の限界

確認した資料は、報告形式、方針混在、重複の曖昧さ、外部宛先確認、プライバシー、偽造警告を裏づける。RFC 9990 の普及率、特定実装の品質、実際の偽造事件や重複頻度は示さない。

本稿は集計報告を単なる意見とは扱わない。運用観測者から届く構造化証拠である。ただし高い影響の判断には、誰の観測か、どの期間か、どの方針か、重複をどう扱ったか、誰が行動を認めたかという接続が必要だ。

出典