メールセキュリティ
送信ドメイン認証 その3
認証方式の詳細 その1
情報セキュリティG 新井 全勝
本稿は、迷惑メール対策推進協議会発行の「送信ドメイン認証技術導入マニュアル 第3.1版」を参考にして作成したものである。
1．迷惑メール発生の背景と搾称の問題
迷惑メール発生の背景
インターネットメールシステムは仕組みの簡便さもあり、多くのコミュニケーションツールの基盤として広く普及した。その一方でメールを読むべきかを判断する送信者を確認する手段が備わっていなかったことから、重大な問題が引き起こされてきている。例えば、匿名の広告宣伝メールや実在の事業者を騙って偽のWebサイトに誘導し個人情報や金銭に繋がる情報を窃取するフィッシングが大きな社会問題になっている。
こうした迷惑メールは、メールに示される送信者情報が信用できないことから、本当の事業者であるかどうかを判断できないことが、大きな原因となっている。
送信者情報搾称によって発生する問題
メールの送信者情報が搾称されることによって、下記のようなさまざまな問題が発生する。
- 搾称されたメールを受信側で的確に拒絶できない可能性がある。
- 実物とは異なる偽のサイトに誘導し個人情報を搾取するなどの犯罪行為（フィッシング）が行われる。
- 信頼性のある外部の送信者を騙りメールに添付された不正プログラムを実行させ、外部からコントロールされるボット 注１）に変身させたり、PC内部にある個人情報や操作過程で得られる個人情報を窃取するなどの行為が行われる。
- 迷惑メールは宛先が存在するか否かにかかわらず大量に作成される傾向にあるため、そのRreturn-Pathヘッダ 注２）を搾称し実在するメールアドレスとしている場合、エラーメールが大量に送信される、いわゆるバックスキャッタの問題が発生する。
- バックスキャッタの場合、そのエラーメールが迷惑メールとして判断され、迷惑メールの判断機能を提供しているベンダやブロックリストを運営している組織に報告され、迷惑メール送信者として登録される。
- 迷惑メール送信者として登録されると、そのメールアドレスから送信される通常メールは迷惑メールの扱いを受け、正常にもかかわらず届かなくなるという２次的な問題が発生する。
注１） ボット：ロボットの略称。人間による操作や作業を代替したり、人間の行為を模して人間のように振る舞い、自動的・自律的に行動するソフトウエアやシステムなどのこと。（IT用語辞典e-Words）
注２）Return-Pathヘッダ： SMTPプロトコルによる配信時に、配信エラーが発生したときにエラーメッセージを返信するメールアドレス。SMTPでメール送信時、 コマンドで指定されたメールアドレスが Return-Path となる。これは郵便の封筒に擬えて Envelope From とも呼ばれる。
2．送信ドメイン認証技術によるなりすまし対策の概要
送信ドメイン認証技術とは
受信者が受け取ったメールの送信者情報が搾称されているかどうかをドメイン単位に確認（認証）する技術を送信ドメイン認証技術という。
送信ドメイン認証技術を利用すると、メールを受信したときに、それが本当にfromヘッダやReturn-pathヘッダに示されているメールアドレスのドメインから送られてきたかどうかを確認（送信ドメイン名を認証）することが可能になり、なりすましを見破ることができる。
認証方式は3種類
- ネットワーク方式
- メール配信時のSMTPプロトコルで使われる 送信元 MTA（メールサーバ）の IP アドレスを確認する方式である。
- 送信側は「このドメインからメールを送るサーバの IPアドレスはこれです」とDNS（Domain Name Server）に登録して公開する。
- 受信側は実際の送信元 IPアドレスと照合して正当性を判断する。
- 代表例：SPF（Sender Policy Framework）。
- 電子署名方式
- 公開鍵暗号方式によってメールに送信者の電子署名を付け、受信側がそれを検証する方式である。
- 電子署名では、メールヘッダの送信者情報やメール本文をそのまま使うのではなく、ハッシュ関数 注1）を用いて固定長のハッシュ値を作成して使用する。ハッシュ関数はハッシュ値の長さによって、SHA-1 / SHA-256 が利用可能。
- 公開鍵は DNS に登録して公開する。
- 受信側は公開鍵で署名を検証し、改ざんやなりすましをチェックする。
- 代表例：DKIM（DomainKeys Identified Mail）。
- 両者を組み合わせた方式
- 両者を組み合わせ統合化した方式をDMARC（Domain-based Message Authentication, Reporting, and Conformance）という。
- SPF と DKIM の結果を統合し、下記の機能をポリシーとして設定できる。
- 認証失敗時の扱い（拒否・隔離など）
- レポート送信
既存のメールシステムに大きな変更を加えず導入できるよう設計されている。
注１） 電子署名には、鍵生成、署名生成、署名検証のアルゴリズムが使われる。詳細は後述。
注２） ハッシュ関数：任意の長さのデータ（キー）を固定長のデータ（ハッシュ値）に変換する関数。この変換は一方向性であり、元のデータを復元することはできない。
受信側では、元のデータをハッシュ関数で変換してハッシュ値を得て、これと送信側から送られてきたハッシュ値を照合して内容の検証を行う。
ハッシュ値の長さ（ビット数）によって攻撃されたときのリスクが異なる。長い方がリスクは低い。現在、SHA-1 / SHA-256 が利用可能。
3. SPF認証の仕組み
SPFはネットワーク方式の送信ドメイン認証技術である。メールの送信側と受信側のメールサーバを組み合わせて認証する。両側のメールサーバに、SPF認証機能を付加する。
送信側
- あらかじめ送信側メールサーバのドメインのDNSに、そのドメインの送信者が外部に向けてメールを送信する可能性のあるメールサーバのIPアドレス一覧表を登録し公開する。これをSPFレコードの公開という（図3‐1の（1））。
- SPFレコードは文法に基づいて記述する。
- 送信側メールサーバについては、次のことを考慮して複数のIPアドレスをSPFレコードに記載する必要がある。
- 共用サーバで使用されるIPアドレスは複数個存在し、それらのIPアドレスの中から選択して動的に割り当てられる。そのため、IPアドレスのすべてを記載することが必要である。
- Gmailなどの外部メールサーバを利用する場合、送信側メールサーバとは異なるサーバが利用されるので、そのことを考慮してIPアドレスを記載する。
- SPFレコードの登録は送信側メールサーバのメール管理者の役割である。
- 送信者user1がメールを投稿すると、送信側メールサーバのIPアドレスが、メール配信プロトコルSMTPの送信者情報（Mail from）注１）としてメール本体 注２）と共に受信側に送信される。
受信側
- メールの送信時にリバースパスとして指定されたIPアドレスのドメイン部分に示されるドメインのDNSサーバに問い合わせ、SPFレコードを取得する（図3‐1の（２））。
- 取得したSPFレレードの内容は「v=spf1 ip4:192.0.2.1 ～all」。SPFレコードのバージョン＝「1」、送信元メールサーバのIPアドレス（バージョンは4）＝「192.0.2.1」、「～all」はそれ以外のIPアドレスは「softfail」とすることを示している。このSPFレコードのドメインは「example.jp」。
- そのSPFレコードに示されているIPアドレスと、SMTPで接続した先のメールサーバ（Mail from）が一致するかを確認することで認証を実施する（図3‐1の（3））。
注１） 送信者情報（Mail from）：電子メールを郵便に擬えたとき、SMTPプロトコルで送られる送信者情報や宛先情報は封筒に書かれる情報に見立てて、エンベロープfromと呼ばれる。また、受信側でエラーが検出された場合、送信側にエラーメールを返信する。その際の宛先メールアドレスとしても使用されることから、リターンパス（Return-path）とも呼ばれる。また、リバースパス（Reverse Path）とも呼ばれる。
注２） メール本体：メールヘッダとメール本文を併せたもの。
6．参考文献
- 送信ドメイン認証技術導入マニュアル 第3.1版 2023年2月発行 迷惑メール対策推進協議会
- IT用語辞典e-Words Webコンテンツ 2026年2月アクセス
次回は、送信ドメイン認証DKIMやDMARCの仕組みについて紹介する。
以上