方法論

何を測っているか

DNS に公開されているレコードだけを見ています。SPF / DKIM / DMARC と、 MTA-STS / TLS-RPT / BIMI / DNSSEC / DANE です。メールの内容も配送も 見ていません。標準への準拠状況の計測であり、各社のセキュリティを 総合評価するものではありません。

8つの工程

工程 内容
P1 母集団確定 金融庁 EDINET のコードリストから上場企業を確定する
P2 ドメイン候補生成 公式サイト、CT ログ、SPF redirect、DMARC rua から候補を広げる
P3 メールドメイン確定 候補を絞り、確度（confirmed / likely / unknown / parked）を付ける
P4 DNS計測 レコードを取得し、応答をそのまま保存する
P5 パース 保存した応答を仕様に照らして解釈する
P6 推察 辞書と照合してメール基盤や製品を推定する
P7 集計 公開用の統計を作り、前月との差分を計算する
P8 公開 このサイトを生成する

各工程は独立して実行でき、何件処理して何件失敗したかを必ず記録しています。

「取れなかった」と「無かった」を分けている

DNS の応答が SERVFAIL や タイムアウトだった場合、それは「レコードが無い」 ことの証明にはなりません。この2つを別の事実として扱っています。

計測対象から外した分がある

計測対象から外すと決めたドメインには、以降 DNS の問い合わせを行いません。「除外した」は「観測できなかった」 でも「レコードが無かった」でもなく、「測らないと決めた」という第三の状態です。

除外した件数は各月の実行記録に残しています。黙って分母から外すと、率が 理由の説明できない形で動き、読み手には計測失敗と区別が付かないためです。

事実と推察を分けている

DNS から直接読み取れる値と、辞書との照合による推定は別のものとして扱い、 このサイトでも視覚的に分けています。推定には必ず確度と根拠が付きます。

検出できないもの

API 連携型のメールセキュリティ製品

MX を変更せず API や OAuth で連携する製品は、原理的に DNS に痕跡を残しません。 検出されなかったことは、使っていないことを意味しません。

DKIM のセレクタ

DKIM のセレクタは DNS 上で列挙できません。既知のセレクタ辞書で照会しており、 辞書に無いセレクタを使っている場合は検出できません。「既知セレクタでは 検出できなかった」と「設定していない」は別の状態として記録しています。

MTA-STS のモード

enforce か testing かは DNS からは分かりません。ポリシーファイルを HTTPS で取得する必要があり、現時点では取得していません。

転送経路

DMARC の効果は転送やメーリングリストの経路に左右されますが、DNS の観測からは 分かりません。

DMARC の実効強度を二通りに計算している

RFC 7489 は pct を尊重し、RFC 9989（DMARCbis）は pct を扱わず t=y で テスト扱いに落とします。どちらの解釈でも同じ結果になるとは限らないため、 両方を計算して保存しています。

Organizational Domain の解決も二通り

Public Suffix List による解決と、RFC 9989 の Tree Walk による解決の両方を 計算しています。.co.jp 系や多階層のサブドメインで差が出ることがあります。

出典

再現できるようにしている

取得した DNS の応答は加工せずに保存しており、解釈にバグが見つかった場合は 保存した応答から作り直します。集計に使った辞書の版も出力に記録しています。 計測のコードと設定は、計測結果と同じ版で保管しています。