送信ドメイン認証技術 DMARC とDMARC レポートの活用

北川 直哉（国立大学法人 東京農工大学）
平野 善隆（株式会社 クオリティア）

本セッションの概要• 講演者紹介• 北川 直哉：国立大学法人東京農工大学 大学院工学研究院・助教• 平野 善隆：株式会社クオリティア クラウドサービス開発本部・チーフエンジニア• DMARC（およびSPF・DKIM）の概要解説（北川）• DMARCの導入にあたっての技術的Tips（平野）• DMARCレポートの概要解説とレポート分析（北川）• パークドメインで受信したDMARCレポートについて（平野）• 実際にレポートを受け取ってみましょう（北川）DMARCとは• Domain-based Message Authentication, Reporting,and Conformance• ＜DMARCの2つの機能＞① SPF/DKIM検証のエラー状況(ruf)・統計情報(rua)のレポーティング機能Ø 自ドメインにおけるSPF/DKIM検証の効果
Ø 自ドメインをなりすましたメールの状況② SPF/DKIM検証失敗メールの取扱いを送信側が指定する機能
Ø none（処理方法を指定しない）
Ø quarantine（隔離する）
Ø reject（受信拒否する）

受信側はポリシに基づいて取扱い方法を決定SPF(Sender Policy Framework)とは送信側(example.jp)
送信サーバ

192.0.2.1

DNS権威サーバ

受信側(example.com)
MAIL FROM: kitagawa@example.jp

受信サーバ

せ問合 ド )のード Tレコー
コレ
SPF e.jpのTX
plmax(eallドー4
レコ .2.0/2
F
PS
2.09
1
:
ip4+
1
fv=sp!"

DKIM(Domainkeys Identified Mail)とは送信側(example.jp)
送信サーバ

DNS権威サーバ(1)署名に使用する公開鍵を公開受信側(example.com)(2)メールヘッダに電子署名を付加して送信(DK

受信サーバ照)せ参合をの問 d=タグ
鍵開(3)公 ヘッダのuretanig
IM-S
取得(4)公を開鍵()DMARC検証とレポート送信の流れ
送信側

受信側
送信ドメイン
認証

ユーザ

Pass

何もしない
FailDMARC
ポリシ
チェック

隔離拒否

認証結果(rua)レポート
認証失敗(ruf)レポートDMARC のアラインメント• SPF/DKIMでは，送信元ドメイン と 検証用ドメイン は無関係でも良い（第三者署名を許可）• 東京農工大学の例：
・RFC5321.From(Header From)ドメイン ＝ cc.tuat.ac.jp
・DKIM検証ドメイン＝ cctuat.onmicrosoft.com

正しいドメインの組を知る術がないため偽の署名がついたなりすましメールも検証に成功してしまう恐れがある• DMARCでは第三者署名を許可しない = 認証失敗(fail)となる→より強固な送信ドメイン認証といえる

（参考）https://dmarc.org/dmarc-xml/0.1/rua.xsd

DMARCレポート(rua)の構造
XML形式
Report generator metadata

DMARC policy

DKIM and SPF results

All the authentication results

レポートのメタデータ
組織名，メールアドレス，レポートID，期間，など
DMARCポリシ
ドメイン名，ポリシ(p=)，
レート(pct=)，アラインメント，など
評価結果
ドメイン名，IPアドレス，評価内容，理由，各認証結果，など
ドメイン認証結果
認証ドメイン，鍵のセレクタ，認証結果，など
DMARCレポートの統計分析
ある組織に送られてきたDMARCレポートを約14ヶ月分分析してみました（p=none のドメイン）2018年10月末時点で約1,800万レポート/day2018年10月末時点で約2億メール/day
各レポートの<count> </count>から計算

2018年10月末時点で
1,143レポータ/day全JPドメイン数=1,492,109
うちMXレコードを有するドメイン数=1,216,500
うちDMARCレコードを有するドメイン数=9,017→ (9,017/1,216,500) * 100 = 0.74%(参考) 総務省: JPドメイン名における送信ドメイン認証技術の設定状況の調査（ 2018年6月末現在）

日本ただし，日本の組織での観測データのため，実際より日本の順位が高くなっている可能性が高い

日本

DMARCレポートをよく見てみると…
• DMARCの処理に矛盾が生じているレポータの存在• 送信側が宣言している policy と実際の処理の違い(p=quarantine, p=reject を宣言している場合のみ)なども見えてきますDMARC処理に矛盾が生じているレポートの例<?xml version”1.0” encoding=“UTF-8” ?><feedback>(snip)<policy̲evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</spf>(snip)DMARC-SPFの結果

DMARC-DKIMの結果(snip)<auth̲results>
SPF の結果<spf>(snip)<result>fail</result></spf><dkim>(snip)<result>fail</result>(contd)DKIM の結果

DMARC-SPFの処理に矛盾があったレポータ(2018/10/25日分：1,143レポータ中12レポータで矛盾あり)
レポータ A

7,525/10,738 通

レポータ C227/228 通

レポータ E

1/3 通

レポータ B

レポータ D
レポータ F

レポータ G

4/46 通1/452 通
1/1 通
1/5 通

レポータ H

21/142,627 通

レポータ J

6/21 通レポータ I

レポータ K
レポータ L

1/1 通

31/31 通4/4 通DMARC-DKIMの処理に矛盾があったレポータ(2018/10/25日分：1,143レポータ中35レポータで矛盾あり)
レポータ 1

177/301,529 通

レポータ 2

103/109,427 通

レポータ 4

246/373 通

レポータ 6

2/25 通レポータ 3
レポータ 5

3/3 通
2/2 通

レポータ 7

8,478/10,738 通

レポータ 9

7/13,255 通

レポータ11

18,725/192,395,820 通

レポータ 8
レポータ10
レポータ12(contd)

3/4 通

78/380 通
2/5 通DMARCポリシと実際の処理の違い• ここまでとは別の組織(p=reject)に送られてきたレポートで調査(レポータ数13, レポート数8,155, メール総数24,081/day(2018/10/25))• 強いポリシ(p=reject や p=quarantine)を宣言した場合でも，例えば以下の理由で，より弱いポリシに下げられることがあります(この理由もDMARCレポートのdescription欄に書かれています)• ホワイトリストに含まれているから• 転送サーバリストに含まれているから など• 反対に強いポリシに変更される場合はこれまで観測していません• 例: none → quarantine or reject
quarantine → reject公開ポリシvs解釈と実際の処理(2018/10/25)
レポータ名 合計メール数
        



12r̲rr̲q141475

75

415
80990

118

1161

126

1q̲r

q̲qq̲nn̲rn̲qn̲n415
19122,312 8098 5569
11247990

1r̲n

19
93
11

14
1

1230 3611
7974711117

DMARCレポートからわかること・できること【基礎編】• 自ドメイン名を偽称したメールがどこにどれだけ送られているのか• 自ドメインの送信ドメイン認証の効き目や設定の正確性【応用編】• データ解析による False Positive / False Negative の軽減(例えば転送や ML 配送で生じていた False Positive の検出)
• 機械学習や確率論等を用いて上記の解析で得られた情報を高度化(レポート受信のためにも)まずは弱いポリシから始めて徐々に強いポリシに変更していくのがオススメです

DMARC レポートを受け取ってみましょう
1. レポートを受信するメールアドレスを準備する
例：rua@example.jp (rua レポート用アドレス)
ruf@example.jp (ruf レポート用アドレス)
2. DNS に DMARC レコードを追加し，メールアドレスを記述する
例：̲dmarc.example.jp IN TXT “v=DMARC1; p=reject;
rua=mailto:rua@example.jp; ruf=mailto:ruf@example.jp”
3. DMARC レポートを送ってくれる組織(ナリタイ等)にメールを送る
4. ワインを飲みに行く!"(一日ほど待つ)
5. 1.で設定した受信用メールアドレスを確認する



なりすまし対策ポータル「ナリタイ」• 今日お話した DMARC をはじめ，SPF や DKIM の解説も充実(方式の解説から設定方法まで網羅的に解説)• 「DMARC/DKIM/SPF CHECK」で設定確認が可能• さらに今秋，check@naritai.jp に空メールを送ると，rua/ruf レポートを送信する機能が追加されました！

• 詳しくは https://www.naritai.jp/ をご覧ください