“送信ドメイン認証”の普及が不正メールを減らす--DMARC.orgが意義を説明

日川佳三 2015年11月19日 07時30分

  • このエントリーをはてなブックマークに追加

 フィッシングメールなどの成りすましメールの被害を防ぐ仕組みとして、受け取ったメールが正規の送信者から送られているかどうかを調べる“送信ドメイン認証”と呼ぶ技術がある。DKIM(Domainkeys Identified Mail)とSPF(Sender Policy Framework)の2つが送信ドメイン認証技術の代表だ。

 DKIMとSPFの送信ドメイン認証技術の認証結果をもとに自動でアクセスを制御したりレポーティングしたりできるようにする仕組みがDMARC(Domain-based Message Authentication, Reporting & Conformance)だ。認証に失敗したメールを機械的に処理できるようになるほか、認証結果をメール送信者に伝えて情報を共有できるようになる。

Steven Jones氏
DMARC.org エグゼクティブディレクター Steven Jones氏

 11月18日、DMARCの普及を推進する組織「DMARC.org」でエグゼクティブディレクターを務めるSteven M Jones氏が会見し、DMARCの意義を説明した。Jones氏は「迷惑メールとフィッシングメールは永遠の脅威」とメール送信者を認証することの必要性を説いた。この上で「送信者と受信者が協力しあえば、メール利用者を保護できる」とDMARCの意義を説明した。

メール送信側の対応は容易--受信側はメールを自動で処理可能に

 DMARCに対応する労力と、その見返りは以下の通りだ。

 まず、メール送信者がDMARCに対応するのは簡単だ。DKIMかSPFのいずれか、または両方に対応した上でDMARCの情報をDNSサーバに登録するだけでよい。DNSには、認証に失敗した場合のメールの処理方法、レポートの送信先アドレスなどを記述する。一方で、メール受信者がDMARCに対応するためには、メール受信サーバがDMARCに対応している必要がある。

DMARCに対応するために必要な準備
DMARCに対応するために必要な準備

 DMARCの前提の1つとなるDKIMは、電子署名で認証する。具体的には、受信メールのヘッダに含まれる電子署名をDNSから得た公開鍵で復号して検証する。仕組み上、メール送信者と受信者ともにメールサーバがDKIMに対応している必要がある。

 もう1つの前提となるSPFは、IPアドレスで認証する。具体的には、DNSから得たIPアドレスと、送信サーバのIPアドレスが一致するかどうかを調べる。仕組み上、メール受信者側はメールサーバがSPFに対応する必要があるが、メール送信者はDNSへの登録だけでよい。

 メール受信者がDMARCに対応するメリットの1つは、送信者がDNSで公開しているアクセス制御ポリシーに応じて、認証に失敗したメールを機械的に処理できること。DMARCの情報がDNSに登録されている(DKIMかSPFで認証できることを表明している)にもかかわらずDKIMやSPFで認証できなかった場合に、自動的に受信を拒否したり、迷惑メールとして隔離したりできるようになる。

 DMARCは、DKIMとSPFの認証に加えて、DMARC独自の検証機能も持つ。DKIMが認証に使うドメイン名(メールのDKIMヘッダに書かれたドメイン名)やSPFが認証に使うドメイン名(SMTPセッションのMAIL FROMコマンドの引数)を、DMARCがDNSを参照する際に使うドメイン名(メールのFROMヘッダに書かれたドメイン名)と照らし合わせ、これらが一致するかどうかを確認する。部分一致や完全一致を確認し、DMARCの最終的な認証結果とする。

 メール送信側がDMARCに対応するメリットの1つは、DMARCのアクセス制御ポリシーを送信者側で設定できること。認証できなかったメールの処理において、はじめのうちは何も制御しないモードで運用を続け、しばらく様子を見てから受信を拒否させるモードに切り替える、といったことがDNSの記述だけで制御できる。

 もう1つのメリットは、DMARCに対応した受信者から、認証結果に関するレポートをもらえること。これをDMARCのアクセス制御ポリシーなどにフィードバックできる。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

この記事を読んだ方に

関連ホワイトペーパー

連載

CIO
IT部門の苦悩
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
「企業セキュリティの歩き方」
「サイバーセキュリティ未来考」
「ネットワークセキュリティの要諦」
「セキュリティの論点」
スペシャル
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell EMC World
AWS re:Invent
AWS Summit
PTC LiveWorx
より賢く活用するためのOSS最新動向
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
米株式動向
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]