目
第１章
1.1
1.2
1.3

第２章

次

はじめに

1

メールの普及と送信者情報偽装の問題 ･････････････････････････････････････････････ 2
送信ドメイン認証技術による対応 ･････････････････････････････････････････････････ 2
本マニュアルの目的 ･････････････････････････････････････････････････････････････ 2

メールの仕組みと課題

5

2.1
2.2
2.3
2.4

メールシステムの概要 ･･･････････････････････････････････････････････････････････ 6
メール配送の手順 ･･･････････････････････････････････････････････････････････････ 8
メール本体の構造 ･･･････････････････････････････････････････････････････････････ 9
メールの送信者情報 ･････････････････････････････････････････････････････････････ 9
2.4.1 概要 ････････････････････････････････････････････････････････････････ 9
2.4.2 メール配送時に指定される送信者情報 ･･････････････････････････････････ 9
2.4.3 ヘッダ領域に記述される送信者情報 ･･･････････････････････････････････ 10
2.5 送信者情報詐称の問題 ･･････････････････････････････････････････････････････････ 11
2.5.1 送信者情報詐称を判断する仕組み ･････････････････････････････････････ 11
2.5.2 送信者情報詐称の問題点 ･････････････････････････････････････････････ 12
2.5.3 送信ドメイン認証技術 ･･･････････････････････････････････････････････ 13

第３章
3.1
3.2

送信ドメイン認証技術

送信ドメイン認証技術による対応 ････････････････････････････････････････････････ 16
Sender Policy Framework (SPF)････････････････････････････････････････････････ 17
3.2.1 概要 ･･･････････････････････････････････････････････････････････････ 17
3.2.2 SPF の仕組み ････････････････････････････････････････････････････････ 17
3.2.3 送信側の設定 ･･･････････････････････････････････････････････････････ 17
3.2.4 SPF レコードの記述法 ････････････････････････････････････････････････ 18
3.3
Sender ID ････････････････････････････････････････････････････････････････････ 22
3.3.1 概要 ･･･････････････････････････････････････････････････････････････ 22
3.3.2 Puported Resposible Adress(PRA) ････････････････････････････････････ 22
3.3.3 SPF レコードのバージョン ････････････････････････････････････････････ 23
3.4
Domainkeys Identified Mail (DKIM)････････････････････････････････････････････ 25
3.4.1 概要 ･･･････････････････････････････････････････････････････････････ 25
3.4.2 公開鍵の提供 ･･･････････････････････････････････････････････････････ 26
3.4.3 送信側での電子署名の作成 ･･･････････････････････････････････････････ 27
3.4.4 受信側での処理 ･････････････････････････････････････････････････････ 29
3.4.5 認証結果の扱い ･････････････････････････････････････････････････････ 29
3.4.6 DomainKeys Identified Mail (DKIM)
Author Domain Signing Practices (ADSP) ･･････････････････････････ 29
3.5 認証結果のヘッダへの表示 ･･････････････････････････････････････････････････････ 32
3.5.1 Authentication-Results ･････････････････････････････････････････････ 32
3.5.2 ヘッダの詐称 ･･･････････････････････････････････････････････････････ 32
3.5.3 認証方法ごとの結果表示 ･････････････････････････････････････････････ 32

15

第４章

送信ドメイン認証技術導入手順

37

4.1

事前準備 ･･････････････････････････････････････････････････････････････････････ 38
4.1.1 導入する送信ドメイン認証技術の決定 ･････････････････････････････････ 39
4.1.2 ドメイン名の把握 ･･･････････････････････････････････････････････････ 40
4.1.3 メールの利用方法の確認 ･････････････････････････････････････････････ 42
4.1.4 導入計画の作成 ･････････････････････････････････････････････････････ 45
4.2 一般的な導入手順 ･･････････････････････････････････････････････････････････････ 48
4.2.1 SPF/Sender ID ･･････････････････････････････････････････････････････ 48
4.2.2 DKIM ･･･････････････････････････････････････････････････････････････ 51
4.3 運用 ･･････････････････････････････････････････････････････････････････････････ 54
4.3.1 メールサーバの運用 ･･････････････････････････････････････････････････ 54
4.3.2 DNS の運用 ･･････････････････････････････････････････････････････････ 54

第５章

ISP での対応

57

5.1
5.2

ISP のメールサービスの概要 ････････････････････････････････････････････････････ 58
送信側の対応 ･･････････････････････････････････････････････････････････････････ 59
5.2.1 概要 ･･･････････････････････････････････････････････････････････････ 59
5.2.2 送信ドメイン認証技術の導入 ･････････････････････････････････････････ 59
5.2.3 迷惑メールの管理 ･･･････････････････････････････････････････････････ 62
5.3 メール受信側としての検討 ･･････････････････････････････････････････････････････ 65
5.3.1 概要 ･･･････････････････････････････････････････････････････････････ 65
5.3.2 利用する送信ドメイン認証技術の選定 ･････････････････････････････････ 65
5.3.3 メールの配送制御 ･･･････････････････････････････････････････････････ 65
5.4 ユーザ周知 ････････････････････････････････････････････････････････････････････ 67
5.4.1 送信側の対応 ･･･････････････････････････････････････････････････････ 67
5.4.2 受信側の対応 ･･･････････････････････････････････････････････････････ 67

第６章

ホスティングサービスでの対応

69

6.1

ホスティングサービスの分類 ････････････････････････････････････････････････････ 70
6.1.1 メールサーバによる分類 ･････････････････････････････････････････････ 70
6.1.2 DNS サーバによる分類 ････････････････････････････････････････････････ 73
6.2 送信側の対応 ･･････････････････････････････････････････････････････････････････ 74
6.2.1 SPF / Sender ID の対応 ･････････････････････････････････････････････ 74
6.2.2 DKIM の対応 ････････････････････････････････････････････････････････ 76
6.3 受信側の対応 ･･････････････････････････････････････････････････････････････････ 79
6.3.1 認証結果の解説と利用方法の提示 ･････････････････････････････････････ 79
6.3.2 認証結果によるフィルタリング実施 ･･･････････････････････････････････ 79

第７章
7.1

配信サービスでの対応

配信サービスとは ･･････････････････････････････････････････････････････････････ 82
7.1.1 配信サービスと送信ドメイン認証技術 ･････････････････････････････････ 82
7.1.2 From ヘッダアドレスの管理主体 ･･･････････････････････････････････････ 83
7.2 送信ドメイン認証技術の導入 ････････････････････････････････････････････････････ 84
7.2.1 SPF ････････････････････････････････････････････････････････････････ 84
7.2.2 SenderID ･･･････････････････････････････････････････････････････････ 84
7.2.3 DKIM ･･･････････････････････････････････････････････････････････････ 86
7.3 配信サービスによる利用者への周知 ･･････････････････････････････････････････････ 88

81

第８章
8.1
8.2
8.3
8.4

利用者への周知
送信ドメイン認証技術とは ･･････････････････････････････････････････････････････ 90
送信時の注意事項 ･･････････････････････････････････････････････････････････････ 91
受信時の注意事項 ･･････････････････････････････････････････････････････････････ 92
メール転送時の注意事項 ････････････････････････････････････････････････････････ 93

Appendix 1.
Appendix 2.
Appendix 3.
Appendix 4.

SPF レコードの記述例 ･･････････････････････････････････････････････････ 95
DKIM レコードの記述例 ････････････････････････････････････････････････ 103
関連 RFC ･････････････････････････････････････････････････････････････ 109
用語集 ･･･････････････････････････････････････････････････････････････ 111

89

第１章

はじめに

第１章

1.1

はじめに

メールの普及と送信者情報偽装の問題

送信ドメイン認証技術には、その手法の違い
により、複数の方式が併存しています。さら現在のメールシステムは、その仕組みの簡に、メールの利用環境や利用局面の多様化に便さによって、多くのコミュニケーションツ

より、技術的な課題以外にも、送信ドメインールの基盤として広く普及しました。その仕認証技術を導入する際に考慮すべき事項があ組みの簡便さの一方で、送り手が誰であるかります。例えば、仕事に関連したメールを個を確認する手段が備わっていなかったことに人が契約した ISP（Internet Service Provider）

より、現在では、多くの問題が引き起こされの回線を利用して自宅から送信する場合に注ています。例えば、第三者のメールアドレス

意すべき点や、自社に関連したキャンペーン

を悪用した匿名の広告宣伝メールの送信行為

情報を顧客に大量送信するために外部の事業や、実在するメールアドレスを騙って偽のウ者に委託する場合に検討しておくべき点があェブサイトへ誘導して個人情報などを搾取すります。また、メールシステム自体について、

るフィッシングなどの犯罪行為などが頻繁にISP など外部事業者のサービスを利用してい行われるようになっています。また、メール

る場合や、専用システムであるものの運用をシステムでは、受け取ったメールが宛先不明

外部委託している場合など、利用環境の違いなど何らかの原因で配送できない場合には、によって導入の方法が大きく異なる場合があ

送信元に対してエラーメールなどの通知文をります。

送信する必要がありますが、これにより送信者情報を詐称された第三者へ大量の通知文がこのため、送信ドメイン認証技術を利用す届く問題なども発生するようになっています。

る場合には、どの方式を利用すべきなのか、それぞれの方式にはどのような特徴があるの

1.2

送信ドメイン認証技術による対応

か、というような具体的な導入の手順や内容について理解することが必要になります。

送信ドメイン認証技術は、受信者が受け取ったメールについて、送信者情報が詐称され

1.3

本マニュアルの目的ているかどうかをドメイン単位で確認可能とする技術です。この技術により、送信者情報

本マニュアルは、主にメールシステムの管が詐称されることによって発生する問題の多理者やメールの仕様の検討や導入を計画する

くを解決できると期待されています。

立場にある企画担当者などを対象に、既にメールシステムの構造や概要についてある程度

送信ドメイン認証技術を利用するためには、

2

理解していることを前提として、送信ドメイ

メールの送信側と受信側のそれぞれで、新たン認証技術の導入にあたって必要な事項をまな設定や機能の導入が必要となります。また、

とめています。また、それらの事項に加え、

第1章

はじめに

メールサービスを他組織へ提供している事業者にとって有益な情報も別にまとめています。

送信ドメイン認証技術は、あくまでドメイ
ン単位で送信者情報が詐称されているかどう

まず、電子メールの仕組みと課題についてかを確認可能とする技術であって、これ自体解説を行います（第２章）。続いて、送信ドメで送受信されるメールが迷惑メールかどうか

イン認証技術について、導入の前提となる知を判断できる訳ではありません。しかし、こ識を整理する目的で、技術部分の解説を行いの技術の活用によりドメイン名の詐称ができます（第３章）。次に、送信ドメイン認証技術

なくなれば、ドメイン単位で受け取りたいメの導入の手順について解説を行います（第４ール、受け取る必要がないメールを決めてお章）。さらに、他者にメールサービスを提供す

けば、それを確実に判断できるようになりまる事業者での追加的な注意事項について、ISP

す。送信ドメイン認証技術が広く普及するこでの対応（第５章）、ホスティングサービスでとにより、このような判断が可能なドメインの対応（第６章）、配信サービスでの対応（第が増え、それにより、迷惑メール自体も減少

７章）の順に解説を行います。最後に、利用することが期待されます。本マニュアルがこ者への周知一般について、解説を行います（第のような流れに少しでも貢献できれば幸いで

８章）。また、巻末に、参考情報や用語解説をす。

つけています。

3

MEMO

4

第２章

メールの仕組みと課題

第２章

メールの仕組みと課題

本章では、送信したメールが受信者に届くま2.1

メールシステムの概要

での仕組みについて解説します。また、迷惑メールがなぜ受信者に届いてしまったり、受信側

メールの送信者が作成したメールは、インタで迷惑メールを防ぐのが難しかったりする原因ーネット上の幾つかのサーバを経由して受信者となっている、メール配送の課題についても解に届けられます。図表２－１ に、example.com

説します。

ドメインを利用している送信者が、example.jp

なお、ここでは、携帯電話で利用する SMS(Short Message Service) など宛先に電話番号

ドメインを利用している受信者へメールが届けられるまでの流れを示します。

を指定する方法ではない、PC で送受信するドメ
イン名を @ (アットマーク) で区切るメールア
ドレスを宛先に指定するメールを対象とします。

図表２－１

6

インターネットでのメール送信

第２章

メールの仕組みと課題

図表２－１の説明
１

要素

Mail Transfer Agent （MTA : メール転送エージェント）
メールを異なるメールシステム間で転送する役割を持ち、他の MTA や MSA と SMTP プロトコルなどを利用してメールの送受信を行う機能を提供します。
メールの宛先に応じて転送する先を振り分ける機能や、受信側のシステムで受信する準備ができていない場合などに一時的にメールを保存（キュー）する機能などを持ちます。
一般にサーバ・アプリケーション・プログラムとして実装されます（例： sendmail 、 Postfix 等）。
Mail User Agent (MUA : メール・ユーザ・エージェント)
エンドユーザがメールを作成し、送信する（MSA にメールを投稿する）機能や、受信したメールをエンドユーザが読む（メール・スプールから読み出し、表示する）ための機能を提供します。
MUA から MSA へのメールの送信は、一般に SMTP プロトコルを利用して行われます。また、メール・スプールからの読
み出しは、 Post Office Protocol 3 （POP 3） や Internet Message Access Protocol 4 （IMAP 4） プロトコルを利用して行われます。
一般的にエンドユーザの端末上で動作するアプリケーションとして実装され、メールクライアント、メールソフト等と呼ばれる場合が多いです（例：Microsoft 社の Outlook や Mozilla の Thunderbird 等）。
Mail Submission Agent （MSA : メール・サブミッション（投稿）・エージェント）
エンドユーザにより作成されたメールを MUA などから受信し、メールの配送を開始する機能を提供します。
MTA の役割をもつサーバ・アプリケーション・プログラムが MSA を兼ねる場合もあります。 MSA から MTA へ SMTP プ
ロトコルを利用してメールを送信すると、 MTA は、次の配送先（他の MTA や MDA ）へメールを転送します。
Mail Delivery Agent （MDA : メール・配送・エージェント）
メールの受信側（宛先）で、MTA からメールを受信し、メール・スプールへメールを保存する機能を提供します。
MTA の役割をもつサーバ・アプリケーション・プログラムが MDA を兼ねる場合もあります。
Mail Spool （MSPOOL : メール・スプール）
メールの受信側（宛先）で、エンドユーザが MUA を利用してメールを読み取るためにメールを保存する機能を提供します。
Mail Box と呼ぶ場合もあります。
２

処理
①
②
③
④
⑤
⑥
⑦

ドメイン example.com のエンドユーザが、 MUA を利用してメールを作成
エンドユーザは、 MUA を操作し、 MSA にアクセスしてメールを送信（投稿）MSA は、受け取ったメールを MTA へ配送
MTA は、宛先ドメインの MTA を見つけ出して、その MTA へメールを配送受け取った宛先ドメインの MTA は、内部の MDA へメールを配送
MDA は、メール・スプールへメールを届け、メール・スプールでメールを格納
宛先のエンドユーザは、MUA を利用してメール・スプールへアクセスし、自分宛のメールを読み出す③④⑤のメールの配送では、複数の MTA を経由する可能性があります。最近では、アンチウィルスフィルタや迷惑メール
フィルタなどを運用しているドメインも多く、そうしたフィルタを用いたフィルタリングは MTA で実施されている場合が多く、１つのドメインの内部であっても複数の MTA を経由してメールが配送されることが一般的になっています。
また、④で宛先ドメインの MTA を探すときに、送信元の MTA は、宛先ドメインの DNS 上の MX レコードを参照します。 MX レコードとして登録されているホストは、そのドメインにおいて外部ドメインからのメールを受信する役割をもつ
ホストと解釈されます。

7

第２章

メールの仕組みと課題

2.2 メール配送の手順

を相手方に送信し、相手方がそれに対する応答を返信するやりとりを繰り返すことにより手続

メールを宛先に届けるための配送手順として、
SMTP (Simple Mail Transfer Protocol, RFC5321)

受信側へ処理を伝えるので、ほとんどの場合、が使われます。

送信側が受信側に実行したいコマンドを送信す

メール配送では、メールを送りたい側 (送信側)が、メールを届けたい先 (受信側) にネットることになります。
このときの接続の方法やメールの受け渡し、ワーク的に接続を要求し、受信側が要求を受理

受信側からの応答の仕方などを決めたものがすることにより、一連の配送手続が開始されま

SMTP です。SMTP での手続の一般的な流れを図す。そして、実行したいコマンド名とその引数

表２－２に示します。

図表２－２

SMTP によるメール通信手順

送信側では、処理の内容を示すコマンド(MAIL, RCPT, DATA など) を、引数とともに受8が進みます。なお、メール送信は、送信側からに対する応答という形で、受信側の判断や意図を送信側に伝えることができます。

信側に伝えます。例えば、MAIL FROM で送信者のSMTP の規格（RFC5321)では、送信側が指定す情報（メールアドレス）を、RCPT TO で宛先の情る各コマンドの形式や順番、それぞれのコマン

報（メールアドレス）を、DATA でメール本体のドに対して受信側が返すことができる応答番号

情報を伝えます。

の種類などが定められています。

受信側では、それぞれのコマンドを解釈してこうしたメールの配送時に指定される、送信応答をします。コマンドに対する応答の種別は、者や宛先のメールアドレスなどは、郵便の手紙

数字 (220 や 250 などの 3 桁の数字) で示されになぞらえてエンベロープ(封筒)情報とも呼ばます。例えばメールを受け取れない場合には、れます。

否定的な応答番号 (500 番台の数字) を返すこ

なお、SMTP は、メールサーバ間の配送時だけとになります。受信側は、このようなコマンド

でなく、利用者がメールを作成する MUA (メール

第２章

メールの仕組みと課題

ソフト) からメール投稿サーバ (MSA) への送字列で表現され、専用の区切り記号は決められ信時にも使われます。

ていませんが、文字列の構成方法によって区別ができるように決められています。

2.3 メール本体の構造

ヘッダ領域は、メール本体の先頭からヘッ
ダ行が連続する領域で、ヘッダ行ではない空メール本体は、送信側が DATA コマンドを送信し、受信側がその応答として "354" を返した

行 (改行だけの行) がメール本文との区切りとなります。

場合に、送信側から送信されます。メール本体

メール本文は、ヘッダ領域の区切り(空行)の最後に、ドット ('.') 文字だけの行（ドット行）

から、メール本体の末尾までとなります。メが送信されます。なお、この場合のドット行は、ール本体の例を図表２－３ に示します。

メール本体には含まれません。
メール本体は、ヘッダ領域とメール本文によって構成されます。いずれの領域もテキスト文

図表２－３

メール本体

ヘッダ行は、ヘッダ名と続くコロン (':')、

ールの配送時に指定される送信者情報（エンベ

ヘッダ本文で構成されます。ヘッダ行はそれぞ

ロープ情報に含まれる送信者情報）と、メール

れ形式や構文が決まっており、ヘッダを追加す

本体のヘッダ領域に記述される送信者情報の 2

る場合には、正しく構文に従って記述しなけれ

種類があります。これらの送信者情報は、メーばなりません。

ルで利用される情報なので、いずれも、メール

なお、メール本体の構造及びヘッダ行の構文

アドレスで示されます。

については、SMTP の規格（RFC5321）とは別に、Internet Message Format (RFC5322, インター2.4.2

メール配送時に指定される送信者情報

ネットメッセージの形式)で決められています。
メールの配送時に指定される送信者情報は、
2.4 メールの送信者情報

図表２－２ で示した MAIL コマンドの引数として指定されるメールアドレスです。このメー

2.4.1 概要

ルアドレスは、配送上で何か問題が発生した場
合に送信者に通知を送る際に利用されます。そメールの作成者や送信者を示す情報には、メのため、リバースパス (reverse-path) という

9

第２章

メールの仕組みと課題名称が付いています。リバースパスは、SMTP にールを送信してきた送信者であった場合などによるメールの配送時に渡される情報なので、一は、受け取らないことを応答コードで示すこと

般にはメールの受信者には渡されない情報になができます。また、受信側の MTA が、一旦メーります。

ルを受け取った後で、MDA (Mail Delivery Agent)

なお、受信側の MTA は、この MAIL コマンド上でメールスプールに保存ができなかった場合に対する応答として、メールを受け取らないこや宛先が実際には存在しなかった場合など何らとを示すエラーコードを返すことができます。

かの問題があった場合には、このリバースパス

例えば、指定されたメールアドレスが明らかに宛にエラーメールを送信することになります。

実在しないものであった場合や、過去に迷惑メ

図表２－４

エラーメールの送信例

2.4.3 ヘッダ領域に記述される送信者情報

Agent, メールソフトウェア) の多くは、全てのヘッダを表示しません。送信者情報を示すヘッ

ヘッダは、メール本体の一部として受信者にダの仕様としては図表２－５に掲げるものがあ届けられるため、受信者が見ることのできる情りますが、MUA が送信者情報として表示する情報です。しかし、ヘッダにはたくさんの種類が報は、通常は From ヘッダになっています。

あるために、受信者が利用する MUA (Mail User

ヘッダ名

用途

Sender

メール送信を実際に行った送信者を示す情報

From

メールの作成者を示す情報

Reply-to

返事を送信する場合の宛先を示す情報

図表２－５

10

ヘッダ上の送信元アドレス

Sender ヘッダが最も良く使われるケースとするプログラムなどが配送しています。そのたしては、メーリングリストがあります。メーリ

め、Sender ヘッダにはメーリングリストの管理

ングリストでは、リストへの投稿者が From ヘ

者などのメールアドレスが示されることになり

ッダに示されます。しかし、リストメンバへのます。また、今ではあまり行われないかもしれ

送信は、実際にはメーリングリスト機能を実現ませんが、例えば実際のメール内容の作成者に

第２章

メールの仕組みと課題

代わって秘書がメール送信するような場合に、送信者のメールアドレスを Sender ヘッダに示

2.5 送信者情報詐称の問題されることがあります。
From ヘッダの使われ方にも注意すべき点が

2.5.1

送信者情報詐称を判断する仕組みあります。From ヘッダには、メールアドレス以
外にも、補助情報としてディスプレイネーム

メールシステムにおける送信者情報には、2.4(display-name) を追加することができます。デでみたように、用途に応じた複数の種類がありィスプレイネームには、任意の文字列を使用でます。しかし、これまで、いずれの送信者情報

きますので、From ヘッダ上に示されたメールアについても、それが正しく名乗られているかをドレスと全く関係の無い名前や文字列が使えま判断する仕組みがありませんでした。もともとす。MUA や Web ブラウザでメールの送受信を行の電子メールシステムは、インターネットが現ういわゆるウェブメールシステムの多くは、送在のような形で普及する以前から存在してきた信者情報として、このディスプレイネームを優システムであり、メールの利用者が限られてい

先して表示しますので、送信者情報として表示た時代から少しずつ拡張されて使われて続けてされる文字列は、実際の送信者情報とは全く関いるために、現在のように送信者情報が詐称さ係が無いかもしれないものとなっているのです。

れることを予め想定していなかったためです。

図表２－６

なりすましメール送信例

11

第２章

メールの仕組みと課題

そのため、これまで受信側では、経験的な運頼性のある送信者を騙り、メールに添付された用方法として、例えば、送信者情報として、存不正プログラムを実行させ、外部からコントロ

在しないドメイン名が指定された場合や、日本ールされるボットにされたり、PC 内部にある個の有名ドメインを名乗っているものの海外など

人情報や操作過程で得られる個人情報を搾取す

明らかに異なった送信元からのメールだった場

るなどの行為が行われています。

合に受信を拒否するなどの工夫をしてきました。

さらに、迷惑メールは宛先が存在するかどう

しかし、それらの場合であっても、ドメイン

かにかかわらず大量に送信される傾向にあるた名を管理する DNS(Domain Name System) が単にめ、リバースパスを詐称し、実在するメールア

不調であったり、海外からメール転送をしていドレスを指定している場合に、宛先が不明であたりする場合など、ごくまれに送信者情報を故ることによるエラーメールが、詐称されたメー意に偽装したものではない、正しい送信である

ルアドレスに宛てて大量に送信される、バック場合があります。

スキャッタ (backscatter) が大きな問題となってきています。その場合には、そのエラーメ

2.5.2 送信者情報詐称の問題点

ールが迷惑メールと判断され、迷惑メール判定機能を提供しているベンダやブラックリストをメールの送信者情報が詐称されることによって、様々な問題が出てきています。

運営している組織に報告され、正しい処理としてエラーメールを送信している側（最初のメー

まず、受信側で、迷惑メールを受信しないた

ルの受信側）が、迷惑メール送信者として登録

めに、送信者情報をもとに受信を拒絶しようとされ、同じ出口から送信される通常メールまでしても、詐称されていることにより、的確に受もが、迷惑メール扱いされて届かなくなる、と信の拒絶ができないことがあります。

いう 2 次的な問題も発生しています。

また、実在する送信者を詐称し、実物とは異なる偽のウェブサイトに誘導し、個人情報を搾取するなどの犯罪行為 (フィッシング) や、信

図表２－７

12

バックスキャッタ問題

第２章

2.5.3 送信ドメイン認証技術

メールの仕組みと課題問題が生じています。これに対応するために、送信ドメイン認証技術が開発されており、そのこのように、送信者情報が簡単に詐称できてしまい、それを受信側で簡単に判断することが普及により、送信者情報詐称の問題点を防ぐことが可能になります。

できない現在のメールの仕組みにより、大きな

13

第3章

送信ドメイン認証技術

第３章

送信ドメイン認証技術

本章では、送信ドメイン認証技術の基礎にするような手段で、自分のドメインで利用しついて解説します。送信ドメイン認証技術は、ているメールサーバ（MTA）の IP アドレス

受信者が受け取ったメールについて、送信者を公開します。ネットワーク方式の送信ドメ情報が詐称されているかどうかをドメイン単イ ン 認 証 に は 、 Sender Policy Framework

位で確認可能とする技術です。

（SPF）と Sender ID という 2 つのインターネット標準があります。

3.1

送信ドメイン認証技術による対応

電子署名方式の送信ドメイン認証技術は、
公開鍵暗号技術を利用します。この方式では、

送信ドメイン認証技術を利用すると、ある送信側で、公開鍵暗号技術を用いて、公開鍵

メールを受信したときにそのメールが、と秘密鍵を用意し、あらかじめ公開鍵を公開

From ヘッダアドレスやリバースパスに示さしたうえで、秘密鍵を用いて送信するメール

れているドメインから本当に送られてきたかから電子署名を作成し、メールに付与した上どうかを確認することが可能になり、なりすで送信することで、受信側での電子署名の照ましを見破ることができます。

合を可能にします。この方式には、Domain
Keys Identified Mail（DKIM）という標準規格

送信ドメイン認証技術には、ネットワーク
方式と電子署名方式という２つの異なる方式があります。
ネットワーク方式の送信ドメイン認証技術
は、SMTP プロトコルにおいて、その送信元のホスト（MTA）の IP アドレスをもとにして認証します。この方式では、送信側で、後述

16があります。
いずれの方式も既存のメールシステムの仕組みに大きな変更を加えなくても導入できるように考慮されています。

第３章

3.2 Sender Policy Framework (SPF)

送信ドメイン認証技術

カテゴリの RFC（RFC4408） として標準化されています。SPF では、リバースパスを元

3.2.1 概要に認証を行います。

Sender Policy Framework （SPF）は、元

3.2.2 SPF の仕組み

Pobox 社の Meng Wong 氏により提唱されたネットワーク方式の送信ドメイン認証技術です。SPF は、IETF の MARID WG 等におSPF の動作の概要を、図表２−４に示します。

いて数々の議論と検討を経て、現在、実験的

図表３－１

SPF による認証の仕組み

送信側では、あらかじめ、自ドメインののメールサーバ（認証対象のメールサーバ）

DNS サーバ上に、自ドメインの送信者がメーの IP アドレスが、一致するか確認すること

ルを外部に向けて送出する可能性のあるメー

で、認証を実施します（図表３－１の③）。

ルサーバの IP アドレスの一覧を公開します（図表３－１の①）。これを「SPF レコード」

3.2.3 送信側の設定と呼びます。
受信側では、メールの受信時に、送信者とメールの送信側では、DNS 上で SPF レコ

して指定されたリバースパスのドメイン部分

ードを公開するだけで SPF の運用を開始でに示されるドメインの DNS サーバより、きます。RFC4408 では、SPF レコードは、SPF レコードを取得します（図表３－１の

DNS の TXT レコードか SPF RR レコード②）
。そして、その SPF レコードに指定され（以下「SPF 資源レコード」といいます。）ている IP アドレスと、 SMTP で接続した先として公開することが定められています。た

17

第３章

送信ドメイン認証技術

だし、現時点では、SPF という新しい RR レ

SPF レコードには、当該ドメインに属するコード（以下「資源レコード」といいます。
）

メールアドレスを送信者として、そのドメイを取り扱えないリゾルバや DNS サーバの実ン外にメールを送信する可能性のあるメール

装 が 存 在 す る た め 、 SPF 資 源 レ コ ー ド とサーバ（MTA）の、外向けの IP アドレスのTXT レコードの両方を利用して公開します。

リストを記述します。

なお、SPF レコードは、SPF 資源レコードと TXT レコードとの両方を同時に公開可能

SPF では、IPv6 を含む IP アドレスを直ですが、SPF 資源レコードが存在する場合に接記述するほか、簡略に公開可能にする記述

は、受信側で、SPF 資源レコードのみを参照

法が提供されています。SPF レコードの簡単すべきとされています。

な例を、図表３－２に示します。

例１） a. example.com.

IN TXT

例２） b. example.com.

IN TXT "v=spf1 +ip4:192.0.2.1 -all"例３） b. example.com.

IN SPF "v=spf1 +ip4:192.0.2.1 -all""v=spf1 -all"

図表３－２

SPF レコード記述例

１つめの例は、a. example.com をドメイン記述方法の詳細は、3.2.4 で解説します。

名 と し て 持 つ ア ド レ ス （ 例 え ば user@a.
example.com ）からは、一切メールを送信し3.2.4 SPF レコードの記述法

ないことを意味するものです。
２つめの例は、b. example.com をドメイン

SPF レコードは、最初にバージョンを記述

名として持つメールアドレス（例えば、し、空白（半角スペース）を入れて、定義を

user@b.example.com ） か ら の メ ー ル は記述します。定義は、空白（半角スペース）

192.0.2.1 の IP アドレスを持つホストからので区切り、複数記述できます。

み送信されるという意味を持ちます。
３つめの例は、SPF 資源レコードとして公開した場合です。

バージョン 空白

定義

空白 定義

・ ・ （以下繰り返し）

図表３－３

3.2.4.1 バージョン

定義

ードが、SPF のどのバージョンの文法にしたがって記述されているかを示します。

バージョン（Version）は、その SPF レコ

18

RFC4408 で定義されている SPF レコー

第３章

ドの文法はバージョン１のみであり、”v=spf1”と記述することとされています。それ以外の送信ドメイン認証技術

ディレクティブは、限定子（qualifier）と機構（mechanism）で構成します。

記述（例えば、”v=spf1.0” 等）をすると、そ

図表３－２の例 2 では、"-all" と "+ip4:の SPF レコードは不正なものとして、受信192.0.2.1" がディレクティブです。 "-all" の側で、無視されることになります。

うち、"-" が限定子で、"all"が機構です。また、重要な点は、RFC で定められた文法に従わない、誤った SPF レコードを記述すると、受信側ではその SPF レコードを無効として扱うということです（具体的には、3.5.3.2 で"+ip4:192.0.2.1" のうち、"+" が限定子で、"ip4:192.0.2.1" が機構です。
修飾子の例としては、"redirect=a.com" 等があります。

解説する ”permerror” として扱われることになります。
）。したがって、記述は慎重に行い、受信側での認証の処理では、定義は左から

公開に際して SPF レコードの記述について

右へと評価します。認証対象のメールサーバ

試験を行えるサイトなどを利用して試験を行の IP アドレスに対して最初にマッチした定義

うことなどにより、記述ミスがないことを確の限定子によって認証結果が決定されます。

認するべきです。

いずれの定義にもマッチしない場合は、“neutral“ と評価されます（“neutral“ について

3.2.4.2 定義

は、3.5.3.2 で解説します。）。

定義（terms）は、ディレクティブ（directive）と修飾子（modifier）で構成します。

定義 ＝ ディレクティブ（directive）（限定子（qualifier）＋機構（mechanism））＋修飾子（modifier）

図表３－４(a) 限定子

定義

限定子には、”+” 、”-” 、”~” 、”?” があ

限定子（qualifier）には、認証対象のメー

り、”+” 限定子は省略可能です。それぞれ

ルサーバの IP アドレスが、それに続く機構についての認証結果とその意味を、図表３にマッチした場合の認証結果を指定します－５に示します。

（図表３－４を参照）
。
表記
+
-

認証結果
pass
fail

~

softfail?

neutral意味
当該ドメインの送信メールサーバとして認証する
当該ドメインの送信メールサーバとして認証しない
当該ドメインの送信メールサーバとして認証しないが、正当なメールであっても認証失敗する可能性もある認証されたかどうかを判断されたくない

図表３－５

限定子

19

第３章

送信ドメイン認証技術(b) 機構”a”、”mx” などがあります。機構の種類と、機構（mechanism）には、認証対象のメールサーバの IP アドレスと照合する条件

それぞれの引数及び機能を、図表３－６に示します。

を記述します。機構には、”all”、”include”、
機構

引数

all

なし

include

ドメイン名

a

ドメイン名

mx

ドメイン名

ptr

ドメイン名

ip4

IP ネットワークアド
レス（CIDR 表記可能)
又は IP アドレス

ip6

IPv6 ネットワークア
ドレス又は IPv6 アド
レス

existsドメイン名

機能・ すべての IP アドレスにマッチする。
・ SPF レコードの末尾におかれ、デフォルトの動作を定義するために利用される。
・ 引数に与えられたドメインの SPF レコードを使って認証処理を実施する。
・ その結果が pass、temperror 又は permerror の場合にのみ値が採用される。すなわち、include に指定された先のドメインの SPF
レコードによって fail の判定が与えられても、それが認証結果としては採用されない。
・ 認証対象のメールサーバの IP アドレスが、ドメイン名に与えられた FQDN の A レコードのいずれかであれば、マッチする。
・ 認証対象のメールサーバの IP アドレスが、ドメイン名に対応する MX レコードに指定されているホストの A レコードのいずれかであれば、マッチする。
・ MX は複数与えられる場合があるが、10 個までの MX ホストに対して検査する。
・ 認証対象のメールサーバの IP アドレスをリバースルックアップ
し、得られたホスト名でさらに正引きを実施して IP アドレスを得て、その IP アドレス（複数の IP アドレスが得られる場合がある）
が送信元ホストの IP アドレスを含む場合でかつ、リバースルック
アップによって得られたホスト名が ptr の引数に与えられたドメ
イン名と一致するかそのサブドメインである場合に、マッチする。
・ リバースルックアップに失敗した場合は fail とみなす。負荷の多い処理となるため、あまり利用は推奨されない。
・ そのドメインのメールを送信する可能性のあるメールサーバのIP ネットワークアドレス又は IP アドレスを引数に指定する。
・ 認証対象のメールサーバの IP アドレスが、指定された IP ネッ
トワークに含まれているか、IP アドレスに合致する場合に、マッチする。
・ そのドメインのメールを送信する可能性のあるメールサーバのIPv6 ネットワークアドレス又は IPv6 アドレスを引数に指定する。
・ 認証対象のメールサーバの IP アドレスが、IPv6 ネットワークに含まれているか、IPv6 アドレスに合致する場合に、マッチする。
・ 引数であるドメイン名に指定された表記で A レコードのルックアップを実施し、該当の A レコードが存在すればマッチする。
・ SPF のマクロ機能とあわせての利用を想定する。

図表３－６

機構

(c) 修飾子

20

修飾子（modifier）は認証についての付加のように認証結果に影響を与えるものもあ的な情報を与えるものです。機構とは異なります。修飾子について、図表３－７に示り、直接、認証結果を与えませんが、redirect

します。

第３章

修飾子

引数

redirect

ドメイン名

exp

ドメイン名

送信ドメイン認証技術

機能・ 引数であるドメイン名に指定されたドメインの SPF レコー
ドにより認証処理を実行する。
・ 複数のドメインが１つの SPF 定義を共有するような場合での使用を想定する。
・ この修飾子を利用する場合には、SPF レコードの末尾に配置することを推奨する。
・ 認証が失敗した場合に、引数であるドメイン名に指定されたドメインの TXT に設定されている文字列を、認証失敗した理由や説明等として利用する。
・ SMTP セッションでのエラーメッセージなどでの利用を想定
する。

図表３－７

3.2.4.3 SPF レコード公開時の制限

修飾子を軽減する意味もあり、一度の認証処理で参照する DNS の回数の上限を 10 回に制限しRFC4408 では、SPF レコードの文字列はています。

DNS 上の制約から 512 オクテットに収まる
ようにすべきであり、また、UDP を用いた

3.2.4.4 認証結果の扱い

DNS 問合せに対応するためには 480 文字より少なくすべきであることが示されています。

認証結果については、3.5 で解説します。

また、DNS サーバの負荷や受信側の認証処理

21

第３章

送信ドメイン認証技術

3.3 Sender ID

できます。RFC4407 は、この PRA の扱いを定義した RFC です。ヘッダに対して認証処

3.3.1 概要

理をするため、SMTP での通信上では、メール本文の内容をある程度読み込んだ上でない

Sender ID はネットワーク方式の送信ドメと認証が行えません。したがって、MAIL コマ

イン認証技術です。Microsoft 社が提唱したンドを受信した段階で認証結果が得られる

Caller ID for E-mail と SPF を統合する形でSPF に比べて、受信側では、運用時に、やや策定されました。Sender ID の仕様は、 SPF

システム負荷が高くなる場合があります。

の RFC（RFC4408）と同じく実験的カテゴ
リの RFC（RFC4406 と RFC4407）として、

3.3.2 Puported Resposible Adress(PRA)

標準化されています。
Sender ID は、SPF の影響を強く受けてお前述のように、Sender ID では、ヘッダ上のり、送信側では、SPF （RFC4408）で定義さ送信者アドレスから送信元のドメインを判断れている SPF レコードを利用して認証情報します。このとき、送信者を表す複数のヘッを公開できます。さらに、 Sender ID 独自でダを利用することで、転送時の問題を回避す拡張した宣言書式もあります。

るように考えられています。一般に、メールの送信者を表すヘッダは ”From” ですが、SPF と Sender ID の大きな違いは、 SPF

PRA では、それだけでなく、”Resent-Sender”、がリバースパスを対象に認証するのに対して、”Resent-From”、”Sender”、”From” の各ヘッ

Sender ID では、ヘッダ上の送信者アドレス

ダについても、この順に優先度が高い者としを対象に認証することもできます。実際に受て参照します。図表３－８にそれぞれのヘッ

信者が見るヘッダ上のアドレスを検査するこダの概要を示します。

とで、フィッシィング対策としての効果を強める狙いがあります。
ま た 、 複 数 の 送 信 ヘ ッ ダ （ Purported
Responsible Address。以下「PRA」といいます。
）を利用することで、転送時の問題を回避
ヘッダ
Resent-Sender:
Resent-From:
Sender:From:

概要
メールを転送したり、メーリングリストで再送する際に、転送等をしようとした者の代理でその転送等を実際に行った者（Resent-From と Resent-Sender が同じアドレスになる場合は Resent-Sender は付与しない）
メールを転送したり、メーリングリストで再送する際に、その転送等を行った者
メールの送信処理者（メールの送信者の代わりにメールの送信処理を実際に行った者）
メールの送信者（メールを実際に作成した者）

図表３－８

22

PRA（Purported Responsible Address）

第３章

なお、メールを転送するときや、メーリン
グリストで再送するときには、図表３－９で送信ドメイン認証技術

ックスにひもづくアドレスを Resent-From
ヘッダで指定します。

示すように、その転送等を実施するメールボ

図表３－９

転送時のＰＲＡ追加

認証時には、まず、Resent-Sender ヘッダ

ヘッダなどのヘッダを追加されていれば、受が存在する場合には、それを利用して認証を信側で認証を行うことができます。RFC5322

行います。Resent-Sender ヘッダが存在しな

では再送時には、再送フィールドを入れるべい場合には、次に、Resent-From ヘッダを探きと記載されており、また、再送ヘッダを入し、存在すれば、それを利用して認証します。

れる場合は、Resent-From を利用するとしてResent-From ヘッダもない場合は、次に、いるので、メールを再送する場合、Sender ヘッダ、さらにそれもなければ、From

Resent-From ヘッダを付与するべきです。な

ヘッダという順番で対象を変えます。From

お、直接は関係ありませんが、Resent-From

ヘッダが複数存在する場合は認証処理に失敗

ヘッダを付与した場合は、Resent-Date と再します。

送信時間を付与しなければなりません。

このようにすることで、たとえ、メールの3.3.3 SPF レコードのバージョン

配送時に転送等が行われて、From ヘッダでの認証ができなくても、転送時に、Sender ヘ

Sender ID では、 SPF で定義されている

ッダや Resent-From ヘッダ、Resent-Sender

SPF レコードを spf1 （バージョン 1）とし

23

第３章

送信ドメイン認証技術て 扱 い 、 Sender ID の SPF レ コ ー ド を

spf1 のレコードしか公開していないサイ

spf2.0 （バージョン 2.0）として扱います。

トからのメールについても Sender ID では

spf2.0 の SPF レコードでは、From ヘッ

認証対象としており、その場合、リバースパ

ダのアドレスを含む PRA を認証対象とする

スとPRA を 対 象 と し て 認 証 し ま すか、リバースパスを認証対象とするか、また（ ”spf2.0/mfrom,pra” と宣言されているとみその両方を対象とするかを、 SPF レコードなすことになります）。

上で指定できます。具体的には、レコードのまた、
1 つのドメインで、spf1 と spf2.0 の先頭のバージョンの表記である ”spf2.0” に

２つの SPF レコードを同時公開できます。

つづけて、認証対象のスコープを記述します。

図表３－10 は、spf2.0 と spf1 の SPF レ

PRA を 対 象 と し て 認 証 す る 場 合

コードの例です。バージョンの記述方法が微は ”spf2.0/pra” と、リバースパスを指定する

妙に異なるので、公開するときは間違えない

場合は ”spf2.0/mfrom” と、両方を対象とする

ように気をつけることが必要です。

場合は ”spf2.0/mfrom,pra” と記述します。

(spf2.0)
example.org.

IN

TXT

"spf2.0/pra include:example.org -all"(spf1)
example.org.

IN

TXT

"v=spf1 include:example.org -all"

図表３－１０24

spf2.0 と spf1 の SPF レコードの例

第３章

3.4 Domainkeys Identified Mail (DKIM)

送信ドメイン認証技術

図表３−11 では、次のような手順で DKIM 送
信ドメイン認証を実施しています。

3.4.1 概要①

example.jp ではあらかじめ DNS に電子署名に使う公開鍵を公開しておく
Domainkeys Identified Mail (DKIM) は、電②

example.jp のメールサーバでは送出メ

子署名方式の送信ドメイン認証技術です。

ールの本文とヘッダを元に電子署名を付与

IETF において、Sendmail 社の Eric Allman 氏する等を中心として検討が進められ、RFC4871 及
び RFC5672 として標準化されました。さらに 、 DKIM の 標 準 を 補 う も の と し て③

メ ー ル を example.com の サ ー バ にSMTP で送信する④

example.com の メ ー ル サ ー バ は

DKIM-ADSP と いう標準があ り、 RFC5617

DKIM-Signature の d パラメータに指定さで標準化されています。

れたドメイン部である example.jp の DNS

図表３−11 に示すように、DKIM では、送信側でメールから電子署名を作成して付与し、へ公開鍵を問い合わせる⑤

example.jp から取得した公開鍵により受信側でその電子署名を検証するという方法

電子署名を照合して OK であれば認証成で送信者のドメインの認証を行います。メー功

ル本体（ヘッダ及びメール本文の内容）をもとに電子署名を作成するので、中継メールサーバ（MTA）などで何らかの理由で電子署名
又は電子署名の元になったメール本体のデー
タが変更されなければ、たとえメールが転送されても、転送先で認証が可能です。

25

第３章

送信ドメイン認証技術

図表３－１１

DKIM による送信ドメイン認証

3.4.2 公開鍵の提供

り大きな鍵を利用する場合もあるとされていますが、同時に、実際には DNS の UDP パ

DKIM では、送信側のドメインの DNS 上

ケットサイズの 512 バイトにうまく収まるに、電子署名の作成に利用した秘密鍵に対応

最も長い鍵として 2048bit までが現実的であする公開鍵を公開します。公開鍵は、FQDNると説明されています。なお、1024bit より短に対する TXT レコードとして DNS に登録

い鍵では、オフラインでの解読行為に対して

します。

脆弱です。

鍵の長さは、512bit から 2048bit までがサポートされています。RFC では 2048bit よ

公開鍵を登録する FQDN 及びレコードの例を、図表３－12 に示します。

<セレクタ>._domainkey.<ドメイン名> <タグ>＝<値>
例： sls.dkim._domainkey.smtest.com. 300 IN TXT

図表３－１２

26"v=DKIM1; k=rsa; t=y;p=MIGfMA0GCSqGSIb3...<省略>"

公開鍵を登録する FQDN 及びレコードの例< セ レ ク タ > は 、 3.4.3 で 解 説 す る

異なるセレクタを用意することで、同じド

DKIM-Signature ヘッダの s タグに指定した

メインに対して複数の公開鍵を運用できます。

ラベルになります。<ドメイン名>は、

公開鍵のレコードは、「タグ＝値」を ; で列

DKIM-Signature ヘッダの d タグに指定され挙することになります。利用できるタグを、たドメイン名になります。

図表３－13 に示します。

第３章

タグ

値

v

Key レ コ ード のバ ー ジョン番号g

鍵の適用条件パターンh

利用可能なハッシュ方式

k

鍵の形式

n

説明

p

公開鍵データs

サービスタイプt

フラグ

説明・ 指定する場合は、「DKIM1」になる。省略した場合も、「DKIM1」になる。
・ 指定する場合は、レコードの最初に記述する。
・ 電子署名の対象とするメールのメールア
ドレスのローカルパートにマッチする条
件パターン。
・ ワイルドカード文字「*」が利用できる。
・ この鍵を利用できる送信者のメールアド
レスを限定する場合に利用する。省略時は「*」になる。
・ 電子署名の作成の際に利用できるハッシ
ュ方式を限定する。省略した場合には、す
べてのハッシュ方式を許容する。
・ 電子署名の作成者と照合者の両方がsha256 方式をサポートする必要がある。
また、照合者は sha1 もサポートする必要がある。
・ 電子署名の作成の際に利用できる鍵の形
式を指定する。省略した場合には、「rsa」になる。
・ 可読な説明文を保持するタグ。省略した
場合には、無（長さ０の文字列）になる。
・ 公開鍵のデータを保持するタグ。鍵デー
タは base64 でエンコードする。
・ 値が指定されない場合は、該当の鍵が無効になっていることを示す。
・ 当該鍵が有効であるサービスを指定する。
・ カンマで区切って複数指定できる。現時点で指定できるサービスは、「*」（すべてのサービス）と「email」（電子メール）の２つがある。省略した場合には、「*」となる。
・ フラグを指定する。
・ 「:」で区切って複数指定できる。
・ 指定できるフラグには、「y」と「s」がある。「y」は DKIM の運用が試験モードであることを示す。「y」フラグがある場
合は、受信者は認証に成功したメールとそ
うでないメールを区別して処理してはいけない。「s」が指定されている場合は、i=に指定されたアドレスの @ から右のドメイン名は d= に指定された値と一致する必要がある。省略した場合には、フラグなしとなる。

送信ドメイン認証技術

省略の可否
設定することが推奨されるが省略可能

省略可能

省略可能

省略可能
省略可能

必須

省略可能

省略可能

図表３－１３ レコードに利用できるタグ

3.4.3 送信側での電子署名の作成

ッダとして付与します。DKIM-Signature ヘッ
ダの書式は、「タグ=値」の組を ; で区切って送信側では、メール本体（ヘッダ及びメー

列挙します。DKIM-Signature ヘッダの例を、

ル本文の内容）をもとに電子署名を作成しま

図表３－14 に示します。また、利用できるタす。作成した電子署名を、DKIM-Signature ヘ

グを、図表３－15 に示します。

27

第３章

送信ドメイン認証技術

図表３－１４ DKIM-Signature ヘッダ例
タグ
v
a
b
bh

値
バージョン
電子署名の作成に利用したアルゴリズム
電子署名データ
本体のハッシュ値c

メール本文とヘッダの正規化方式

d

ドメイン名

h

電子署名の対象としたヘッダ

i

認証対象送信者アドレス

l

電子署名の対象とした本文の長さq

公開鍵取得方法

s

セレクタ

t

電子署名実施時のタ
イムスタンプx

有効期限z

電子署名の対象としたヘッダのコピー

説明・ バージョン番号を示す。
・ 現時点では、「1」と指定する。
・ 電子署名の作成に利用したアルゴリズムを指定する。
・ 「rsa-sha1」と「rsa-sha256」が利用できる。
・ 電子署名データ。base64 にエンコードして指定する。
・ 電子署名の対象とした本体のハッシュ値。
・ 電子署名の作成に利用する正規化処理の方法を指定する。
「/」
で区切って、それぞれメール本文正規化に利用したアルゴリズ
ムを表示する。
・ 「simple」と「relaxe」が指定できる。省略した場合には、「simple/simple」になる
・ 電子署名の作成を行ったドメイン名、すなわち、送信ドメイ
ン名を指定する。公開鍵の取得の際に参照するドメイン名の一部になる。
・ 後述の i タグに与えられるアドレスのドメイン名は、このタグに与えられる値と同じか、又は、サブドメインであることが必要である
・ 電子署名を作成するデータに含まれたヘッダ。: で区切って複数列挙できる。
・ 送信者を示すヘッダである From や Sender などは、必ず
電子署名の対象に含めることが必要である。
・ メールの送信者や送信プログラム（メーリングリストなどの場合）のメールアドレス。省略した場合には、 d タグに指定したドメイン名の先頭に @ を追加した値になる。
・ 電子署名の作成を行ったメール本文の先頭からの文字長（バイト長）。省略した場合は、メール本文すべてを電子署名の対象とする。
・ 公開鍵を取得する方法を指定する。現時点では「dns/txt」のみ指定可能。省略した場合には、「dns/txt」となる。
・ 公開鍵を取得する際に、クエリを発行する対象のドメイン名の一部に利用する。
・ 複数のセレクタを持つことで、１つのドメインで複数の公開鍵を利用できる。
・ 電子署名を作成した日付を EPOC（1970 年からの秒数）で指定する。省略時は未定義となる。
・ 電子署名の有効期限について、有効である日時を EPOC
（1970 年からの秒数）で指定する。省略した場合は、無期限になる。
・ 電子署名の対象にしたヘッダの電子署名の作成時の値を保持する。「｜」記号で、複数の指定が可能である。
・ デバッグ目的であり、認証処理には利用しない。

図表３－１５28

DKIM のタグの概要

省略の可否
必須
必須
必須
必須

省略可

必須

必須

省略可

省略可
省略可

必須
利用推奨（省略可）
利用推奨（省
略可）
省略可

第３章

送信側は、次の手順で電子署名を作成し、
DKIM-Signature ヘッダをメールに追加します。
1. 電子署名を作成する対象となるメールか確認する
2. 電子署名を作成する対象となるヘッダを決定し、h タグに列挙する
3. メール本文の内容から l タグに指定した送信ドメイン認証技術

外の DKIM-Signature ヘッダの値を併せてハッシュを作成する
4. 公開鍵を利用して、DKIM-Signature ヘッ
ダの電子署名データからハッシュを取り出す（復号する）
5. 電子署名から取り出した（復号した）ハッ
シュと、受信したメールから作成したハッシュを比較して、同じであれば認証成功

長さを取り出し、正規化処理を実施する
4. ヘッダ、正規化したメール本文の内容、こ3.4.5 認証結果の扱い

れから追加する DKIM-Signature ヘッダの電子署名のデータを除いた部分をつな

DKIM では、認証する対象の送信ドメイン

げたデータに対して、ハッシュを作成する

は、メールの From ヘッダから取り出すので

5. ハッシュに対して電子署名を作成し、はなく、DKIM-Signature ヘッダに指定されて

DKIM-Signature ヘッダとして付与したのいるドメインや送信アドレスを対象に認証しち、DKIM-Signature 自体をヘッダに追加ます。このため、ヘッダ上の送信者である

する

From 行の値と、認証に利用したドメイン名が異なる場合が存在します。DKIM の RFC

3.4.4 受信側での処理においては、認証結果に対するメールの扱い
についてははっきりと定義されておらず、受信側では、メールに付与された
DKIM-Signature ヘッダを取り出し、次の手順

DKIM-ADSP の RFC において説明されています。

で電子署名の検証を行います。
1. DKIM-Signature ヘッダの d タグ、 s タ
グの値から、公開鍵を取得する FQDN を

DKIM-ADSP については 3.4.6 で、認証結果の詳細については 3.5 で解説します。

作成する
2. 公開鍵を取得する。このとき、 i タグに設定してあるメールアドレスのローカルパ

3.4.6

DomainKeys Identified Mail (DKIM)

Author Domain Signing Practices (ADSP)

ートが DKIM レコードの g タグの条件パターンにあわない場合は、電子署名の照3.4.6.1 概要

合を行わない3. h タグに記述してあるヘッダと、メール本

Author Domain Signing Practices（ADSP）

文の内容（ l タグで有効な本文の長さが指とは、 DKIM の認証結果をどのように扱うべ定してある場合は、先頭からその長さだけきかを示すポリシーを送信側で公開するもの

を切り出したもの）及び電子署名データ以

です。

29

第３章

送信ドメイン認証技術

3.4.5 で解説したように、DKIM では、メーと、電子署名を作成したドメインが異なる場

ルの DKIM-Signature ヘッダから認証対象の合があります。

ドメインを取り出しますので、From ヘッダ

まず、DKIM-ADSP では、これを図表３－に指定されている送信者アドレスのドメイン
分類

16 のように整理しています。

原文

認証成功した電子署名

Valid Signature

メール作成者アドレス

Author Address

メール作成者ドメイン

Author Domain

メール作成者ドメイン電子署名

Author Domain Signature

図表３－１６意味
DKIM の電子署名の認証処理に成功した電子署名（DKIM-Signature ヘッダ）
メールの From ヘッダに指定されている送信者アドレス
メール作成者アドレスのドメイン部分
照合が成功した電子署名で、かつ、
DKIM-Signature ヘッダの d タグに指定したドメインとメール作成者ドメインが同一である電子署名

DKIM-ADSP で追加された署名およびメール作成者の整理

DKIM-ADSP では、メール作成者ドメインとなります。

電子署名として認証できれば、そのメールの<ドメイン名> は、From ヘッダのアドレス

送信ドメインは認証された（pass）と判定しのドメイン名部分となります。電子署名の検ます。認証に成功した電子署名がないメール、証に使う公開鍵を DKIM-Signature ヘッダの検証した電子署名のドメインがメール作成者

d タグや i タグをもとに読み出すのに対して、ドメインと異なる場合などにおいて ADSPADSP は、ヘッダ上の送信ドメインから取りレコードを参照する必要があります。

出す点が相違していますので、注意が必要です。

3.4.6.2 ADSP レコードの公開

ADSP は、”dkim=値” で記述します。値には、図表３－17 に示すものがあります。

ADSP も DNS 上に TXT レコードで公開します。公開に利用する FQDN は_adsp._domainkey.<ドメイン名>値
allunknown
discardable

概要
このドメインから送信されるメールは、すべてメール作成者ドメイン電子署名が与えられる。
このドメインから送信されるメールのいくつか又はすべてに、メール作成者ドメイン
電子署名が得られる。
このドメインから送信されるメールは、すべてメール作成者ドメイン電子署名が与えられる。そして、もしメール作成者ドメイン電子署名が得られない場合は、受信者はそのメールを破棄することが望まれる。

図表３－１７30

DKIM-ADSP の値第３章

3.4.6.3 DKIM-ADSP 利用上の注意点

送信ドメイン認証技術

ール作成者ドメイン電子署名で認証に成功した場合）のみの結果を利用し、それ以外の場

メール作成者ドメイン電子署名以外のケー合は、その結果だけでなりすましメールであスの場合、特にメーリングリストに投稿したると判断しないようにすることが必要です。

メールの場合の扱いなどについては、現在も検討中となっており、特に送信側で ADSP レ
コードを公開する場合には、注意が必要です。
また、受信側では、認証に成功した場合（メ

31

第３章

送信ドメイン認証技術

3.5 認証結果のヘッダへの表示

RFC5451 では、認証結果を記録するヘッダとして、Authentication-Results ヘッダを利用す

3.5.1 Authentication-Results

るよう定義されています。
Authentication-Results ヘッダを利用して送信ドメイン認証技術による認証の結果を記録した例を、図表３－18 に示します。

該当のメールのヘッダに記録する場合の方法
は 、 RFC5451 で 標 準 化 さ れ て い ま す 。

Authentication-Results: smtp.example.co.jp;
dkim=pass (1024-bit key) header.i=user@example.com; spf=pass (example.co.jp: domain of
user@example.com designates 192.0.2.1 as permitted sender) smtp.mail=user@example.com

図表３－１８Authentication-Results ヘッダを利用して記録した例

3.5.2 ヘッダの詐称

3.5.3 認証方法ごとの結果表示

Authentication-Results ヘッダには、認証を3.5.3.1 概要

実施したメールサーバの ID も同時に記録します。

１つの Authentication-Results ヘッダで、また、このヘッダの詐称を防ぐために、ま複数の種類の認証方式による認証の結果を表

ったく関係のない外部のドメインから、内部示できます。図表３－18 の例では、dkim との ID が認証を実施したメールサーバとして

spf の結果が表示されています。

ヘッダに記録されたメールを受信した場合にAuthentication-results ヘッダの表示の方法

は、そのヘッダを削除することが必要です。

を、図表３－19 に示します。１つの認証方法
による認証の結果は、１つの「認証結果情報」に表示します。「認証結果情報」は、「認証結果」、「理由」及び「プロパティ情報」で指定します。

Authentication-Results: 認証実施ホスト ID;バージョン; 認証結果情報; 認証結果情報;・・・※ バージョンは、省略可能※ 認証結果情報は、認証結果 理由 プロパティ情報 が指定されます。
－ 理由は、省略可能－ プロパティ情報は、指定されないか、１つ以上指定される場合があります。

図表３－１９32

Authentication-results ヘッダの表示の方法

第３章「認証結果」は、認証処理の結果を表示す

送信ドメイン認証技術

定される認証方法の概要を図表３-20 に示しるもので、「認証方式ラベル=認証結果の値」

ます。

で表示されます。
「認証方式ラベル」として指
認証方法
iprev
auth
dkim
dkim-adsp
domainkeys
sender-id
spf

説明
RFC5451 にて定義されている接続ホストの IP アドレスの逆引きに基づく認証方法
SMTP 認証 (SMTP AUTH)
DKIM 送信ドメイン認証
DKIM-ADSP 送信ドメイン認証
DomainKeys 送信ドメイン認証
Sender ID 送信ドメイン認証
SPF 送信ドメイン認証

図表３－２０

認証結果一覧

「プロパティ情報」では、認証対象が何で複数の認証方式の結果を表示する場合は、”;”あったかを表示することが可能です。表示す（コロン）で区切って並べます。認証方式ラる場合には、認証対象が何であったかを示す

ベルと認証対象タグとして指定されるものを、認証対象タグと、その実際の値を組として、

図表３－21 に示します。

認証対象タグ=認証対象の値の形で表します。
認証方式
dkim
dkim-adsp
sender-id
spf

認証対象タグheader.i
header.dheader.fromheader.ヘッダ名
smtp.mailfrom
smtp.helo

意味
DKIM 認証において i= タグに指定された送信者を元に認証を行った
DKIM 認証において d= タグに指定された送信者を元に認証を行った
DKIM-ADSP 認証処理において From ヘッダを元に認証を行った
Sender ID の認証において、表示されたヘッダ名のヘッダに対して認証行った
SPF 認証においてエンベロープの送信者に対して認証した
SPF 認証において HELO コマンドの引数のホスト名を元に認証した

図表３－２１

プロパティ情報一覧

3.5.3.2 SPF 及び Sender ID での結果表示

３－22 で示すように、”none”、”neutral”、”pass”、”policy”、”hardfail”、”softfail”、”temperror”、”

Authentication-Results ヘ ッ ダ で は 、 SPF

permerror” があります。

及び Sender ID での認証結果の値には、図表
値
none
neutralpass
policyhardfail
softfailtemperror
permerror意味
SPF レコードが宣言されていない
送信元のドメインでは、該当のホストが認証できたかできないかを明らかにしない認証に成功した
認証は成功したがローカルなポリシーによってその認証結果は受け入れられない
認証が失敗した認証は失敗であるが、はっきりと認証失敗としては扱ってほしくない
一時的な問題で認証処理を実行できなかった
SPF レコードの文法的な誤りなど永続的なエラーで認証処理を実行できなかった

図表３－２２

SPF での認証結果の値

33

第３章

送信ドメイン認証技術”none” は、SPF レコードが公開されていは ”neutral” になるとされています。

ないため、認証できなかった場合です。この”softfail” は、SPF レコードが公開されてお場合、送信ドメイン認証では、送信元についり、送信元の IP アドレスが「~」クオリファての評価が下せないため、従来どおりスパム

イヤの条件にマッチする場合です。RFC でフィルタを通すなどしてメールの扱いを決定

は、”fail” と ”neutral” の中間くらいの扱いをします。結果が none だった場合には、メーすべきであるとされています。結果

ルを即座に受信拒否すべきではありません。

が ”softfail” である場合には、メールを即座に”neutral” は、送信ドメインの SPF レコー
ドが、例えば「v=spf1 ?all」のように定義され受信拒否すべきではありません。
”temperror” は、一時的な障害で認証処理がている場合や、

失敗した場合です。対応としてはメールを一「v=spf1 +ip4:xxx.xxx.xxx.xxx ?all」

時エラー（4XX）で受信拒否するか、そのまのようにレコードの末尾が「?all」と定義されま受信することになります。受信した場合は、ていて、先立つほかの条件にマッチせず「?all」

少し厳しく扱うべきです。

にマッチした場合です。 RFC には、neutral”permerror” は、SPF レコードは公開されは none と同じように扱うべきであるとされているが、SPF レコードの記述に誤りがあるています。また、softfail よりは正当性が高い

場合などです。この結果であっても、永続的ものとして扱う可能性があるとも説明されてな受信拒否をすべきではありません。

います。結果が neutral だった場合には、メールを即座に受信拒否すべきではありません。

3.5.3.3 DKIM での結果表示”pass” は、送信元の IP アドレスが SPF
レコードにマッチし、認証に成功した場合でDKIM 認 証 の 結 果 と後 述 の DKIM-ADSP

す。送信ドメインは正当であるので、あとは認証の結果は、それぞれ別のものとして扱わ

その送信ドメインの評価に従ってメールを処

れます。

理します。
“hardfail“ は、SPF レコードが公開されてで示すように、”none”、”neutral”、”pass”、

いるが、送信元の IP アドレスが「-」クオリ”policy”、” fail”、”temperror”、”permerror” がファイヤの条件にマッチする場合です。
「?all」あります。

や「~all」が末尾に設定されている SPF レコードを持つ送信ドメインのメールに対しては、この結果は発生しません。なお、RFC では、「all」の記述が省略された SPF レコードに対して、どの条件にもマッチしない場合

34

DKIM での認証結果の値には、図表３－23

第３章

値
none
neutralpass
policyfailtemperror
permerror

送信ドメイン認証技術

意味
メールに DKIM の電子署名が付与されていない
メールは DKIM の電子署名が付与されていたが、DKIM の電子署名の文法上の誤りなどで、照合処理できなかった
メールに DKIM の電子署名が付与されており、その電子署名は受信者にとって受け入れられるもの
であり、かつ、電子署名の照合が成功した
メッセージには DKIM の署名が付与されていたが、ローカルなポリシーによってその電子署名は受け入れられない
メールに DKIM の電子署名が付与されており、その電子署名は受信者にとって受け入れられるもの
であるが、電子署名の照合が失敗し、認証が失敗した
一時的な問題で認証処理を実行できなかった照合に必要なヘッダが存在しない場合など永続的なエラーで認証処理を実行できなかった

図表３－２３

DKIM での認証結果の値

3.5.3.4 DKIM-ADSP での結果表示”pass”、”discard”、”nxdomain”、” fail”、”temperror”、”permerror” があります。

DKIM-ADSP での認証結果の値には、図表３－24 で示すように、”none”、”unknown”、
値
none
unknown
pass
discardnxdomainfailtemperror
permerror

なお、前述の DKIM 認証の結果はそれぞれ別のものとして扱われます。

意味
DKIM-ADSP レコードが公開されていない。
メールにはメール作成者ドメイン電子署名が付与されておらず、かつ、DKIM-ADSP レコードに
unknown が公開されている場合
メールが DKIM 電子署名を付与されており、電子署名の照合が成功し、かつ、それがメール作成者
ドメイン電子署名である場合
メールにはメール作成者ドメイン電子署名が付与されておらず、かつ、DKIM-ADSP レコードにdiscardable が公開されている場合
メッセージにはメール作成者ドメイン電子署名が付与されておらず、かつ、メール作成者ドメインが
DNS 上に存在しない場合
メールはメール作成者ドメイン電子署名が付与されておらず、かつ、DKIM-ADSP レコードに all が公開されている場合
一時的な問題で認証処理を実行できなかった照合に必要なヘッダが存在しない場合など永続的なエラーで認証処理を実行できなかった。

図表３－２４

DKIM-ADSP での認証結果の値

35

第４章

送信ドメイン認証技術導入手順

第４章

送信ドメイン認証技術導入手順

送信ドメイン認証技術は、メールの送信側と受信側の双方が協調することによって成り

容、導入後の運用にあたり注意すべき点などについて解説します。

立っています。送信ドメイン認証技術は、既4.1 事前準備

存のメール配送の仕組み (SMTP) に直接影響を与えることなく下位互換的に導入することができますので、メールの送信側と受信側

送信ドメイン認証技術の導入に際し、予めのどちらの立場からでも導入することができ検討しておくべき事項がいくつか存在します。

ます。

どの技術を導入すべきか、送信側と受信側のどちらから導入すべきか、導入の時期をどう

本章では、送信ドメイン認証技術の導入に判断するか、という基本的な検討のほか、 送

際し、事前に検討しておくべきことや、それ

信ドメイン認証技術を正しく機能させるためぞれの送信ドメイン認証技術について、送信のメールの運用部分についても検討が必要で側と受信側のそれぞれの側での実際の作業内す。

導入する送信ドメイン認証技術の決定

4.1.1

・ SPF、Sender ID、DKIM のうち、どの技術を導入するか

ドメイン名の把握

4.1.2

・ 利用しているドメイン名の把握
・ ドメインの利用方法の把握
・ メールの配送経路の把握

メール利用方法の確認

4.1.3

・ メール配送経路
・ 再配送メールの取り扱い
・ 外部ネットワークからの利用環境の整備

導入計画の作成
・ メールサーバの負荷調査
・ 受信メールの傾向調査
・ 認証結果の取り扱い

図表４―１

38

・ 効果の予測と見直し
・ 利用者への周知
・ 導入手順の策定

事前準備

4.1.4

第４章

例えば、メール送信側として、送信ドメイン認証技術を導入したにもかかわらず、それ

送信ドメイン認証技術導入手順

ン認証技術において、どのような意味があるのかについて補足して説明します。

が正しく運用されなければ、送信者情報を偽装していないにもかかわらず認証が失敗する

4.1.1 導入する送信ドメイン認証技術の決定

ようなメールが流通してしまう可能性があります。そのようなメールが多くなれば、その前述のとおり、送信ドメイン認証技術では、ドメイン名自体の信用も失われてしまう可能

メールの送信側と受信側の双方が導入するこ性があります。

とによって、はじめて認証が可能になるため、

また、メールの受信側では、送信ドメイン
認証技術を利用することにより得られた認証

送送側と受信側の双方での導入が同程度進むことが望ましいものです。

結果をどのように利用すべきなのかを考える

導入のための費用は導入する技術によって必要があります。そのためには、実際のメー差があり、技術によっては送信側ではほとん

ルの配送形態でどのような認証結果が得られど費用がかかりませんが、いずれの技術でも、る可能性があるのかを正しく理解し、これら受信側での導入には受信時に認証するという

メール配送の事情に合わせた検討が予め必要

新たな機能の追加が必要になるので、新たにになります。

費用か発生することになります。そのため、
まず送信側の導入を増やすことによって、受以下では、送信ドメイン認証技術の導入に

信側での認証可能なメールの割合を高め、導あたり、事前に検討すべき内容について具体入効果が得られやすい環境を作ることが普及的に解説するとともに、それらが送信ドメイを進めていくために必要となります。

図表４－２ 普及のサイクル

送信ドメイン認証技術のうち、送信側の導ればメールの送信ごとの処理が不要な

入費用が低い技術は、ドメインを管理する

SPF/SenderID です。そのため、導入費用の

DNS 上に、導入時に SPF レコードを記述す

低さからも、まず SPF/SenderID の送信側の

39

第４章

送信ドメイン認証技術導入手順

導入は、全てのドメインにおいて実施すべきール本体が改変されていないことの判別もでです。実際に幾つかの導入状況の調査結果かきること、電子署名というメールの配送経路

らも、SPF レコードの宣言率が高く、に依存しない技術を利用するため、配送経路

SPF/SenderID の送信側の導入が進んでいる

上の各メールシステムに変更を加えることなことが分かります。

く多くの利用局面で利用できることなど、受信側については、SPF レコードの宣言率

SPF/SenderID にはない利点があります。そのが高いことから、SPF/SenderID の認証機能

ため、DKIM の導入については、送信するメの導入が効果が得やすいでしょう。SPF とールの重要度や受信しているメールに係る送SenderID では、送信者情報の種類に違いがあ

信側での DKIM の導入割合などを考慮し、導りますが、SPF レコードの形式はバージョン

入を進めるべきです。

番号を除いて同じですので、可能であれば4.1.2 ドメイン名の把握

SPF/SenderID の両方の認証ができる機能の導入が望ましいと考えられます。

次に、自組織内で利用しているドメイン名
DKIM については、送信側の導入にあたっを把握しなければなりません。具体的には、ても、 SPF/SenderID に比べて導入のための費利用しているドメイン名の把握、ドメインの用はかかりますが、メールの送信者情報が詐称

利用方法の把握、メール配送経路の把握が必されているかどうかを認証する以外にも、メ要です。

利用しているドメイン名の把握

4.1.2.1

・ 網羅的に把握することが必要

ドメインの利用方法の把握(b) メールに利用せず(a) メールに利用

メール配送経路の把握 4.1.2.3(a) 単一ドメイン名を用いたメールを一つのメールサーバから配送(b) 単一ドメイン名を用いたメールを複数のメールサーバから配送(c) 複数のドメイン名を用いたメールを一つのメールサーバから配送(d) 複数のドメイン名を用いたメールを複数のメールサーバから配送
図表４ー３

40

4.1.2.2

SPF / Sender ID ：メールに利用しないドメイン名であることを宣言可能
DKIM：DKIM ADSP で DKIM の認
証結果をどのように扱うべきかを示すポリシーを宣言可能

ドメイン名の把握

第４章

4.1.2.1 利用しているドメイン名の把握

送信ドメイン認証技術導入手順

うな方針 (discardable) を宣言することで、勝手にドメイン名を利用するようなメールを防

まず、自組織内で利用しているドメイン名
自体を正しく把握しなければなりません。

ぐことができます。DKIM ADSP については、
3.4.6 を参照してください。

その際、メールに利用しているドメインについて把握することはもちろんですが、それ4.1.2.3 メールの配送経路の把握

以外に、ドメイン名の構造上存在する上位ドメインや、メール以外の用途に使っている

次に、メールに利用しているドメインにつDNS で参照可能なドメイン名についても確いて、そのドメインを用いて送信されるメー

認することが必要です。

ルの外部への配送経路を把握しなければなりません。

4.1.2.2 ドメインの利用方法の把握

配送される形態としては、大きく分けて、ドメイン名を把握したあとは、それぞれのドメインの利用方法を確認しなければなりません。
ドメインの利用方法は、メール利用の観点からは、大きく以下のように分類することができます。
(a) メールに利用しているドメイン名(b) メールに全く利用していないドメイン名

次の４つが考えられます。
(a) 単一ドメイン名を用いたメールを一つのメールサーバから配送(b) 単一ドメイン名を用いたメールを複数のメールサーバから配送(c) 複数のドメイン名を用いたメールを一つのメールサーバから配送(d) 複数のドメイン名を用いたメールを複数のメールサーバから配送(a) については、メールの配送経路を把握す(a) の場合には、そのドメインを利用するメ

ること、適切な送信ドメイン認証技術の送信

ールの出口（メールサーバ）が一つのメール側の設定をすることが必要です。メールの配サーバであることを、利用する送信ドメイン

送経路の把握については、4.1.2.3 を参照して認証技術を用いて設定することになります。

下さい。
(b) については、SPF / Sender ID では、メ(b) の場合としては、送信効率を上げるためールに利用しないドメイン名であることをに複数のメールサーバを利用しているような

SPF レコードで宣言することができます。こ場合や、同じドメイン名を利用した特定のメの設定方法の詳細については、3.2.3 を参照しールの配信を外部委託しているような場合がてください。DKIM では 、DKIM ADSP であります。この場合にも、利用する送信ドメ

DKIM の認証結果をどのように扱うべきかをイン認証技術で、それぞれの送信側のメール

示すポリシーを宣言できます。例えば、電子サーバが、そのドメインから配送されるメー署名が付与されていないメールを破棄するよ

ルの正しい出口（メールサーバ）であること

41

第４章

送信ドメイン認証技術導入手順を設定できます。

この場合には、それぞれのドメインが同じメールの出口を示すことで、受信側の認証に問(c) の場合としては、メールの利用目的別に題は生じません。

複数のドメインを併用している場合や、組織

なお、いずれの形態であっても、メールがごとにサブドメインを利用しているものの、外部に配送される前に、そのメールで利用さ全体の規模としてそれほど大きくないために、れるドメイン名の利用権限を送信者が適切にメールサーバを集約している場合などが考え有しているかを、何らかの方法で確認するこられます。また、メールサービスを外部の複とが必要です。この確認が適切に行われてい数の組織 (ドメイン名) に提供している、いわないと、利用権限のない者がドメイン名を詐ゆるホスティングサービスの場合などもあり称して不正なメールを外部に配送することがます。さらに、(b) のメール配送業務を複数受できてしまいます。こうしたことが行われる

託し、複数のドメイン名を送信者情報としてと、送信ドメイン認証技術を設定していたこ

利用する場合も、この形態に含まれます。

とによって、受信側のメールサーバで、詐称されたメールの認証に成功してしまい、かえって問題となってしまいかねません。

図表４ー４ 送信者情報の利用権限の確認(d) の場合には、クラウドサービスを用いたしなければなりません。

ホスティングに多く見られる形態で、複数の具体的には、メールの配送経路の方針、再ドメインで複数のサーバを共有している場合配送を行うメールの利用方針、複数のドメイがあります。また、(b) と (c) の組合せのケンを利用する場合の方針、外部ネットワーク

ースもあります。これらの場合には、(b)、(c)から利用する場合の方針のそれぞれについて

における対応を組み合わせることで正しい設決定が必要です。

定が可能です。
4.1.3.1 方針検討の必要性
4.1.3 メールの利用方法の確認

メールの送信に利用するドメイン名と、実際
事前準備の最後に、メールの利用方針を決定

42のメールの配送経路は、これまで比較的柔軟第４章

送信ドメイン認証技術導入手順に運用されてきました。しかし、迷惑メール- 外部ネットワークからの利用環境の整備

がメール流量の大部分を占めるようになって（4.1.3.4）

きた現在では、正しいメールが適切に受信できるようにするために、メールの利用方針を

4.1.3.2 メールの配送経路適切に決定し、運用することが必要です。
送信ドメイン認証技術が適切に機能するよ

メールの利用形態としては、（典型的なものうにするためには、正規に送信されるメール

として）１対１のコミュニケーションを目的

が、送信側で利用するドメイン名に対応したとしたものがあります。そのような場合には、正しい出口（メールサーバ）からのみ配送さ送信に用いられるメールサーバが特定できまれるようになっていることが重要になります。

すので、送信ドメイン認証技術の導入にあたっても、そのメールサーバを利用ドメイン名

技術革新に伴い、メールの利用形態は多様化してきています。例えば、携帯電話の通信の出口（メールサーバ）として設定することになります。

網を利用したデータ通信端末や無線 LAN のメールの利用形態には、そのような一般的

アクセスポイントなどモバイル環境は急速になメール配送以外にも、顧客へのアナウンス

普及してきており、それに伴い、これらの回や特定の参加者への連絡網といった多数の宛線を利用したメールの利用も増えてきていま

先への一斉送信などがあります。メールの大す。

規模配信を行う場合には、送信中に通常のメ

また、業務として利用するメールや、個人ールが阻害されたりすることがないように専で利用しているメール、ウェブメールなどア

用のメールサーバを利用することがあります。

クセス端末をあまり選ばずしかも無料で利用

また、こうした配送処理を効率よく行うため可能なメールなど、同一の個人が複数のメーに、専門の外部事業者へ委託することがあり

ルアドレスを利用するようになっています。

ます。これらの場合に利用する送信者情報のドメイン名については、次の２つの考え方がこうしたメールの利用形態の多様化を踏まあります。

え、それぞれのドメインごとにメールが適切(a) 大量送信用の専用ドメイン名を利用に受信できるようにするための対応が必要と(b) 通常のメールと同じドメイン名を利用なりますが、それについては、技術的に対応可能な部分や、利用方針に基づく運用によるべき部分もあります。

(a) としては、サブドメインを新たに作成する場合や、別のドメイン名を取得する場合

以下では、メールの利用方針を決定し、そなどが考えられます。この場合には、専用ドれに基づく運用を適切に行う必要がある部分

メイン名を使って配送する出口（メールサー

として、次の点について、詳細に検討します。

バ）を特定し、それぞれのメールサーバで適- メールの配送経路（4.1.3.2）

切な送信ドメイン認証技術を導入することに- 再配送メールの取り扱い（4.1.3.3）

なります。

43

第４章

送信ドメイン認証技術導入手順

図表４ー５

大量送信用の専用ドメインを利用する例(b) には、メールの受信側にとって同じ組織

DKIM の場合には、電子署名の作成に利用からのメールであるという印象を強く受けるする秘密鍵の管理の問題がありますので、外ため、信用度が比較的高くなるといった利点

部委託している場合で秘密鍵を共有できる関があります。その場合には、大量送信される係にないときなどには、(b) の方法を採ること

メールは、通常のメールとは配送出口（メーはできず、署名ドメイン自体を別ドメインとルサーバ）が異なりますので、そのドメイン

し、それぞれで鍵の管理と運用を行うことが名に対する送信ドメイン認証技術の設定に、必要になります。

これら大量送信を行うメールサーバを追加する必要があります。

4.1.3.3 再配送メールの取り扱い

例えば、SPF / Sender ID の場合には、SPF

これまで利用されてきたメール利用形態のレコードに、これら大量送信を行うメールサ

一つに、メールを一旦受信した後、外部へ再ーバを追加することになります。大量送信を配送するような場合があります。具体的には、行うメールサーバの管理が別組織で行われてメールを転送するときやメーリングリストでいたり、外部委託されたりしている場合には、再送するときなどです。これらの再配送処理

それら実際の管理元で別のドメイン名でにあたっては、送信ドメイン認証技術として

SPF レコードを宣言してもらい、それを考慮しなければならない事項があります。こ"include" などの機構を使って取り込むこと

れらは、それぞれの送信ドメイン認証技術で、ができます。これにより、大量送信を行うメ影響の受け方や対処方法が異なりますので、ールサーバが追加されたり、何らかの事情で4.2 で解説します。

IP アドレスが変更されたりした場合でも、通44

常のメールサーバのドメイン名の管理側にそ

いずれの技術を利用する場合でも、再配送の都度連絡をすることなく、独立して運用すを行う際には、メール受信時に事前に認証をることができます。

行い、その認証結果をメールヘッダに記録し第４章

送信ドメイン認証技術導入手順

た上で再配送したり、正しく認証できたメー

信手段を用意し、内部ネットワークにアクセ

ルだけを再配送したりするなどの考慮が必要

ス可能にする方法や、外部ネットワークからです。

アクセスできる位置に送信メールサーバを用意する方法などがあります。

4.1.3.4 外部ネットワークからの利用環境の整備

このような場合には、ネットワーク接続に利用している回線が OP25B を実施している

モバイル環境や社外滞在先など、外部ネッ

可能性がありますので、メール配送に使われトワークからメールを送信することがありまる 25 番ポートではなく、メール投稿用のす。

587 番ポートを使えるように設定することが自組織で運営している送信用のメールサー必要です。また、送信者を正しく識別するたバは、通常、セキュリティ上の観点からファ

めに、SMTP AUTH (送信者認証) による認証

イアーウォールなどを用意し、インターネッを行うべきであり、認証方式についても、パト側から直接通信ができないような内部ネッ

スワードがそのままネットワークに流れない

トワークに設置されています。そのため、外方式 (例えば CRAM-MD5 など) を利用すべ部ネットワーク上からメール送信を行うこときです。

を可能とするためには、別途 VPN などの通図表４ー６

SMTP AUTH による認証

最近では、ホテルなどの環境でもインター

われる 25 番ポートを用いて直接インターネ

ネット接続サービスが提供されるようになっットへの通信ができず、一度アプリケーショてきていますが、これらの環境では特に注意

ン型のファイアーウォールなどで通信が終端が必要です。

されていることがあります。そのため、外部

特に、欧米のホテルなどでは、ネットワー

からアクセス可能な送信用メールサーバを用

クの不正利用を防ぐ目的で、メール配送に使意している場合で、MUA からは通常どおり送

45

第４章

送信ドメイン認証技術導入手順

信が行われたように見えても、実際には自組

た、受信側で認証を行うことにより DNS の織の送信用メールサーバを経由せず、ホテル

参照回数が増えるため、ネットワーク帯域やなどが用意しているファイアーウォールから

DNS のキャッシュサーバの負荷などの考慮送信される場合があります。この場合には、も必要になります。

メールの受信側では、受信したメールが、そ一般にメールの流量は、時間帯によってばのメールのドメインの本来の出口（メールサ

らつきがありますし、ピーク時に極端に負荷ーバ）から送信されているメールではないたが高くなる場合もあります。導入に際しては、

めに、認証が失敗することがありますので、予め一定の期間の負荷状況を計測し、予想さ注意が必要です。

れる負荷の上昇分を重ねた上で、設備設計を行うことが必要です。

4.1.4 導入計画の作成
4.1.4.2 受信メールの傾向調査

送信ドメイン認証技術の導入に際しては、技術自体の違いやそれに関連した運用上の特受信側では、広く受信メールの傾向を調査

徴以外に、より実際的な側面についても検討することによって、導入する技術の判断に役し、具体的な導入計画を作成することが必要

立てることができます。例えば、既に送信者です。

情報を詐称したメールに困っている場合や、その検討の際には、以下に挙げた観点が参取引先など受け取るべきメールが把握できて考になるでしょう。

いる場合には、認証の効果を予め予測するこ(a) メールサーバの負荷調査とができます。予め受け取るべきメールが明(b) 受信メールの傾向調査

確である場合は、それらのメールの送信側で(c) 認証結果の取り扱い

導入している技術を受信側でも導入するべき(d) 効果の予測と見直しです。

(e) 利用者への周知

送信側についても、受信側で認証している(f) 導入手順の策定

技術が予め分かる場合には、導入に際して、参考となるでしょう。

4.1.4.1 メールサーバの負荷調査
4.1.4.3 認証結果の取り扱い

メール送信側に DKIM を導入する場合や、

46

メール受信側で認証を行う場合には、メール受信側では、認証の結果の利用方法も予めサーバに新たな機能を追加することが必要で決めておくことが必要です。メールヘッダにす。この機能追加により、メールサーバの負認証結果を示すだけなのか、認証が成功した

荷が高くなりますので、導入前には既存のメ

特定のドメインをホワイトリスト的に優先的

ールサーバの負荷状態を把握することが必要に配送するのか、誤認証の可能性がないドメです。CPU などのリソースの負荷は、いずれインで認証が失敗した場合に隔離するのかなの技術を導入する場合でも高くなります。まど、認証結果を有効利用する方法はいくつか

第４章あります。受信メールの傾向調査と合わせて、送信ドメイン認証技術導入手順

4.1.4.5 利用者への周知と導入手順の策定

それぞれの認証結果と送信元のドメインに応じた、効果的な取り扱いの方針を決めることになります。

送信ドメイン認証技術を導入する際には、予めメールの利用者に対して、送信側及び受信側

また、メールは多様な用途で用いられるたでの運用ポリシーを事前に説明しておくこともめ、メールシステム全体で一律に適用できな必要です。特に送信側の利用ポリシーについて

い認証結果に基づいた処理も、個々のメール

は、送信ドメイン認証技術の対象としているド受信者が MUA などで個別に設定することにメイン以外のドメインを送信者情報として利用

より、認証結果を有効に利用できる場合があしないよう周知しておくことが重要です。メー

ります。メールサービス提供者やメールシス

ルの受信側で認証が失敗するような使い方をしテムの管理者は、こうした設定例などをマニてしまうことによって、そのドメインやメールュアル等で利用者に周知すると良いでしょう。

の送信元の評価が低下してしまう可能性があります。

4.1.4.4 効果の予測と見直し

また、メールは絶え間なく送受信されてい受信側では、事前に受信メールの調査を行ることから、メールシステムへの送信ドメイ

うことにより、認証による効果を予測するこン認証技術の導入やそれに基づく新たな機能とができます。また、送信ドメイン認証技術

追加、仕様変更などは、頻繁にできない場合を導入するメールサーバは、今後も増えてくもあります。このため、手順を決めて、計画ることが予想されますので、導入時だけでな的に導入を進めることが必要です。

く、継続してメールの傾向を把握することがさらに、メールを送受信している相手の導有効です。これは、導入時には見送った技術

入状況も変化していきますので、日頃のメーがより機能するようになっていたり、認証結

ル送受信の状況の把握とともに、その結果に果をより効果的に活用できるようになってい基づいた新たな機能追加や仕様変更などの見たりするなどによるものです。

直しについて、予め計画を立てることも必要となります。

47

第４章

送信ドメイン認証技術導入手順

4.2 一般的な導入手順

うな場合には、4.1.3.2 で示したようにメールの配送経路 (出口) を正しく把握した後、それ送信ドメイン認証技術には、ネットワーク

をもとに SPF レコードを記述することにな

方式の SPF/SenderID と、電子署名方式のります。この場合、送信側の導入に際して特DKIM の二つの技術があります。それぞれの別な費用は発生しません。

技術についての概要、導入に際しての注意点については、第 3 章で解説しています。

メールの運用自体を外部委託している場合
や ISP のメールサービスを利用している場

ここでは、一般的な導入手順について、送合には、第 5 章以降を参考に、それぞれ設定

信側での対応を中心に、それぞれの技術ごとして下さい。なお、DNS の運用を外部委託しに解説します。また、導入に際して既存のメていて、自由に編集が行えないような場合にールの使われ方との関係や、問題が生じる場

は、委託先に SPF レコードの設定依頼が必合の対処方法について解説します。

要になりますので、送信側の導入に際し、費用が発生する場合があります。

4.2.1 SPF/SenderID

SPF/SenderID を受信側に導入し、メールのSPF と SenderID は、送信者を認証するた

受信時に認証するためには、受信メールサー

めに送信元の IP アドレスを利用するネット

バへの新たな機能追加が必要になります。すワーク方式であること、認証のために送信側

なわち、受信側での認証を行うためには、送のドメイン (DNS) 上にある SPF レコード

信元の IP アドレスが必要になりますので、を利用するなど、多くの共通点があります。

原則として、外部から直接メールを受けるサ

ここでは、両方の技術について、導入手順のーバ上に認証機能を追加する必要があります。

ほか、そのままでは認証がうまくできない課

例えば、迷惑メールフィルタ機能を提供する

題と対処方法などについて解説します。

サーバで、送信ドメイン認証機能も提供するものがありますが、その機能を用いるために

4.2.1.1 SPF/SenderID の導入手順

は、そのサーバが外部からのメールを直接受ける位置にあるかどうかの確認が必要です。

SPF/SenderID を送信側に導入するためにオープンソースの MTA として広く使われは、対象とする送信者情報のドメインに対している Sendmail や Postfix では、MTA の拡て SPF レコードを宣言することが必要にな

張機能を外部プログラムとして追加できるよります。

うに、milter インターフェースが標準で提供されています。この milter インターフェース

48

DNS サーバを自組織で管理している場合を利用した認証機能を実現するものが、同様

や、運用を委託しているサービスで、DNS のにオープンソースとして公開されていますの

資源レコードをある程度自由に編集できるよ

で、それを利用することもできます。

第４章

送信ドメイン認証技術導入手順

商用のメールサーバを利用している場合やせて下さい。その場合には、認証機能の追加

外部のメールサービスを利用している場合にには、新たに費用が発生する可能性がありまは、その開発元やサービス提供元に問い合わすので、確認が必要です。

図表４－７ SPF/SenderID の導入

4.2.1.2 課題と対策

信者情報をそのままにして、新たな受信者へメールを再配送してしまうことに起因する問ネットワーク方式の送信ドメイン認証技術

題です。

は、メールの再配送時に認証が失敗してしま

具体的な事例としては、メール転送や古いうという問題があります。これは、メールの実装のメーリングリストサーバで発生するこ

再配送時に、メールを一旦受け取った後、送とがわかっています。

図表４－８ メール再配送による認証失敗の例

49

第４章

送信ドメイン認証技術導入手順

この問題を回避するには、メールの再配送
時に、送信者情報をメールの再配送元のドメ
インに書き換える必要があります。

用する方法があります。
この場合、転送時にすべてのメールのリバースパスを単純に書き換えてしまうと、メールがループする可能性がありますので、転送

現時点でそれほど広く運用されているもの

時に利用するリバースパスは、転送者のメーではありませんが、メールの転送に関しては、

ルアドレスをそのまま利用するのではなく、

以下の方法を用いることで、転送先でも正し

例えば、図表４-9 のように、メールアドレス

く認証を行うことができるようになります。

のローカルパート部分を工夫して、エラーメールとして戻ってきた場合や、さらに再転送

まず、SPF の場合には、リバースパスを送されてきた場合に区別ができるようにするこ

信者情報として認証しますので、転送時に認とが必要となります。このようにすることで、証が失敗しないようにするために、転送を行転送したメールが何らかの事情で戻ってきた

う際のリバースパスとして、元の送信者のリ場合に、さらに転送を繰り返さないことによバースパスを利用するのではなく、転送元（転り、不要なループを防ぐことができます。

送者）のドメインを含むメールアドレスを利

図表４ー９

メール転送への対応の例

Sender ID の場合には、送信者情報として
PRA を用いて認証しますので、メールの転送

50

メーリングリストに関しては、リストメン

時に、PRA で優先的に使われるヘッダ

バの管理のために、エラーメールの送信先を(Sender ヘッダなど)に、転送元のドメインを示すリバースパスには、メーリングリストの含んだメールアドレスを送信者情報として付

管理用のメールアドレスを指定するようにな加すれば問題ありません。

っています。そのため、SPF では、リストメ

第４章

送信ドメイン認証技術導入手順

ンバ側で認証が失敗するようなケースはほとの MTA である Sendmail や Postfix のんどなくなっています。

milter インターフェースを利用することによ

しかし、一部の古い実装のサーバプログラ
ムのメーリングリスト機能では、PRA としてり、DKIM の電子署名の作成機能を追加することができます。

From ヘッダより優先度の高いヘッダを付け

DKIM では、電子署名の作成に公開鍵暗号ないものがあり、そうした実装では、SenderID

技術を使いますので、予め電子署名を作成すでは、リストメンバ側で認証が失敗してしまるときに利用する秘密鍵と、電子署名を検証います。

するために利用する公開鍵を用意する必要が

このため、メーリングリスト機能を使う場あります。オープンソースの OpenDKIM プ

合には、メーリングリスト側からメンバへのロジェクトでは、これら鍵のペアを作成する

送信時に、Sender ヘッダなどにメーリングリ

スクリプトプログラムもソースコード一式のスト管理用のメールアドレスを追加する機能中に含まれていますので、これを利用して鍵を持った、最近の実装のサーバプログラムをペアを生成することもできます。商用のメー

利用することが推奨されます。

ルサーバを利用している場合や外部のメールサービスを利用している場合には、その開発

4.2.2 DKIM

元やサービス提供元に問い合わせて下さい。
DKIM を送信側に導入するためには、新たに費DKIM では、送信者情報が正しく表明されているかどうかを、公開鍵暗号方式を利用し用が発生する可能性がありますので、確認が必要です。

た電子署名を検証することによって認証します。このため、ネットワーク方式とは異なり、

DKIM を受信側に導入する場合には、メール

メールの配送経路に影響を受けないという大サーバに対して、電子署名を検証し、認証処きな利点があります。その反面、メールの送理を行う機能の追加が必要になります。

信側にも電子署名を作成して添付する負担が生じます。
ここでは、DKIM の導入手順のほか、運用上課題となる点について解説します。

この受信側の認証機能も OpenDKIM プロ
ジェクトで提供されています。商用のメール
サーバやメールサービスを利用している場合
で導入を検討している場合には、提供元に確認が必要です。送信側への導入と同様に、新4.2.2.1 DKIM の導入手順

たに費用が発生する可能性がありますので、確認が必要です。

DKIM を送信側に導入するためには、メールの送信時に電子署名を作成し、それをメー
ルヘッダ(DKIM-Signature) として追加する機能が必要になります。
SPF/SenderID と同様に、オープンソース

51

第４章

送信ドメイン認証技術導入手順

図表４ー１０ メール転送への対応の例

4.2.2.2 鍵の管理と運用利用してメール受信側に渡されますので、ある時期を境に鍵ペアを変更しても、 DNS のDKIM の電子署名を作成するために必要な伝播の問題で正しい鍵の組み合わせにならな

秘密鍵は、外部に漏れないようにきちんと管い可能性があることに注意が必要です。この理しなければなりません。秘密鍵がわかって点については、DKIM では、3.4.2 で解説した

しまうと、認証に成功する DKIM の電子署名

ように、同一ドメイン上に、セレクタを利用

を第三者が勝手に作成できてしまうことにな

して複数の鍵を DNS 上に同時に公開するこり、そのドメインに対する認証の意味がなくとができますので、この仕組みを利用し、セなってしまいます。

レクタ値と、それが指し示す公開鍵に対応した秘密鍵を切り替えることにより、電子署名

また、DKIM で利用する鍵のペアは、セキの作成に利用する鍵を見かけ上瞬時に切り替ュリティ上の観点から、定期的に変更するこえることができます。以下に、鍵を切り替えとが望ましいとされています。鍵のペアの変る手順を示します。

更にあたっては、公開鍵は、DNS の仕組みを

52

第４章

図表４－１１

送信ドメイン認証技術導入手順

鍵の切替え手順

新たに利用するセレクタ名は、予め取得でき

4.2.2.3 課題と対策ないように、なるべく予測しづらい名称 (例
えば、番号や続きが連想される名称は避ける)

DKIM では、メール本体の電子署名の対象を利用すると良いでしょう。予め公開鍵がわとなっている部分が改変されない限り、認証

かると、解読のための時間が増えることになが失敗することはありません。逆にいえば、り、危険性も増すおそれがあるからです。まSubject ヘッダやメール本文にフッタ情報な

た、特別な事情がない限り、古いセレクタ名

どを追加するようなメーリングリスト機能で(鍵ペア) に戻すことはせずに、常に新しいセは、リストメンバでのメール受信時に認証がレクタを用意し続けるべきです。

失敗する可能性があります。このような場合

このセレクタの仕組みをうまく活用すれば、には、メーリングリスト側で投稿者からのメ

例えば、ハッシュ長が短い SHA-1 を利用してールを受け取るときに認証を行い、その結果いる場合でも、頻繁に鍵を変更していくことも含めて DKIM で再署名するなどの対応がによって、ある程度のセキュリティを保つこ必要になります。

とができます。これにより、送受信側ともに、
電子署名の作成・検証に必要となる処理能力

DKIM の課題として、もっとも難しいもの

を抑えることもできます。しかし、絶対に詐は、電子署名のポリシーの問題です。DKIM で称されては困るような大事なメールには

は、認証の対象となるのは、正確には、送信

SHA-1 は利用すべきではありませんし、新た者情報ではなく、署名者の情報になります。

な攻撃手段が開発されて、より脆弱性が高ま

つまり、電子署名がないメール（署名者の情った場合にも利用すべきではありません。

報がないメール）に対しては、認証が全くで

53

第４章

送信ドメイン認証技術導入手順

きないことになります。その結果として、受4.3 運用け取ったメールがたまたま電子署名の対象としていないメールだったのか、誰かが詐称し送信ドメイン認証技術を導入後にも、その効て送ってきたメールなのかの判断ができない果を維持するために、日々正しく運用することことになります。この点は、メールにもともが必要です。メールシステムの管理者は、受信と備わっている送信者情報を利用する側に必要とされるメールを正しく送信すること

SPF/SenderID と DKIM の大きな違いの１により、そのドメインの信頼性を高めていくこつです。

とができます。また、送信ドメイン認証技術でこの問題に対応するため、DKIM には、3.4.6

は、メールサーバだけでなく DNS も重要な役で解説した DKIM ADSP の仕組みが追加され割になっていますので、DNS が正しく機能するました。送信側で ADSP を表明することにより、ような運用が必要になってきます。

送信する全てのメールに電子署名が添付されているはずなのか (dkim=all) 、一部だけなのか

4.3.1 メールサーバの運用（dkim=unknown)を送信側が示すことができます。

送信ドメイン認証技術は、送信者情報が詐称

しかし、この対応策については、まだ問題がされているかどうかを認証する技術ですが、認残っています。3.4.6.2 で解説したとおり、ADSP

証されたドメインが、必要なメールを送信してを表明するのは、From ヘッダ上のメールアド

いるドメインなのか、迷惑メールを送信するドレスのドメイン名のサブドメインですので、メメインなのかまでは判断しません。

ール配信を請け負う事業者が、顧客のドメイン

そのため、受信側での迷惑メール対策としてを From ヘッダに利用し、実際の電子署名の作は、送信ドメイン認証技術による認証に加え、成を事業者側が行うような、いわゆる第三者署

ドメイン自体を評価する仕組みが別途必要にな

名をどう認証するのか、が問題となります。まります。

た、同様のケースとして、メーリングリストの問題もあります。

また、送信側では、送信ドメイン認証技術を導入しても、そのメールサーバから実際に

DKIM は、ドメインを自ら管理し、そのドメ

迷惑メールが送信されてしまえば、ドメイン

インを送信者情報及び署名者情報として使う場の信用は低下してしまいます。そのため、せ合には、とてもうまく機能しますが、メールのっかく送信ドメイン認証技術を導入したにも利用形態は多様化していますので、それぞれのかかわらず、評判の悪いドメインだと判断さ使い方にうまく適合させるための工夫も必要にれないように、関係のない第三者が勝手にメなってきています。現在もこうした議論は続いールサーバを利用できないようにきちんと設ておりますので、こうした問題をうまく解決し、定し、管理することが必要になります。例え適合できるようになることが期待されます。

ば、SMTP-AUTH のパスワードに安易な文字列を設定できないようにしたり、自らのメールサーバを利用するメール送信者の PC に
不正プログラム (マルウェア) が混入されて

54

第４章

送信ドメイン認証技術導入手順

パスワードが漏洩しないようにしたりという刻な問題となる可能性があります。 3.2.4.3

対策を講じなければなりません。また、業務で解説したとおり、SPF や Sender ID での的なものを除いて短時間で大量にメールが送

SPF レコードの記述方法で、DNS の参照回

信されていないか、短時間で地理的に離れた数に上限が決められているのも、受信側での場所からメール送信されていないかなどの監認証時の処理を軽減させる意味が含まれてい視等も必要になる場合もあります。

ます。

4.3.2 DNS の運用

送信側のドメインの管理元は、DNS の状態を監視したり、きちんと運用体制が整ってい送信ドメイン認証技術では、送信側から受る外部のサービスプロバイダを利用したりす

信側へ伝える、認証に必要な各種情報を DNSるなど、 DNS の維持管理を心がけるべきでを利用して受け渡しします。そのため、メーす。

ルの送信側ドメインの DNS が常に正しく動作していることが必要です。
4.3.2.1 DNS の状態監視

4.3.2.2 DNS の TTL

DNS では、問合せを高速に処理するために、
キャッシュの仕組みがあります。このキャッ送信側の DNS に何らかの問題があり、受シュの仕組みとその TTL は、SPF レコード

信側で、SPF レコードや DKIM の公開鍵のや DKIM の公開鍵の変更時の伝播時間と密情報が取得できなかった場合には、認証結果

接な関係があります。TTL の値を大きくする

は temperror (一時的な失敗) となり、正しくことで、送信側ドメインの DNS へのアクセ

認証できません。認証結果の temperror を受

ス回数を少なくする ことができますが、一方信側でどのように扱うかにもよりますが、送で SPF レコードや DKIM の公開鍵や DSP

信側で送信ドメイン認証技術に関する情報をレコードを変更した場合に、受信側のメール

正しく設定していたとしても、利用しているサーバに反映されるまでに時間が長くなって

DNS が不安定だったり、何らかの問題があっしまいます。

て正しく情報が引き出せない状態にあったり送信側のドメインで、これら DNS 上の情

すると、場合によっては受信側で受け取って報を変更する場合には、予め利用しているもらえないことになり、送信ドメイン認証技

DNS の TTL 値を把握したうえで、その時間術を導入していない場合よりも悪い結果となに合わせて十分情報が伝播した後に、システる可能性もあります。

ムの変更や鍵の変更をする必要があります。

また、送信側の DNS からの応答が遅かっ

DNS の TTL 値の変更が可能な場合には、前たり、応答を返さないなど不安定な状態にあ

もって TTL 値を短い時間に設定しておくと、ったりする場合には、受信側での認証処理に変更作業までの時間を短くすることができま

負荷がかかる原因になります。特に、大量のす。

メールを受けているメールの受信者には、深

55

第5章

ISP での対応

第 5 章 ISP での対応

本章では、ISP が送信ドメイン認証技術

す。受信したメールは、メールアドレスごを導入する場合に考慮すべき事項についてとにメールスプールに格納されます。メー

解説します。

ルスプール上の受信メールは、顧客が MUAISP が運用するメールシステムは、2.1

や、ウェブメール機能を提供している場合で解説したような構成となっており、提供

はウェブブラウザなどを利用して閲覧しま

するサービスの規模にもよりますが、概ねす。

メールの送信側と受信側でそれぞれのメー
ルの流れがあります。ここでは、送信ドメ

ISP はドメインを管理している場合が多イン認証技術の導入に際し、ISP として、

いので、SPF レコードの設定や DKIM のメールの送信側及び受信側のそれぞれで行

公開鍵の設定など、DNS 上に必要となる作

うべき作業や検討すべき事項について解説

業を自社で行えるため、送信ドメイン認証

します。

技術の導入が比較的容易であるといえます。
また、メールスプールも管理していますの

5.1 ISP のメールサービスの概要

で、例えば送信ドメイン認証技術で認証が失敗したメールを通常閲覧できる領域と別

58

ISP のメールサービスは、ISP が管理すの場所に保管したり、認証が成功した特定

る固定的なドメイン名を用いたメールアドのドメインからのメールを優先的に受信さレスを顧客に提供し、インターネットへのせるなど、フィルタサービスの機能拡充にメールの送信と顧客宛のメールを受信しま

応用することも可能です。

第5章

5.2 送信側の対応

ISP での対応するためには、メールに利用しているドメ
インについて、3.2.4 で解説した SPF レコ

5.2.1 概要ードの記述が必要です。

ISP が送信するメールは、一般の企業やSPF レコードには、メールの出口である

各種組織のドメイン名を利用して送信されホストのグローバル IP アドレスが含まれるメールに比べて、その規模が大きかった

るような、ネットワークアドレスや IP ア

り、利用目的が多様であることにより様々

ドレス、ドメイン名などを記述します。こな種類のメールが送受信される、という特れらの出口には、通常の送信用のホスト以

徴があります。送信ドメイン認証技術を送外に、例えば、受信側が一時的に受け取ら

信側で導入し、ISP を経由しない詐称されなかった場合に移される再配送用のホストたメールを区別できるようにすることは、や、メールサービスで利用しているドメイ

ISP のドメイン名の信頼度を向上させるたン名を使った顧客向けの連絡用の送信用メめに非常に重要です。

ールサーバなども含める必要があります。

送信ドメイン認証技術は、送信者情報が5.2.2.1.1 サブドメイン利用時の注意

偽装されているかどうかを確認可能とする技術なので、送信側で送信ドメイン認証技

メールサービスに、複数のドメイン名が術を導入することにより、迷惑メールの多利用できるようになっている場合には、そい ISP のドメイン名が、逆に迷惑メールのれぞれのドメインについて SPF レコード

送信元として判断されてしまう可能性もあを記述する必要があります。

ります。ISP から日々大量に送信されるメ

また、複数のドメイン名を利用しているールの中に、メールの受信者にとって迷惑場合で、それぞれがサブドメインの構成とメールとなるようなメールが含まれていな

なっており、それらの親ドメインをメール

いか、それらが誰から送信されているのか

サービスに利用していないときは、注意がを管理することも重要です。自社のドメイ必要です。SPF レコードが記述されていなン名に対して迷惑メールを送信するドメイ

いドメイン名は、詐称されても受信側で判ンとしての評判が下がらないように、何ら定できませんので、よく目にするドメイン

かの監視等の管理が必要です。

名の認証結果が fail / softfail などの認証失
敗でない場合には、誤解を与えてしまう可5.2.2 送信ドメイン認証技術の導入能性がありますので、3.2.3 と 4.1.2.2 で解説したとおり、以下のように、メールに利5.2.2.1 SPF/Sender ID の導入

用しない親ドメインの場合は、明示的にす
べて認証が失敗するような SPF レコード

ネットワーク方式の送信ドメイン認証技を宣言した方が良いでしょう。

術である SPF / Sender ID を送信側で導入

59

第5章

ISP での対応

example.jp
TXT "v=spf1 -all"apple.example.jp TXT "v=spf1 +ip4:192.168.0.4 -all"peach.example.jp TXT "v=spf1 +ip4:192.168.0.4 -all"mango.example.jp TXT "v=spf1 +ip4:192.168.0.4 -all"

図表５－１

サブドメインがある場合の SPF レコードの例

5.2.2.1.2 転送処理

あれば、受け取ることは可能になります。
SPF の場合は、送信者情報としてリバー60

一度受信したメールを、あらかじめ設定

スパス を利用しますので、 4.2.1.2 で解説された別のメールアドレスへ送信する転送

したとおり、転送時に送信元の情報を利用

機能は、古くから提供されてきた機能の一するのではなく、転送者のメールアドレス

つですが、 4.2.1.2 で解説したとおり、ネを設定し直すことによりこの問題は回避でットワーク方式の送信ドメイン認証技術ときます。ただし、単純にリバースパスを書の相性は良くありません。すなわち、現在き換えてしまうと、転送先で受け取れなか

提供されている多くの転送機能は、転送時った場合やエラーメールなどが、ループしのリバースパスに元々の送信者のリバースてしまう可能性があります。そのため、転パス情報をそのまま使いますので、転送先送時に書き換えるメールアドレスは、ローでの SPF の認証は失敗してしまいます。

カルパート部分に何らかの印となるような転送設定は、メールの利用者がそれぞれ文字列を別途挿入し、通常の受信メールと設定しますし、転送先のメール利用者は転

転送メールの戻りメールとを区別できるよ

送者と同一であることが一般的です。そのうな工夫も考えられます。通常の受信メーため、転送先のメール受信設定で、転送元

ルは転送し、転送したメールが戻ってきたからのメールが SPF の認証が失敗しても場合には、そのまま転送せずに利用者のメ受け取るようなフィルタ等の設定が可能でールボックスに格納するなどです。

第5章

図表５－２

ISP での対応

転送時の処理の例

転送先のメールシステムが Sender ID

たびに行います。そのため、これまでのメで認証している場合も、単純に受信したメール送信時より負荷が高くなることが予想

ールを転送したときには、認証が失敗しまされますので、導入時にある程度設備に余す。転送時には、転送者のメールアドレス

裕があるかどうかを確認する必要がありまを Resent-From ヘッダに記述することで、す。設備負荷は、電子署名の作成に利用す

転送先の Sender ID の認証時に送信者情るアルゴリズムとも関連しますので、それ報として認識されることになります。メーとも合わせて検討が必要です。

ル形式を定義する規格である RFC5322
では、転送のような再送信されるメールに

次に、どのメールに対して電子署名を行ついては、Resent-From ヘッダなどのうかの判断については、送信者情報が偽装

Resent- ヘッダを追加すべきと示されていされていないかを確認するという送信ドメます。

イン認証技術の目的を考えると、基本的にはすべての送信メールを対象に電子署名を

5.2.2.2 DKIM の導入

付与することが望ましいでしょう。自 ISP

DKIM は、送信するメールそれぞれに電宛に送信するメールなど、送信者が明確に子署名を追加して送信元を明らかにします。

判断できるような場合もありますが、その3.4.3 で解説したとおり、電子署名は、メー

メールが転送されて外のメールシステムにル本文（ヘッダとメール本文の内容）のハ

届くような場合も考える必要があります。

ッシュ値の計算、公開鍵暗号技術による電子署名の作成という処理を、メール送信の

61

第5章

ISP での対応

5.2.3 迷惑メールの管理者に通知できない場合に問題となる可能性がありますので、利用者のサポートは十分

多くのユーザが利用する ISP のメールに行う必要があります。また、送信側にもサービスでは、自身のドメイン名の評判を

フィルタを導入することで新たな費用が発下げないような運用を心がける必要があり生する可能性もありますので、費用対効果ます。

なども含めて検討する必要があります。

例えば、迷惑メールが自社のメールサー
バを経由して送信されていた場合には、そ

5.2.3.2 送信者の特定とその対策手順の確立の迷惑メールの受信側からの申告により、ブラックリストに登録され、以降そのブラ

迷惑メールが ISP のメールサーバからックリストを利用しているメール受信側に送信される可能性を完全に排除することは通常のメールも含めた全ての届かなくなっ

困難ですので、問題を大きくしないためにてしまうことが考えられます。近年の迷惑も、仮に迷惑メールが送信されても、受信

メールの増加傾向により、こういった迷惑者からの連絡があった場合などには、そのメール対策を行うメール受信者は増えてい迷惑メールを誰が実際に送信したのかを判ますし、送信ドメイン認証技術の普及によ断する仕組みが重要になります。

りドメイン名による受信制御が行われることが予想されます。
そのための対策としては、以下の事項が考えられます。

送信者を特定するには、メール送信時に送信者の認証を ID とパスワードによって行う SMTP-AUTH を導入し、メールヘッ
ダやメール送信ログに、その AUTH ID を

5.2.3.1

送信側の迷惑メール対策

記録するなどして、誰が実際に送信したかを調べる方法があります。最近では、不正迷惑メールの送信元となる ISP と判断プログラム (マルウェア) に感染して、利用されないためには、そもそも迷惑メールが者が知らない間に外部から制御されて迷惑

外部に送信されないような仕組みがあればメールを送信することが問題となっており、良いことになります。現在、多くの ISP で

SMTP-AUTH にも対応したマルウェアがはメール受信時に迷惑メールかどうかを判現れているのではないかともいわれていま定する迷惑メールフィルタを提供しています。そのため、AUTH ID を利用して迷惑メす。こういったフィルタがメールの内容かール送信者を特定し、利用者への通知及びら判断するタイプのものであれば、それを解決のためのサポートを行うことは、顧客送信時にも適用し、迷惑メールを送信しよ保護の意味でも重要になってきます。また、

うとしている場合に保留することによって、

迷惑メールの大量送信を抑制するために、外部への送信を抑制することができます。

AUTH ID 単位で、一定時間内に送信できる

しかし、迷惑メール判定には誤判定が発生しますし、送信されなかったことが送信

62

メール数を制限する方法があります。

第5章

ISP での対応

5.2.3.3 送信者情報を変更できないような仕組

送信者情報のドメインと異なるようなこと

みがある場合は、同様に何らかの対策が必要になります。
送信ドメイン認証技術で送信者情報として使われるのは、リバースパスと From ヘ

5.2.3.4 エラーメール処理

ッダアドレスのドメイン部分となります。
受信側で送信ドメイン認証が失敗しないた

受信したメールが宛先不明で配送できな

めには、これらが正しい情報となっている

かった場合は、メールの送信者にエラーメ必要がありますので、顧客からメールが投ールを送信する必要があります。エラーメ

稿された場合に、これらの情報が認証失敗

ールは、リバースパスに指定されたメール

するものになっていないかどうかを、配送アドレスに送信されます。迷惑メールの多前に確認すると良いでしょう。

くは、このリバースパスを詐称する場合が多いので、結果として不要なエラーメール

メール投稿時に指定されたこれらの情報が、あらかじめ送信ドメイン認証に失敗することが分かった場合に、ISP が取りうる
対応方法の例を以下に示します。

がメールアドレスを詐称された側に大量に送信されることになります。
ISP では、決まったドメインを使ってメールサービスを提供しますので、詐称に使われる可能性が比較的高いドメイン名であ(a) メールの投稿そのものを受け付けない(エラー応答する)(b) リバースパスの場合、ISP のドメイン
名のメールアドレスに付け替える(c) From ヘッダアドレスの場合、Sender

る一方、不特定多数にサービスを提供していることもあり、宛先不明となる迷惑メー
ルも多く、結果として不要なエラーメールを多数送信している可能性もあります。こ
うした不要なエラーメールを抑制するため

ヘッダなどに ISP のドメイン名のメーには、次の対策があります。

ルアドレスを追加する(a) メールの受信時点で宛先が存在するかを確認して存在しない場合は受け取らな

これまで、多くのメールサービスでは、

いこれら送信者情報の指定方法については比(b) 受信時に送信ドメイン認証技術で認証

較的緩やかな運用をしていました。そのたが失敗した場合にエラーメールを送信しめ、このような対応を急激に行うと、利用ない者にとって混乱の原因になりかねませんので、事前の周知が重要になります。

(a) の対策のために、メールの受信時に、宛先が存在するかを確認するには、顧客管

また、DKIM の場合も From ヘッダアド理を行っているシステム (データベースなレスのドメイン名とは無関係ではありませど) とリアルタイムで問合せできることがんので、DKIM-Signature ヘッダに示される必要です。メールシステムの構成として、

63

第5章

ISP での対応

メールスプールが存在するかどうかで宛先の SMTP 処理を継続しない、という方法

不明かどうかを MTA ではなく、MDA が判があります。

断している場合には、システムの変更が必
要になります。また、メール受信時に宛先

宛先不明時にエラーメールを返す送信先

不明かどうかを SMTP 上の応答として返は、詐称されていない実際の送信元です。

すことになりますので、送信側でその応答そのため、送信ドメイン認証技術で認証がを確認することにより、実在するメールア

失敗した送信先、例えば SPF / Sender ID

ドレスかどうかを簡単に調べることができで認証結果が fail / softfail となった送信元てしまいます。よく使われるローカルパー

や、DKIM で認証が失敗した場合や、ADSP

トの文字列を総当たり的に指定して実在す

で fail/discard であったような送信元には、るメールアドレスを取得する攻撃は、辞書

エラーメールを送信する必要はありません。

攻撃 (DHA: Directory Harvesting Attack)このため、(b) の対策を実施することも考えと呼ばれます。これを防ぐためには、一定られます。

数以上の宛先不明が発生した場合に、以後

64

第5章

5.3 メール受信側としての検討

5.3.1 概要

ISP での対応

5.3.3 メールの配送制御

改めての説明になりますが、送信ドメイン認証技術は、あくまでも「特定の送信元

第３章で解説したとおり、送信ドメインから確かに送信されたかどうか」を機械的認証技術を用いることにより、メールの受に判断するための技術であり、認証結果と信側が認証を行うことで、そのメールが本

メールのコンテンツは何の関係もないもの

当にそのドメインから発信されたかどうかです。ISP では多様な利用者にサービスをを判定することができます。送信ドメイン

提供するという性質上、送信ドメイン認証

認証技術は、送信側の対応も必須ではあり技術での認証結果の取り扱いについては、

ますが、受信側が対応を進めることは送信

特に慎重になるべきです。

側の導入モチベーションにも繋がるものです。そのため、送信ドメイン認証技術の普5.3.3.1 配送前制御に関する注意

及に向けてのよいサイクルを生むためにも、ISP では積極的に受信時の認証およびラベ

送信ドメイン認証技術による認証結果をリングを行うべきであり、受信したメール利用した受信側のアクションで特に注意すを適切に取り扱う努力を行っていることを、べきなのが、認証結果による配送方法の取利用者・送信者へアピールしていくことが扱いです。4.1.3 で解説したとおり、送信ド望まれます。

メイン認証技術では、受信者の意図しない
メーリングリスト経由での再配送や送信時

5.3.2 利用する送信ドメイン認証技術の選定

ポリシーの記述ミスなどによって認証が失敗する場合もあります。特に、ISP ではさ

受信時に利用する送信ドメイン認証技術

まざまな受信者による利用シーンが考えらを選定する場合には、4.1.1 を参考にします。

れるため、送信ドメイン認証技術による認送信ドメイン認証技術を複数導入すれば、証結果だけを利用して、一律にメールの受ドメインの正当性の判断に利用できる情報信を拒否したり破棄したりする取り扱いをは増えますが、認証のために必要な追加コ

してはなりません。ただし、以下の場合にストが増加する場合があります。特に ISP

はこの限りではありません。

の場合、取り扱うメールの通数が一般的な(a) 受信設備の高負荷による緊急避難など企業に比べ多くなりますので、機能を追加する設備の規模も大きくなると考えられま

限定的対応の場合(b) エンドユーザからの個別の同意があるす。現状のネットワーク構成やハードウェ

場合

アを考慮しながら、段階的に送信ドメイン(b) による場合には、エンドユーザに対し認証技術を導入していくことが現実的でしてリスクについて十分な説明を行うとともょう。

に、簡易に機能を解除させたり、個別に回

65

第5章

ISP での対応避できるような機能を設けるなどの機能的ができる権利もしくは機能を持つタイプの配慮もした上で、個別に同意を取って提供

ものでなければなりません。

しなければなりません 。
5.3.3.4 認証結果の可視化による利用者のユー
5.3.3.3 ホワイトリストやドメインレピュテー

ザビリティ向上

ションの活用利用者が認識できるように認証結果の表
4.1.4.3 で示したとおり、送信ドメイン認示を行うためには、Web ブラウザ経由や証の結果と、ISP が事前に用意したホワイ

MUA 経由など、表示領域を任意に制御できトリストやドメインの評判（ドメインレピ

るような環境でメールを閲覧する必要があュテーション）情報と照合することもできります。

ます。照合結果によって、メールに特別な一部の ISP では Web ブラウザ上でメマークを付与したり、迷惑メール判定を実ールを利用できるサービスを提供していま施せずにフィルタを通過させたりするなど

すが、このような環境の場合、画面インタの活用方法が考えられます。また、サービーフェース中に認証に利用したドメイン名

スの利用者が個別にドメインを設定するこや認証結果、ホワイトリストなどとの照合とにより、Web ブラウザや MUA 上でのフ

結果を分かりやすく表示させることが可能

ォルダ振分けなどに利用できるようにするです。一方 MUA ではこのような画面表示

サービス形態も考えられます。

に標準的に対応しているクライアントはま

ISP が他組織により提供されるホワイト

66

だほとんど存在していません。

リストやレピュテーション情報を利用する

送信ドメイン認証結果を分かりやすく表場合は、自組織のポリシーと一致しないこ示するアプリケーション環境が整い、利用とも十分に考えられるので注意が必要です。

者が積極的に利用できるよう、ISP としてそのため、これらホワイトリストやレピュ可能な取り組みを推進することが好ましい

テーション情報は、自組織でコントロールといえます。

第5章

5.4 ユーザ周知

ISP での対応

受信側の対応については、どの技術を採用しているかを説明する必要があります。

送信ドメイン認証を導入する場合には、導認証結果をラベリングとして記述する場合

入した結果として発生する影響について、ユには、ラベリングの確認方法を、代表的なメーザに周知する必要があります。周知の方法

ールクライアントの設定方法について説明すは、メールや郵便物で行う方法もありますが、ることが推奨されます。また、フィルタサー

最低限ホームページでの周知は実施するべきビスを提供する場合には、該当のサービスのです。

利用方法に加えて、利用した場合の影響につなお、ユーザへの周知内容は、各社の対応

いて説明することが必要です。特に、ユーザ

内容によっても異なりますが、ユーザは送信にはドメイン詐称に対する認識が少ないため、ドメイン認証という技術の理解をすることがどのような送信方法のメールがフィルタリン

困難な場合も多いと想定されるため、表現方

グされるかを図解なども用いて説明すること

法や影響をよりわかりやすくする工夫が必要が推奨されます。

です。特に、「送信ドメイン認証技術」という表現にこだわらず、ユーザの理解を得られる
表現を使うことも重要です。
5.4.1 送信側の対応

ユーザによるメールの利用方法により認証が失敗してしまう場合として、送信側では、ユーザが自社のサーバ（MSA）経由で送信ア
ドレスを該当ドメイン以外で送信した場合と、ユーザが自社のサーバ以外のサーバから該当ドメインのメールを送信したケースの２つがあります。後者については、自社の管理外の問題であるため、ユーザに対して必ずしも説明する必要はないとも思えますが、前者と合わせて説明することが望ましいものです。
また、送信側の対応について、導入した技術と期待される効果を説明することが推奨されます。
5.4.2 受信側の対応

67

第6章

ホスティングサービスでの対応

第 6 章 ホスティングサービスでの対応

本章では、送信ドメイン認証技術を適用す

分類できます。

る際に、メールホスティングサービスを提供する事業者特有の対応方法、課題、解説など

6.1.1 メールサーバによる分類を示します。
サービス提供方法の違い、DNS サーバの管

メールホスティングサービスは、メールサ

理の違いによるホスティングサービスの分類

ーバの割当てにより、「サーバ専用型」、「サーについて、メールサービスに関連する DNS

バ共用型」、「ゲートウェイ型」の 3 つに分類

サーバについて、送信側・受信側の対応方法できます。

などについて、以下で解説します。
6.1.1.1 サーバ専用型
6.1 ホスティングサービスの分類

サーバ専用型は、１つの契約ドメイン（企メールホスティングサービスとは、通信事業）に対して、１つ又は１つの集合体のメー業者や ISP・ASP 事業者（以下「ホスティン

ルサーバを「専用」で割り当てる形でメール

グ事業者」といいます。
）が、自社設備を用い送受信機能を提供するサービス形態です（図て、主に企業などにメール機能を提供するサ

表６－１）
。

ービスです。このメールホスティングサービ

割り当てられたメールサーバから送信されスは、メールサーバの割当てや DNS サーバ

るメールは、すべて１つの契約ドメイン（企の管理の状況により、それぞれ以下のように業）からのメールに限られます。

図表６－１

70

サーバ専用型のホスティング事業者の例

第6章

6.1.1.2 サーバ共用型

ホスティングサービスでの対応

表６－２）。
専用型とは異なり、割り当てられたメール

サーバ共用型は、複数の契約ドメイン（企サーバから送信されるメールには、共用して業）に対して、１つ又は１つの集合体のメーいる他社ドメインからのメールも混在するこ

ルサーバを「共用」で割り当てる形でメールとになります。

送受信機能を提供するサービス形態です（図図表６－２

サーバ共用型のホスティング事業者の例

6.1.1.3 ゲートウェイ型

MX サーバのみ提供し、メールデータを蓄積するメールボックス機能や投稿サーバなどの機

ゲートウェイ型は、契約ドメイン（企業）

能は提供しません。反対に、ゲートウェイ型に対して、MX サーバやフィルタリングサーのうち送信メールサーバの場合、契約企業のバ、投稿サーバを割り当てる形で、主に迷惑メールサーバが設定するリレー先サーバ（あメール対策機能やウイルス対策機能、監査機

るいは投稿サーバ）を提供し、MX サーバは能などを提供するサービス形態です（図表６

提供しません。

－３、図表６－４）。
ゲートウェイ型のうち受信メールサーバの場合、ホスティング事業者はゲートウェイ用71

第 6 章 ホスティングサービスでの対応

72

図表６－３

ゲートウェイ型のホスティング事業者の例（受信）図表６－４ゲートウェイ型のホスティング事業者の例（受信）第6章

6.1.2 DNS サーバによる分類

ホスティングサービスでの対応

DNS ホスティング型は、契約企業ドメインの DNS サーバを、ホスティング事業者側がメールホスティングサービスは、DNS サー

代行して管理する形態です。ホスティング事

バの管理により、「DNS 自社管理型」、「DNS

業者は、契約企業のメールサーバとともにホスティング型」、「DNS 提供型」の 3 つに分

DNS サーバの管理も行います。

類できます。
6.1.2.3 DNS 提供型
6.1.2.1 DNS 自社管理型

DNS 提供型は、契約企業ドメインの DNS
DNS 自社管理型は、契約企業ドメインのサーバのみをホスティング事業者が代行してDNS サーバを、契約企業自身で管理する形態

管理する形態です。ホスティング事業者は、です。ホスティング事業者は、契約企業のメ契約企業の DNS サーバは管理しますが、メールサーバは管理しますが、DNS サーバの管ールサーバの管理は行いません。

理（MX レコードや TXT レコードの登録・更新・削除）は行いません。

この場合には、DNS 自社管理型とも異なり、契約企業、メールサーバのみを管理するホス
ティング事業者、DNS サーバのみを管理する

6.1.2.2 DNS ホスティング型

ホスティング事業者の三者が登場します。

73

第 6 章 ホスティングサービスでの対応

6.2 送信側の対応

6.2.1.1 SPF/SenderID 利用の確認

ホスティング事業者は、契約企業が自社ド

ホ ス テ ィ ン グ 事 業 者 は 、 事 前 に SPF /メインを差出人としてメールを送信する際に、Sender ID を利用することのメリットやデメ

SPF / Sender ID 及び DKIM に適合したメー

リットを契約企業へ説明し、利用の確認を行

ル送信環境を準備しなければなりません。

わなければなりません。

以下、 SPF / Sender ID の対応、 DKIM の対応について解説します。

例えば、4.1.3.4 で解説したとおり、契約企業が、登録したドメイン以外の差出人アドレ
スを用いてメール送信を利用している場合（図表６－５）には、SPF / Sender ID を利用

6.2.1 SPF / Sender ID の対応することで認証結果が fail / softfail になる可能
ホ ス テ ィ ン グ 事 業 者 が 送 信 側 で SPF /性があります。

Sender ID を導入する場合には、第４章で解説明内容については、第４章を参考にして、説した一般的な対応のほか、以下のような事

契約企業向けの説明資料を事前に準備するこ項についての対応を行わなければなりません。

とが推奨されます。

メール送信

example.net
192.0.2.0

host.example.com
192.0.2.20

MAIL: user@example.org
RCPT: user@example.net→

softfail / failexample.org がすでに SPF レコード(192.0.2.10)を登録していた場合，192.0.2.20 から送信された user@example.org からのメールは認証失敗(softfail / fail)となる．

図表６－５

example.org
192.0.2.10

自社ドメイン以外のメール送信の例

6.2.1.2 SPF レコード登録に必要な情報の通知元となる IP アドレスなどの必要な情報を契約企業へ通知することが必要です。また、ホスDNS 自社管理型の場合には、SPF レコー

ティング事業者は、契約企業に対しドの登録作業を契約企業自身が行わなければて、”redirect” で呼び出せるドメインなどを通なりません。

知することが推奨されます（図表６－６）。送

この場合に、ホスティング事業者は、送信74

信元を IP アドレスで通知すると、IP アドレ

第6章

ホスティングサービスでの対応

スの追加・削除のたびに、それぞれの契約企知することにより、IP アドレスの追加・削除業に対して通知を行うことになりますがあっても、通知しなくてもすむことになるが、”redirect” で呼び出せるドメインなどを通ためです。

host.example.com
192.0.2.20
192.0.2.21 追加
SPF レコードは redirect 表記として，"v=spf1 redirect=spf.host.example.com"
を 契 約 企 業 へ 通 知 す る ． 送 信 元 に 192.0.2.21 が 追 加 さ れ た 場 合 は「spf.host.example.com」の SPF レコードを更新すればよい．

図表６－６

SPF レコード (redirect) の利用例

また、ホスティング事業者は、契約企業にできます。この場合には、契約企業側で認証対して、”redirect” ではなく ”include” を用い

結果の扱いをカスタマイズすることができまて送信側のメールサーバを指定させることもす。

特徴
redirect

契約ドメインに同一の SPF レコードを設定することができ、管理しやすい。

include各契約企業ごとに認証結果のポリシーを変更することができる。

※ redirect, include については、3.2.4.2 を参照

図表６－７

SPF レコード(redirect, include)の特徴

6.2.1.3 SPF レコード登録のサポート

契約企業側の管理者が SPF レコードの記述

ード登録をサポートすることが推奨されます。
6.2.1.4 サーバ共用型でのユーザ管理体制

方法に詳しくないことも考えられますので、
DNS 自社管理型の場合には、ホスティング事

サーバ共用型の場合には、ホスティング事

業者は、SP F レコードの記述方法の説明や契業者は、契約ドメインの送信状況を随時監視

約企業の要求に合った SPF レコードの作成しなければなりません。また、ホスティング

準備を行うことが推奨されます。また、事業者は、SPF / Sender ID の認証結果がAppendix 1 で紹介している記述例や間違えpass とならないメールの送信を禁止したり、の例を参考にして、契約企業側の SPF レコ

発信元 IP アドレスを分けるなどの対策をとる

75

第 6 章 ホスティングサービスでの対応れた契約ドメインの From ヘッダアドレスことが推奨されます。
これは、同一サーバに収容されているドメやリバースパスを騙って、正当なメールを送

インの SPF レコードも同一となりますので、信することができてしまうためです（図表６

悪意のあるユーザがいた場合に、同一収容さ

－８）
。

メール送信
From:user@bar.example.com

example.net
192.0.2.0

foo.example.com

To:user@example.net→

192.0.2.10

softfail / failfoo.example.com および bar.example.com はともに192.0.2.10 を送信元として SPF レコードを登録しているため、foo.example,com は bar.example.com を騙ってメール送

bar.example.com

信ができてしまう。

192.0.2.10

図表６－８

サーバ共用型でのなりすましメール例

また、サーバ共用型の場合では、同一サー

6.2.2.1 DKIM 利用の確認

バ（IP アドレス）に割り当てられた他社ドメ
インによって、SPF / Sender ID の認証結果がホスティング事業者は、SPF / Sender ID の

fail / softfail するメールを大量に送信されて場合と同様に、事前に DKIM を利用すること

しまい、その結果割り当てられたメールサーのメリットやデメリットを契約企業へ説明し、バが迷惑メールの送信元として認知されてし利用の確認を行わなければなりません。

まう危険性があるためです。すなわち、他社

例えば、契約企業が自社ドメイン以外の差

ドメインのメール送信が、無関係である自社

出人アドレスを用いてメール送信に利用してドメインの送信メールに影響を及ぼし、最悪いる場合には、電子署名を作成する際に利用の場合は送信メールの不達が生じるものです

したドメインと From ヘッダアドレスのド（お隣さん問題）。

メインが一致しない可能性があります。
具体的な説明内容については、第４章を参6.2.2 DKIM の対応考にして、契約企業向けの説明資料を事前に準備することが推奨されます。

ホスティング事業者が送信側で DKIM を導また、電子署名を作成する際に利用したド入する場合には、第４章で紹介した一般的なメインと From ヘッダアドレスのドメインの対応のほか、以下のような事項についての対違いによって、いくつかのサービス仕様が考応を行わなければなりません。

えられますので（図表６－９）、ホスティング
事業者は、契約企業の送信ポリシーと照らし合わせて実装を行うことが推奨されます。

76

第6章

ホスティングサービスでの対応

DKIM 利用方法

サービス仕様の例

1

すべての送信メールに電子署名を作成する方式

・From ヘッダアドレスが自社ドメインの場合は送信者署名とな
り、From ヘッダアドレスが自社ドメイン以外の場合は第三者署
名となる

2

自社ドメインのメールだけに電子書名を作成する方式・From ヘッダアドレスが自社ドメインの場合は送信者署名となりますが、From ヘッダアドレスが自社ドメイン以外の場合は、電子署名を作成しない
・どちらの場合もメール送信は許可する

3

自社ドメインのメールだけ送信を許可す
る方式

・From ヘッダアドレスが自社ドメインの場合は送信者署名となるが、From ヘッダアドレスが自社ドメイン以外の場合は、メール送信を許可しない

図表６－９

DKIM 利用方法とそのサービス仕様の例

6.2.2.2 公開鍵の通知

管理者が公開鍵レコードに詳しくないことが考えられますので、ホスティング事業者は、

DNS 自社管理型の場合には、公開鍵の登録

公開鍵レコードの記述方法の説明や公開鍵レ作業は契約企業が行うことが必要です。ホス

コードの作成準備を行うことが必要です。

ティング事業者は、公開鍵・セレクタなどの

また、DNS 提供型のように、メールサーバ

必要な情報を契約企業へ通知することが必要

をホスティングする事業者と DNS をホステです。電子署名の解読行為を防止するために、ィングする事業者が異なる場合には、公開鍵

定期的な公開鍵と秘密鍵の更新を行うことがと秘密鍵の管理方法が課題となります。ホス

推奨されますので、ホスティング事業者は、

ティング事業者は、ブラウザなどから操作で公開鍵と秘密鍵の更新のたびに、この手続をきる管理画面などを用意し、公開鍵と秘密鍵行うことが必要です。

の生成と、公開鍵のダウンロード機能を提供することが推奨されます（図表６－１０）。こ

6.2.2.3 公開鍵登録のサポートの機能を利用して、契約企業側の管理者は
DNS 提供事業者への公開鍵提供と公開鍵のDNS 自社管理型の場合には、契約企業側の登録をすることができます。

77

第 6 章 ホスティングサービスでの対応

ホスティング事業者
管理画面

メールサーバ(1)鍵生成(2)公開鍵 DL
公開鍵DNS 提供事業者

公開鍵

秘密鍵

(3)公開鍵の登録

利用者は、まずホスティング事業者の用意する管理画面で(1)鍵生成を行います。生成された秘密
鍵は電子署名を生成するメールサーバに保管されます。次に利用者は、管理画面より(2)公開鍵をダウンロードし、得られた公開鍵を DNS 提供事業者へ提供し(3)公開鍵の登録を行います。

図表６－１０78

ホスティング事業者の提供する公開鍵と秘密鍵の管理システムの例

第6章

6.3 受信側の対応

ホスティングサービスでは、ホスティング
事業者の設備で受信側の対応を行うことが必

ホスティングサービスでの対応ことが推奨されます。
6.3.1.2 契約企業への説明とメールクライアント側
へのフィルタリング指導

要です。第３章で紹介した一般的な対応のほか、以下のような事項についての対応を行うことが必要です。

契約企業に対して、契約ドメイン宛の受信
メールの判定結果及びフィルタリングによって得られる効果を報告します。ホスティング

6.3.1 認証結果の解説と利用方法の提示

事業者は、メールクライアント側で設定すべきフィルタリング条件の設定をサポートする

送信ドメイン認証技術による認証結果をとよいでしょう。

Authentication-Results ヘッダに記録する場
合には、契約企業に対して Authentication-Res

6.3.2 認証結果によるフィルタリング実施

ults ヘッダに関する説明を行い、必要であれ
ばメールクライアント側での適切なフィルタ
リングの指導を行うことが必要です。

メールクライアント側のフィルタリングでは、ホスティング事業者の設備コストは直ち

ホスティング事業者は、第３章を参考にしに効果がでるとはいえませんが、今後送信側た説明資料を準備することが推奨されます。

の対応が進むとエンドユーザ側での様々な活用が進むと予想されております。

6.3.1.1 判定結果の確認

ホスティング事業者は、メールの隔離、拒否、破棄などのサーバ側でのフィルタリング

契約企業にフィルタリングの指導をする準機能を準備することが推奨されます。サーバ

備として、該当ドメイン宛の受信メールのう側のフィルタリング機能を実装するにあたっ

ち、適切に送信ドメイン認証が実施された割ては、以下の点について考慮することが必要

合を調査します。受信メールの多くが fail /です。

softfail と判定されているドメインのうち、契約企業とやり取りをされている顧客が含まれ6.3.2.1 フィルタリング利用を選択できる機能の提る場合は、フィルタリングのホワイトリスト

供対象を講じることが考えられます。この場合には、該当するドメインをリスト化して、契特にサーバ共用型の場合には、フィルタリ

約企業に確認してもらうことが推奨されます。

ング機能を利用する契約企業と利用しない契受信メールの多くが neutral / none と判定

約企業が共存する場合が想定されますので、されている契約企業の場合は、フィルタリン

ホスティング事業者は、契約ドメインごとにグによる効果が低いため、この指導は見送る

フィルタリング設定の有効・無効を管理する

79

第 6 章 ホスティングサービスでの対応ことが必要です。
6.3.2.3 なりすましメールの措置を選択できる機能
6.3.2.2 ドメイン単位のホワイトリスト機能の提供の提供

6.3.2.1 で解説したとおり、送信元ドメイン

フィルタリング結果で送信者情報が偽装さによってはすべてのメールの送信元に対してれているメール（なりすましメール）である

送信ドメイン認証技術に対応していない場合と判定された場合には、それらのメールは何があります。言い換えれば、認証結果が fail /らかの措置（隔離、ラベリング、拒否等）がsoftfail であっても受信すべき送信元ドメイ

とられることが推奨されます。ホスティングンが存在することになります。このため、ホ事業者は、このような措置として複数の選択

スティング事業者は、各契約ドメインごとに、肢を用意し、契約企業にリスクと効果をかん

ホワイトリスト機能を提供し、必要なメール

がみて、設定してもらうことが推奨されます。

の不達を防ぐことが必要です。

ホスティング事業者の用意する措置としては、
以下のようなアクションが考えられます。
仕様

特徴

X ヘッダ又は Subject ヘッダなどになりす
ましと認識できる目印を記録する

・受信すべきメールの不達を防止することができるが、契約企業のユーザがメールクライアントでフィルタリング設定をする手間が生じる

隔離して受信ごみ箱や迷惑メールボックスなど、受信箱とは別の場所に受信する・受信すべきメールの不達を防止することができるが、隔離されていることで False Positive が発生した場合にユーザが受信を見落とす可能性がある
・ゲートウェイ型では提供できない

SMTP で拒否する

なりすましメールと判定された時点で、SMTP 応答で該当メールを拒否する

・なりすましメールが契約企業のユー
ザに着信しなくなるが、ホワイトリ
ストが適切に設定されていない場
合には、メール不達が生じる

NDR をメールサーバで破棄なりすましメールと判定されたメールのうち、NDR については SMTP レスポンスを正常応答したのち、メールサーバ内で破棄する・不要な NDR によるコストが軽減されるが、通常のメールについては他の施策と組み合わせて実装する必
要がある

ヘッダに目印を記録

図表６－１１80

なりすましメールの措置の例

第7章

配信サービスでの対応

81

第7章

配信サービスでの対応

7.1

本章では、配信サービスを利用してメー

配信サービスとはルを送信する送信者（配信サービス利用者。
以下この章で「利用者」といいます。）と、

配信サービスとは、電子メール配信のたクライアント組織に代わってメール送信すめの設備を備えた業者が当該設備を利用しる実際の配送者（配信サービス提供者。以下て、クライアント組織に代わってメールを

この章で「配信サービス」といいます。）が、配信するサービスを指します。

送信ドメイン認証を導入する上で、対応すべき事項を説明します。

利用者（送信者）

受信者

配信操作

メール受信

メール送信

メール受信

配送サービス（配送者）

受信プロバイダ

図表７－１

配信サービス

7.1.1 配信サービスと送信ドメイン認証技術

概要

ール（なりすましメール）であると勘違いされかねません。

メールの配信設備を保有していない組織

配信サービスは、配信するメールに送信が、配信サービスを利用して一般消費者やドメイン認証技術を導入することにより、顧客にメール配信する場合には、From ヘ

受信者に対して自ら配信したメールである

ッダアドレスにその組織のドメイン（利用者ことを証明することができます。

ドメイン）のメールアドレスを指定しながら、

今後、送信ドメイン認証技術が普及する

配信サービス環境から送信することになるとともに、ホワイトリストの普及が本格化ため、受信者から送信者情報を偽装したメする可能性があります。この場合、配信サービスは、送信ドメイン認証技術を施した

82

第7章

7.1.2

送信メールから迷惑メールを削減する努力

配信サービスでの対応

From ヘッダアドレスの管理主体を継続することで、結果として、自らのドメインの評判を上げることができます。

配信サービスを利用する際は、主に利用

配信サービスは、専門的な知識や技術を者の管理するドメインの From ヘッダアド

持たない利用者が送信ドメイン認証技術をレスで送信する場合と、配信サービスが管導入するための道を拓き、社会全体のなり理するドメインの From ヘッダアドレスですましメールや迷惑メールの削減に貢献で送信する場合があります。それぞれの場合きる立場にありますので、積極的に送信ドによって、送信ドメイン認証技術の利用時

メイン認証に対応することが望まれます。

の対応が異なりますので、導入する際には、あらかじめ From ヘッダアドレスの管理主体を確認しておくことが必要です。

利用者（送信者）

受信者

DNSサーバexample.net（２）SPFレコード問い合わせ
v=spf 1 ip4:192.0.2.1~all

DNSサーバ（SPFレコードを公開）（３）認証OK（１）メール送信
メールサーバ
IP：192.0.2.1

example.com
配送サービス（配送者）

図表７－２

reverse-path：error@example.com
FromTo：user@example.net：user@example.org

メールサーバexample.org
受信プロバイダ

SPF（From ヘッダアドレスのドメインが利用者管理の場合）

83

第7章

配信サービスでの対応

7.2 送信ドメイン認証技術の導入

Sender ID 認証は、PRA を用いて認証を
配信サービスから送信ドメイン認証技術行います。このため、メールヘッダにに対応したメールを送信する際に、配信サ

Sender を使用しているかいないかで対応

ービスと利用者が対応すべき事項は、以下内容が異なります。Sender は省略されるのとおりです。

ことが多いヘッダですが、メール作成者が複数存在する場合や、From ヘッダアドレ

7.2.1 SPF

スと実際の配送者が異なる場合に用いられます。From ヘッダアドレスに利用者ドメ

SPF は、送信するメールのリバースパス

インのメールアドレスを指定してメールをのドメインで認証します。配信サービスで配信する場合は、実際の配送者である配信

は、一般にエラーメール解析等のバウンス

サービスの情報を Sender に記載すること

メール処理のために、リバースパスには配ができます。

信サービスのドメインのメールアドレスが指定されます。この場合に、配信サービス

7.2.2.1

は、リバースパスで使用するドメインの合

メールヘッダに Sender を使用しない場

DNS に SPF レコードを公開することにな
ります。このとき、利用者が対応する事項

メールヘッダに Sender を使用しない場はありません。

合には、Sender ID での認証の対象は、PRAに基づき、From ヘッダアドレスとなりま

7.2.2 SenderIDす。

利用者（送信者）

受信者（２）FromドメインにSPF 問い合わせ
v=spf 1 ip4:192.0.2.1~all

DNSサーバ（SPFレコードを公開）

example.net（３）認証OK

DNSサーバ（１）メール送信
メールサーバ
IP：192.0.2.1

reverse-path： error@example.com
FromTo

example.com
配送サービス（配送者）

メールサーバ：user@example.net：user@example.org

example.org
受信プロバイダ

図表７－３ SenderID/Sender 使用せず
（From ヘッダアドレスのドメインが利用者管理の場合）

84

第7章

配信サービスでの対応

7.2.2.1.1 From ヘッダアドレスのドメインがることによって、同じ IP アドレスから送

利用者管理の場合信される他の利用者のメールが届きにくくなる可能性がありますので、注意が必要と

From ヘッダアドレスのドメインが利用なるものです。

者管理の場合には、利用者、配信サービスは、それぞれ、次の対応が必要です。

7.2.2.1.2 From ヘッダアドレスのドメインが配信サービス管理の場合(1) 利用者の対応
利用者は、利用者が管理するドメインのFrom ヘッダアドレスのドメインが配信
サービス管理の場合には、配信サービスで、DNS の SPF レコードに配信サービスの送

配信サービスが管理するドメインの DNS

信ドメイン情報を記載します。

の SPF レコードに配信サービスの送信ド
メイン情報を記載します。

(2) 配信サービスの対応
配信サービスは、送信時に利用者が指定

7.2.2.2

メールヘッダに Sender を使用する場合

する From ヘッダアドレスのドメインのSPF レコードに問い合わせ、正しい送信元

メールヘッダに Sender を使用する場合

情報が記載されていることを確認し、正しには、PRA に基づき、Sender ID の認証対

くない場合は警告を出す、送信しない等の象は Sender となります。Sender には、対応を行うことが推奨されます。

実際の配送者である配信サービスのドメイ

利用者が SPF レコードに配信サービスンを記載します。したがって、配信サービの送信ドメイン情報を誤って記載したこと

スは、Sender で使用するドメインの DNSにより、受信側の検証結果が fail になったの SPF レコードに、配信サービスの送信場合には、その検証結果が受信ブロックのドメイン情報を公開します。

原因となる可能性があり、この状況が継続す

利用者が対応する事項はありません。

85

第7章

配信サービスでの対応

利用者（送信者）

受信者

DNSサーバexample.net（２）SenderのドメインにSPF 問い合わせ
v=spf 1 ip4:192.0.2.1~all

DNSサーバ（SPFレコードを公開）（３）認証OK（１）メール送信
メールサーバ
IP：192.0.2.1

example.com

メールサーバ：sender@example.com：user@example.net：user@example.org

Sender
From
To

example.org

配送サービス（配送者）

受信プロバイダ

図表７－４ SenderID/Sender 使用（From ヘッダアドレスのドメインが利用者管理の場合）
7.2.3 DKIM

スは、あらかじめ From ヘッダアドレスの管理主体を確認しておく必要があります。

DKIM は、DKIM-signature ヘッダに記載
7.2.3.1

されたドメインで認証します。
DKIM は送信者署名を基本とし、From

From ヘッダアドレスのドメインが配信

サービス管理の場合

ヘッダアドレスのドメインが利用者管理であるか配信サービス管理であるかによって

From ヘッダアドレスのドメインが配信異なる対応が求められるため、配信サービ

サービス管理の場合には、配信サービスのドメインで電子署名を作成します。

利用者（送信者）

受信者（２）署名ドメイン(d=)のDNSに
公開鍵の問い合わせ

DNSサーバ
署名に使う公開鍵の公開（３）認証OK（１）メール送信（署名含む）

DKIM-Signature:d=example.com；・・・--From：user@example.com
To：user@example.org

メールサーバexample.com
配送サービス（配送者）

図７－５

86

メールサーバexample.org
受信プロバイダ

DKIM／配信サービスドメインによる署名

第7章

配信サービスでの対応(1) 配信サービスの対応
7.2.3.2

配信サービスは、From ヘッダアドレスに使用するドメインの DNS に公開鍵を設

From ヘッダアドレスのドメインが利用

者管理の場合置し、これに対応する秘密鍵で DKIM の電子署名を作成するソフトウェアを用意する

利用者が管理するドメインの From ヘッ

必要があります。

ダアドレスで配信する場合は、利用者自らが管理する DNS へ公開鍵を設置して、電(2) 利用者の対応

子署名を作成することが望まれます。

利用者が対応する事項はありません。
利用者（送信者）

受信者

DNSサーバ
署名に使う公開鍵の公開（２）署名ドメイン(d=)のDNSに
公開鍵の問い合わせexample.net（３）認証OK
DNSサーバ（１）メール送信（署名含む）

DKIM-Signature:d=example.net；・・・--From：user@example.net
To：user@example.org

メールサーバexample.com
配送サービス（配送者）

図７－６

メールサーバexample.org
受信プロバイダ

DKIM／利用者ドメインによる署名(1) 配信サービスの対応

メールを配信するために、配信サービスは、

配信サービスは、送信メールに DKIM 署

配信サービス側で秘密鍵と公開鍵を生成し名したい利用者の鍵の管理やドメインの管て利用者に公開鍵を提供する等、以下の機能

理を軽減するために、以下のような環境をを用意することが推奨されます。

提供することが推奨されます。
・(a) 鍵管理の支援

公開鍵ダウンロード機能
利用者がメールを送信する場合には、利DKIM を利用したい利用者の中には、用者の鍵管理の負担を軽減する為に、あらDNS の管理や鍵の設置が可能な担当者もかじめ From ヘッダアドレスに使用するドいれば、困難な担当者もいます。こういっ

メインを申請してもらい、当該ドメインにた様々な利用者が幅広く DKIM を利用して

対して電子署名の作成に使用する鍵を生成

87

第７章

配信サービスでの対応

し、利用者のドメインの DNS に設置するから提供されるなどして用意した公開鍵をための公開鍵をダウンロードする画面を用DNS に設置します。

意します。
※

From ヘッダアドレスのドメインの DNS サーバの管理をホスティング事業者に委託していて、当該事業者が公開鍵の設置に対応していない場合には、送信者署名は利用できません（受信者は電子署名を正しく検証できません）。

(b) 鍵管理と DNS 管理の支援
利用者の鍵管理の負担の軽減に加えて、DNS の管理の負担を軽減するために、配信サービスが送信者のドメイン又はサブドメインの DNS 管理を代行し、鍵とドメイ

7.3

配信サービスによる利用者への周知ンの管理を併せて代行するといったサービ
スを提供することも有効です。

配信サービス提供者は、導入している送信ドメイン認証技術、及び利用者が対応す(2) 利用者の対応
電子署名の作成用の公開鍵を DNS に設置することが可能な場合は、配信サービス

88

べき事項等の情報を Web サイト等に公開することが推奨されます第8章

利用者への周知第8章

利用者への周知

メールを利用する際に、多くのエンドユー
ザはメールのなりすましを意識することは少メイン認証技術に対応したメールとなることです。

ないと想定されます。しかし、エンドユーザ

しかし、書留郵便と異なり、送信ドメインが意識しないところで、送信ドメイン認証技

認証技術では、たとえ送信側で送信ドメイン

術による影響を受ける可能性があります。

認証技術を導入しても、受信側が対応してい本章では、エンドユーザに、最低限意識して欲しいことについて解説します。

なければ、そのメールは、送信ドメイン認証
技術に対応したメールとして受信されません。
エンドユーザは、各 ISP / ASP が提示する

8.1 送信ドメイン認証技術とは設定方法にしたがって利用していれば、意識送信ドメイン認証技術とは、受信者が受けしなくても、基本的には問題が発生すること取ったメールについて、送信者情報が詐称さはありません。しかし、自分が利用している

れているかどうかをドメイン単位で確認可能

メールについて、送信ドメイン認証技術を意とする技術です。

識しないと問題が発生する場合もあるため、メールを普通郵便に例えるならば、送信ド

これらについて、以下で説明いたします。

メイン認証技術を用いたメールは、書留郵便のようなものと考えることができます。ただ

なお、各 ISP / ASP が提供する迷惑メール

し、決定的な違いは、郵便では、送信者が書対策のサービスには、本技術を用いたものも留を意識して送信するのに対して、送信ドメ存在するため、迷惑メールに困っている場合

イン認証技術では、送信側の該当ドメインのは、サービスの内容を確認することも重要で

ドメイン管理元で送信ドメイン認証技術を導す。

入すれば、送信者が意識しなくても、送信ド

図表８－１ 送信ドメイン認証技術の概要

90

第8章

8.2 送信時の注意事項

利用者への周知

ドレスのドメインが送信ドメイン認証技術に対応している場合、そのメールはそのドメイ

多くのエンドユーザは、メールの送信時に、ンのメールを許可されているサーバ以外から送信に用いるメールアドレスを偽装する（なの送信となり、受信側でも送信ドメイン認証

りすます）ことはないと想定されます。しか技術に対応していると、そのメールは送信者

し、会社などのアドレスを用いて、自宅から情報を偽装した（なりすました）したメール

自分が契約している ISP 経由で送信すること判定されます。仮にそう判定されると、受と等も想定されます。そのような送信方法は、信側の機能によっては、該当のメールがフィ

厳格な管理を行う企業などでは禁止している

ルタリングされ、受信者に到達しない場合も場合が多いと想定されますが、実際にはメーあります。

ルクライアントソフトの設定を変更するだけしたがって、このような方法でのメール送で送信可能な場合もほとんどであり、事実と信は行わないことが賢明です。なお、このよ

してこの利用方法は多数利用されているのがうな事態を回避するために、一部のメールク

現実です。

ライアントでは、”Sender アドレス” というもこのような場合に、送信に用いたメールア

図表８－２のが設定できます。

外部メールサーバ利用時の注意事項

91

第8章

利用者への周知

8.3 受信時の注意事項

ールの多くは、送信者情報を偽装している（なりすましている）ため、このフィルタが提供

送信ドメイン認証技術で認証されたメール
は、あくまでも、送信されたメールアドレス

されている場合には、利用者側でも、積極的に導入することが推奨されます。

のドメインのメールを許可された送信されたことが確認されているだけですので、その内しかし、特別の使い方をする場合には、 8.2

容まで信頼できる訳ではありません。したがで解説した問題のほか、 8.4 で解説するメーって、送信されたメールの内容や送信者のアル転送の課題などもあるため、場合によってドレスを見て、問題ないメールか判断するこは、その利用方法について注意が必要です。

とが重要です。そのため、迷惑メール対策と多くの ISP では、回避策を準備していることして利用する場合には、内容に基づくフィルが多いため、利用の際は、利用している ISP

タリングサービスなど、他のサービスと組みの説明を確認することが推奨されます。

合わせて活用することが重要です。

ただし、多くのエンドユーザは、特別な使い方をすることはないと考えられますので、

迷惑メールの対策として、一部の ISP では、
送信ドメイン認証技術を用いたフィルタサー
ビスを提供しています（サービスの名称としては、「なりすましフィルタ」など、別の名称が用いられていることもあります。）。迷惑メ

92

基本的には、そのようなことを意識する必要はないと思われます。

第8章

8.4 メール転送時の注意事項

利用者への周知

なくなってしまいます。

メールを転送する場合には、転送元のアドしたがって、メール転送を行う場合には、

レスは、最初のメールの送信者のアドレスに転送先のサービスが送信ドメイン認証技術をなるのが一般的です。このため使っているド

採用しているか、メール転送時にどのようなメイン認証技術によっては、メールの転送がアドレスを使っているか等を確認する必要が行われる場合に、受信側で送信ドメイン認証あります。送信ドメイン認証技術を用いたフ技術による確認をする場合に、送信者情報（転ィルタを提供している多くのサービスでは、送元のアドレス）と送信に用いられたメール

ホワイトリストのように、無条件で受信を許サーバ（転送者のサーバ）が異なることにな

可する設定を可能にしており、事前に確認しるので、結果として、送信者情報を偽装した

たアドレスをホワイトリストに登録すること（メールアドレスをなりすました）メールを等により、フィルタで拒否されなくすること送信したことと同じことになってしまい、転も可能です。利用の際は、具体的な設定の方

送先の送信ドメイン認証のフィルタを利用し法等について、利用している ISP の説明を確ている場合などには、転送したメールが届か認することが推奨されます。

図表８－３ メール転送時の注意事項

93Appendix 1.

SPF レコードの記述例

Appendix 1. SPF レコードの記述例ｃ

本節では、SPF レコードの記述例について説明します。

Appendix 1.1 SPF レコードの例
SPF レコードは、記述ミスを防ぐため、なinclude や redirect、またマクロの機能等は、るべく簡潔に記述するよう心がけましょう。

間違えを起こしやすいので、本当に必要な場

また、簡潔に記述することが、受信側での認合にのみ利用し、ip4 や ip6 の記法で簡潔に証処理の負荷を軽減することにもつながりま

記述することを推奨します。

す。
Sample 1: ホストの IP アドレスで記述
メールを外部に送出するメールサーバのスを防ぐためや、受信側での DNS クエリをIP アドレスを直接指定します。送信メールサ

抑制するために、この記述方法を強く推奨しーバの数があまり多くない場合には、記述ミます。

example.org.

IN

TXT

"v=spf1 ip4:10.0.3.1 ip4:10.0.3.2 ip4:10.0.3.3 -all"

Sample 2: ホスト名で記述
メールを外部に送出するメールサーバのホスが簡単ですが、受信側の認証処理で DNS

スト名を指定します。Sample 1 の IP アドレ

への負荷が少し増える可能性があります。ホスを直接指定する方法に比べて、メンテナン

スト名は、必ず FQDN で指定します。

example.org.

IN

TXT

"v=spf1 a:mx01.example.org a:mx02.exmaple.org a:ns.example.org -all"

Sample 3: ネットワークでの指定
メールを送出する可能性のあるホストが存定すると）、SPF レコード自体の意味がなく在するネットワークを、CIDR 方式で指定しなるため、最小限のネットワーク範囲で利用ます。CIDR にあまり小さい値を指定するとします。

（つまりネットワークの領域をあまり広く指example.org.

IN

TXT

"v=spf1 ip4:10.0.4.0/28 -all"

Sample 4: ホストの IP アドレスとネットワークアドレスの混在
Sample 2 のホストの IP アドレスの指定と Sample 3 のネットワークの指定とを混在

96させることも可能です。

example.org.

IN

TXT

"v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 ip4:10.0.3.2 ip4:10.0.4.0/28 -all"

Sample 5: MX に指定したホストを利用
MX に指定したホストからしかメールを外防ぐことができます。ただし、受信側での認部に送出しない場合は、mx を利用します。

証処理でやや DNS への負荷が大きくなる可

メンテナンスが楽であり、記述ミスの発生を能性があります。

example.org.

IN

TXT

"v=spf1 mx -all"

Sample 6: メールを送信しないドメイン
管理しているドメインがまったくメール送

公開できます。

信しない場合は、"-all" を利用して、その旨をexample.org.

IN

TXT

"v=spf1 -all"

Sample 7: サブドメインに個別の SPF レコードを定義する
顧客へのアナウンスメールやキャンペーン

して管理するという方法もあります。業者がメールを外部業者に委託しているような組織

既 に SPF レ コ ー ド を 公 開 し て い れ ば 、の場合では、それらの配信メールの送信元サinclude を利用してそのレコードを利用でき

ーバの IP アドレスを SPF レコードに追加ます。ただし、 include する場合、参照先のする必要があります。しかし、外部業者が多SPF レ コ ー ド に 記 述 ミ ス が あ っ た り 、

数に上る場合など、レコードの管理が複雑に

include や、 redirect で、参照元を相互参照

なることが考えられるので、可能であれば、していたりしないか十分に確認した上で行いそれらの業者ごとに専用のサブドメインを払ます。

い出して、本来の業務用のドメインと切り離
example.org.
announce.example.org.
campaign.example.org.

IN
IN
IN

TXT
TXT
TXT

"v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 ip4:10.0.3.2 -all""v=spf1 ip4:10.1.4.0 ip4:10.1.4.1 -all""v=spf1 include:example.net -all"

Sample 8: redirect を利用してマルチドメイン環境での記述を簡略化する
１つの企業でも複数のドメインを利用してとが考えられます。ただし、参照先が必ず存いる場合や、複数のドメインのメールで１つ在するように注意し、また、相互に参照してのメールシステムを共有する場合には、参照のループを起こすことのないように、参redirect を利用して共有化を図ることで、メ照先のレコードでは include や redirect をンテナンスの負荷を軽減し記述ミスを防ぐこ利用しないようにします。

example.org. IN
example.net. IN
example.com. IN

TXT
TXT
TXT

"v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 ip4:10.0.3.2 -all""v=spf1 redirect=example.org""v=spf1 redirect=example.org"

97

Sample 9: 大きなレコードを複数の文字列で記述する
通信事業者や大きな組織ではメールサーバている場合には、認証を実施する受信側では、の数が多く、SPF のレコードのサイズが大きその文字列はすべてつなぎ合わせして１つのくなる可能性があります。SPF の RFC にお文字列として評価します。ただ、複数の文字

いて、1 つの TXT レコードでは複数の文字列

列を１つの文字列に連結するときに、つなぎを含むことが可能であり、１つの文字列の最目に空白文字は挿入されないので注意が必要

大長は 255 バイトであると説明されていまです。

す。１つの TXT が複数の文字列で構成されexample.org. IN
TXT"v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 ip4:10.0.3.2" " ip4:10.0.3.3 ip4:10.0.3.4
ip4:10.0.3.5" " include:example.net -all"

Sample 10: 大きなレコードをサブドメインを利用して記述する
RFC では、連結した後の１つのレコードがそれらにレコードを分割して記述した上で、450 バイト以下であることが目安とされていそれらを include するような対応が必要です。

ます。DNS のクエリに対するレスポンスが全繰り返しますが、相互参照やループの発生を体で 512 バイト以下でないと DNS のクラ防ぐため、include 文を利用する場合、参照

イアントが無視する可能性があるからです。

先ではなるべく include 文や redirect 文を

450 バイトを超えるような長いレコードを記利用しないようにします。

述するのはあまり勧められませんが、どうしても必要な場合は、サブドメインを定義してexample.org. IN
TXT"v=spf1 include:_spf-a.example.com include:_spf-b.example.com
include:_spf-c.example.com -all"_spf-a.example.org. IN TXT "v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 ip4:10.0.3.2 ip4:10.0.3.3 -all"_spf-b.example.org. IN TXT "v=spf1 ip4:10.0.5.0 ip4:10.0.5.1 ip4: 10.0.5.2 ip4: 10.0.5.3 -all"_spf-c.example.org. IN TXT "v=spf1 ip4:10.0.7.0 ip4: 10.0.7.1 ip4: 10.0.7.2 ip4: 10.0.7.3 -all"98Appendix 1.2 SPF レコードの間違い例
文法的に間違った SPF レコードを公開す
ると、受信側では permerror と扱われ、せっ提供していた場合、メールが届かなくなる可能性があります。

かく公開しても正しく扱われないことになっここでは以下に間違えやすい例を示しますてしまうばかりでなく、受信側で認証を passので、これらを参考に誤った記述が少なくなしたメール以外受信しないようなサービスをることを期待します。

Sample 1: バージョンの間違い(その１）"v=spf1.0" は間違っており、"v=spf1" でな

ければなりません。

(誤)
example.org. IN TXT "v=spf1.0 include:example-example.org -all"(正)example.org. IN TXT "v=spf1 include:example-example.org -all"

Sample 2: バージョンの間違い(その２)
SPFv2 のレコードを公開する場合、SPFv1
での記述方法や、"v=spf2.0/pra" という記述方

法は間違っており、"spf2.0/pra" でなければな
りません。

(誤)
example.org. IN TXT "v=spf2.0/pra include:example-example.org -all"(正)example.org. IN TXT "spf2.0/pra include:example-example.org -all"

Sample 3: 機構が省略されている誤り例では、機構が省略されている上に、ドメイン名が FQDN ではないため、エラーとなってしまいます。+a:ホスト名(FQDN)と記述することが必要です。

(誤)
example.org. IN TXT "v=spf1 mx nm nm1 ~all"(正)example.org. IN TXT "v=spf1 mx a:nm.example.org a:nm1.example.org ~all"Sample 4: １つのドメインに対して複数の SPF1 レコードを公開している
1 つのドメインに対しては１つの SPF1 レ
コードだけ公開可能です。複数公開するとエと SPF1 のレコードを１つずつ同時に公開することはできます。

ラーになります。ただし、SPF2 のレコード

99

(誤)
example.org. IN TXT "v=spf1 ip4: 10.0.3.0 ip4: 10.0.3.1 ~all"example.org. IN TXT "v=spf1 a:mx01.example.org ~all"example.org. IN TXT "v=spf1 a:web.example.org ~all"(正 1)
example.org. IN TXT "v=spf1 ip4: 10.0.3.0 ip4: 10.0.3.1 a:mx01.example.com a:web.example.org ~all"(正 2)
example.org. IN TXT "v=spf1 ip4: 10.0.3.0 ip410.0.3.1 a:mx01.example.com a:web.example.org ~all"example.org. IN TXT "spf2.0 ip4: 10.0.3.0 ip4: 10.0.3.1 a:mx01.example.com a:web.example.org ~all"Sample 5: タイプミス"ip4:" を"ipv4:" や "ip:" などと間違えるケに使ったツールなどが、"~" の文字を間違ってースが非常に多く見受けられます。また、誤 7

変換してしまう場合などもあるので、注意がの例のように、SPF レコードを作成するため

必要です。

(誤 1)
example.org. IN TXT "v=spf1 ipv4: 10.0.3.0 mx ~all"“ipv4:“ は間違い
(誤 2)
example.org. IN TXT "v=spf1 ip: 10.0.3.0 mx ~all"“ip:“ は間違い
(誤 3)
example.org. IN TXT "v=spf1 ip10.0.3.0 mx ~all"“:“ が抜けている(誤 4)
example.org. IN TXT "v=spf1 ip4=10.0.3.0 mx ~all"“:“ の代わりに “=“ を使っている(誤 5)
example.org. IN TXT "v=v=spf1 ip4: 10.0.3.0 mx ~all"“v=v=“ とバージョン記述を間違えている(誤 6)
example.org. IN TXT "v=spf1 ip4"

書きかけで終わっている(誤 7)
example.org. IN TXT "v=spf1 ip4: 10.0.3.0 mx ¥150all"“~“ が文字化けしている(正)
example.org. IN TXT "v=spf1 ip4: 10.0.3.0 mx ~all"Sample 6: 空白文字(SP)が抜ける
SPF レコードを二重引用符で複数にわけて記述することは可能ですが、その場合には、

100"ip4:10.0.3.0/26""ip4:10.5.0.0

~all"

は

"v=spf1 ip4:10.0.3.0/26 ip4:10.5.0.0 ~all" という大きな１つのレコードとして扱われるこ部分を接続するとき空白文字は補われないたとに注意が必要です。"" でくくられた２つのめ、区切り文字として空白文字が入りません。

(誤)
example.org. IN TXT "v=spf1 ip4: 10.0.3.0/26""ip4: 10.0.4.0 ~all"(正)example.org. IN TXT "v=spf1 ip4: 10.0.3.0/26 ip4: 10.0.4.0 ~all"Sample 7: redirect や include の先がない
include している先のドメインの SPF レ

初は存在していたものの、その後の DNS レ

コードが存在しないとエラーになります。誤コードの整理などでの変更を反映していない

り例では、_spf.example.org のレコードが存ことなどが原因として考えられます。

在していないためエラーになります。公開当(誤)
example.org. IN TXT "v=spf1 include:_spf.example.org ~all"* Can't find _spf.exmaple.org: Non-exisitent domain

Sample 8: redirect や include のループ(相互参照)
include している先のドメインの SPF レ

す 。 誤 り 例 で は 、 example.orgとコードで、元となるドメインを include して_spf.example.org がお互いに相手を参照しあ

しまい、相互参照が起こるとエラーになりまっておりエラーになります。

(誤)example.org. IN TXT "v=spf1 include:_spf.example.org ~all"_spf.example.org. IN TXT "v=spf1 include:example.org ~all"101Appendix 1.3 SPF レコードの確認方法の例
現行の送信ドメイン認証技術は、認証情報

以下では、例として、UNIX host コマンド

及 び ポ リ シ ー の 公 開 の た め に DNS 上 にの TXT レコードオプションを利用していまTXT レコードを公開する手法が一般的であすが、同様のクエリが発行できれば問題あり

るため、これを調査することにより、任意のません。このような操作を行うことにより、ドメインが送信ドメイン認証技術に対応して有効なレスポンスがあるかどうかでレコード

いるか、ある程度調べることもできます。

の有無を判断できます。

SPF レコード$ host -t txt example.com
example.com descriptive text "v=spf1 include:spf.example.com -all"

SenderID レコード
$ host -t txt example.com
example.com descriptive text "spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all"102

Appendix 2.

DKIM レコードの記述例

Appendix 2. DKIM レコードの記述例ｃ

本節では、DKIM レコードの記述例について説明します。

Appendix 2.1 DKIM レコードの例
DKIM レコードは SPF レコードに比べる指うにこころがけましょう。DKIM レコード公定する内容は簡単ですが、バージョンの記述

開後に必ず、試験的にメールを送信して認証など間違えないように気をつけて記述するよ

成功するかどうかを確認することが必要です。

Sample 1: 一般的な DKIM レコード
k100430._domainkey.example.co.jp
IN
TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOooW7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS
4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5YO52pZM40bdXY/qtfT2nglJqS53zFFqB36qHoN9lg
PRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"

Sample2 : t=y の指定により試験的運用であることを示す
k100429._domainkey.example.com.
IN
TXT"v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb
3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOooW7HmqsPFzZUUb1nNqMj7ozyv/Q0Www
GJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5YO52pZM40bdXY/qtfT2nglJqS53zFFqB36q
HoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"

104

Appendix 2.2 DKIM レコードの間違い例
文法的に間違った DKIM レコードを公開すると、受信側では permerror と扱われ、せビスを提供していた場合、メールが届かなくなる可能性があります。

っかく公開しても正しく扱われないことにな

ここでは以下に間違えやすい例を示しますってしまうばかりでなく、受信側で認証をので、これらを参考に誤った記述が少なくな

pass したメール以外受信しないようなサーることを期待します。

Sample 1 : 誤ったＦＱＤＮ上にＤＫＩＭレコードを公開している （その１）
直接該当ドメインの TXT レコードとして公開しています。DKIM の場合、 SPF とは異なり、"セレクタ._domainkey" サブドメインに公開する必要があります。

（誤）
example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJ”（正）k100429. _domainkey.example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJ”

Sample 2: 誤った FQDN 上に DKIM レコードを公開している（その２）セレクタを使わないで、サブドメインの_domainkey 以下に直接キーのレコードを記

タ._domainkey" サブドメインに公開する必要があります。

述しています。正しくは、"セレク（誤）_domainkey.example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"（正）K100429._domainkey.example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"

105

Sample 3: 公開鍵方式指定の誤り公開鍵方式の指定をハッシュの方式と間違えています (k=sha1 ではなく k=rsa)。

（誤）k100429._domainkey.example.com. IN TXT "v=DKIM1; k=sha1; t=y;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOooW7HmqsPFzZUU
b1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5YO52pZM40bdX
Y/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"（正）K100429._domainkey.example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"

Sample 4: バージョン記述の誤り
DKIM の バ ー ジ ョ ン を 間 違 え て い ま す（v=DKIM1.0 ではなく、v=DKIM1)。

（誤）k100429._domainkey.example.com. IN TXT "v=DKIM1.0; k=rsa; t=y;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOooW7HmqsPFzZUU
b1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5YO52pZM40bdX
Y/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"（正）K100429._domainkey.example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"

Sample 5: バージョン記述の位置の間違え
タグの順番を間違えています。v= タグがレ

コードの先頭に必要です。

（誤）k100429._domainkey.example.com. IN TXT "k=rsa; v=DKIM1; t=y;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOooW7HmqsPFzZUU
b1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5YO52pZM40bdX
Y/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"（正）K100429._domainkey.example.co.jp IN TXT"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwDc+AabcditzcdHYwOoo
W7HmqsPFzZUUb1nNqMj7ozyv/Q0WwwGJ+bdS4a9tO9roiT+VyyyMfIBoTdMNEWoXUMHafPgkOFPl5
YO52pZM40bdXY/qtfT2nglJqS53zFFqB36qHoN9lgPRwP/e+ScCPlwHkcfIwD58ISU/lC5Bx+wIDAQAB"

106

Appendix 2.3 DKIM のレコードの確認方法の例
現行の送信ドメイン認証技術は、認証情報

プションを利用していますが、同様のクエリ

及 び ポ リ シ ー の 公 開 の た め に DNS 上 にが発行できれば問題ありません。このようなTXT レコードを公開する手法が一般的であ操作を行うことにより、有効なレスポンスがるため、これを調査することにより、任意のあるかどうかでレコードの有無を判断できま

ドメインが送信ドメイン認証技術に対応してす。

いるか、ある程度調べることもできます。
Appendix1.3 と同様に、以下では、例として、UNIX host コマンドの TXT レコードオ
DKIM / DomainKeys レコード
$ host -t txt selector._domainkey.example.com
selector._domainkey.example.com descriptive text "k=rsa¥; t=y¥; p=(中略)¥; n=A 768 bit key¥;"

DKIM ADSP レコード
$ host -t txt _adsp._domainkey.example.com_adsp._domainkey.example.com descriptive text "dkim=all"

ただし、DKIM の場合は、ドメインに加える可能性もあり、DNS レコードが存在していて前述のセレクタが分からなければ確認するるからといって送信ドメイン認証技術に対応ことは困難です。

しているかは断定できません。したがって、

また、そもそも、これらの DNS レコード
は、送信者が試験として一時的に設置してい以上のような確認方法は、あくまで補助的な確認方法となることに注意して下さい。

107

108

Appendix 3.

関連 RFCAppendix 3. 関連 RFC
no
RFC2554

RFC4406

RFC4407

title
SMTP Service Extension for

SMTP での送信者の認証方式であるAuthentication

SMTP-AUTH の標準規格

Sender ID: Authenticating

送信ドメイン認証技術の一方式である

E-MailSender ID の標準規格

Purported Responsible
Address in E-Mail Messages
Sender Policy Framework

RFC4408(SPF) for Authorizing Use of
Domains in E-Mail, version 1

RFC4871

RFC5321
RFC5322

Sender ID で利用する ＰＲＡ の標準規格

送信ドメイン認証技術の一方式である ＳＰ
Ｆ の標準規格

DomainKeys Identified Mail

送信ドメイン認証技術の一方式である ＤＫＩ(DKIM) Signatures

Ｍ の標準規格

Simple Mail Transfer

電子メールのプロトコルである SMTP のProtocol標準規格

Internet Message Format

電子メールの形式に関する標準規格

Message Header Field for
RFC5451

概要

Indicating Message
Authentication Status

認証結果のヘッダーへの記録形式の標準
規格

DomainKeys Identified
RFC5617

Mail(DKIM) Authoer Domain

DKIM の署名方針に関する補助規格

Signing Practices (ADSP)RFC 4871 DomainKeys
RFC5672

Identified Mail (DKIM)
Signatures – Update

110

ＤＫＩＭ の標準規格 （RFC4871） の更新

Appendix 4.

用語集

Appendix 4. 用語集

インターネット標準

インターネットにおける技術等について、オープン標準として承認されたもの。

エラーメール

宛先不明や、メールサイズが大きすぎるなどメールを宛先に配送できない場合に、送信元へエラーが発生したことを通知するメール。
エラーメールの送信先には、送信者情報を用いる。

公開鍵暗号技術

公開鍵と秘密鍵という鍵ペアを用いて、データの暗号化・復号化を行う暗号方式。迷惑メール対策技術の中では、送信ドメイン認証技術の一つである DKIM において利用される。

サーバ

クライアントからの要求に対してサービスを提供するシステムのこと。電子メールの配送をするためのシステムはメールサーバと呼ばれる。

サーバ・アプリケーショ

サーバのサービスを処理するためのプログラム。メールサーバの場

ン・プログラム

合には、メールの相手先を振り分けるメール転送エージェント(MTA) や、振り分けられたメールをサーバ内のユーザや別のサーバへ配送するメール配送エージェント (MDA) などといったサービスを処理するプログラムがある。

送信者情報
リバースパス

電子メールの送信者の情報。
電子メールの送信元。エンベロープ from とも呼ばれる。メールヘ
ッダには ”<Return-Path: メールアドレス>“ として記録される。

From ヘッダアドレス

ヘッダ form 参照。

PRA

Purported Responsible Address の 略 で From 、 Sender 、
Resent-From 、 Resent-Sender で記述するアドレスを指す。

エンベロープ fromリバースパス参照。

ヘッダ from

一般的に、メールを作成した者のアドレス。メールのヘッダーフィ
ールドに記載された送信者のメールアドレス。メールヘッダには 、“From: メールアドレス” で記録される。

Sender アドレス

メールの作成者と送信者が異なる場合に、送信者の名前やアドレスを記載するもの。メール配信業者がメールを送信する場合に使うことが多い。

Resent From アドレス

メールを転送時等に付与する転送者のアドレス。メールヘッダには、”Resent-From: アドレス” で記録される。

Resent Sender アドレ

112

メールを再送時等に付与するアドレス。Sender アドレスが記載さス

れている場合は、“Resent-Sender” を使うのが一般的である。

送信ドメイン認証技術
ネットワーク方式

ネットワークを用いた認証方式

電子署名方式

公開鍵暗号方式を用いた認証方式。

セレクタ

公開鍵を取得する際に、クエリを発行する対象のドメイン名の一部に利用する。複数のセレクタを持つことで 1 つのドメインで複数 の公開鍵を利用できる。

電子署名

本人確認や、偽造・改ざんの防止に用いる電子的な署名。

ドメイン

インターネット上に存在するコンピュータやネットワークを識別する名前。重複しないように ICANN という国際組織により一元管理されている。

ドメインレピュテーション

電子メールの送信に利用されているドメインの評判情報（レピュテーション情報）、または、この情報を用いて、通信を制限する技術。

バウンスメール

エラーにより、送信元に送り返されてくるメールのこと。

ハッシュ

ハッシュ関数から得られた数値のこと。検索やデータ比較処理の高
速化、改竄の検出などに用いられる。

ハッシュ関数元となる情報から、不可逆な一定長の情報を算出する関数。SHA1、
SHA256 などがある。

配信サービス

メールの配信を作成者に変わって行うサービスのこと。

標準規格

RFC で規定される標準化規格のうち、Standard の標準状態のもの。

フィルタ
アンチウィルスフィル

メールに添付されたウィルスファイルを検知し、削除したりする機タ能。

迷惑メールフィルタ

迷惑メールの特徴や送信元情報などをあらかじめデータ化して、受信メールと照らし合わせて機械的に判断し、迷惑メールと判断した
メールを専用フォルダに格納したり削除したりする機能。

ブラウザ

データを表示、閲覧するためのソフトウェア。Web ブラウザ、画像
ブラウザなど。一般的にブラウザと言った場合、ホームページ（html言語）を表示するための Web ブラウザを示す。

ブラックリスト

アクセスを許可しないリスト。メールで用いる場合は、メール受信を拒否するアドレスリストを指すのが一般的である。

ホスティングサービス

記憶領域や演算能力等のサーバの機能を提供するサービス。

ホスト

ネットワークに接続された機器につけられた名前のこと。

ホワイトリスト

アクセスを許可するリスト。ブラックリストの逆。メールで用いる
場合は、メール受信を許可するアドレスリストを指すのが一般的。

113

メールサービス

電子メールの使用権利を提供するサービス。

メールシステム

電子メールの送受信のために用いられるシステム。

メールスプール

第２章参照。

メールヘッダ

電子メールの先頭に記載されたデータ領域で、送受信に用いられる情報を記載する部分。

ラベリング

メールの題名などに、特定の情報を追加する機能。例えば迷惑メー
ルフィルタによって迷惑メールと判定されたメールの題名に、[meiwaku] などの文字列を追加し、見分けやすくするものなどがある。また、ドメイン認証の結果をヘッダに付与するように、ヘッダ情報に付与する付加情報もラベリングと呼ぶ場合が多い。

リゾルバ

DNS のネームサーバに対して IP アドレスからホスト名を取得したり、その逆を行ったりするためのプログラム

Authentication Results ヘッ

送信ドメイン認証における認証結果などを記述するためのヘッダー

ダ

フィールド

CRAM-MD5

SMTP AUTH で使われる SASL の認証方式の一つ

DKIM

送信ドメイン認証技術の一方式。送信元が付した電子署名により送信元情報の真偽及び電子メールの本文の改変を検知することができる。DomainKeys と IIM を合わせて策定されたもの。RFC4871

DKIM-ADSPDKIM Author Domain Signing Practice の略。DKIM の拡張技術

DKIM-Signature ヘッダ

DKIM において、作成した電子署名を付与するためのヘッダーフィ
ールド

DNS

Domain Name System の略。ドメイン名と IP アドレスを対応付け
るデータベースシステム。インターネット上のコンピュータにアクセスするためには IP アドレスを知らなければならないが、直接数字入力するのは実用的ではないので、名前を用いてアクセスする方法が考案された。

再帰検索

DNS サーバに対して DNS 解決が完結するまでドメイン・ツリー
をたどって検索を行うもの

資源レコードDNS サーバに登録する情報のこと。A レコード、MX レコード、
NS レコードなどがある。

MX レコード

Mail eXchange レコードの略。DNS サーバに定義された受信メー
ルサーバーのホスト情報など

TXT レコード

ホスト名に関連付けるテキスト情報（文字列）を定義する DNS レ
コードの一つSPF レコード114

SPF / Sender ID において、そのドメインが使用する送信サーバを

インターネット上で宣言するための DNS レコードの一つ
A レコードホスト名から IPv4 アドレスを取得するための情報を記録した
DNS レコードの 1 つ

ESMTP

SMTP の拡張を定義したもの。

FQDN

Fully Qualified Domain Name の略。TCP / IP ネットワーク上で、ドメイン名・サブドメイン名・ホスト名をすべて省略せずに指定した記述形式のこと

GlobalIP

インターネットに接続された機器に一意に割り当てられた IP アド
レス。

IETF

The Internet Engineering Task Force の略。インターネット上で利用される技術の標準化を行う組織。策定された標準仕様を、RFC（Request For Comment）として発行している。

IMAP4Internet Message Access Protocol version 4 の略。メールサーバ上に保存されている電子メールに直接アクセスすることができる通信
プロトコル。

IP アドレス

インターネット上で個別の端末を判別するための番号。

IPv6

Internet Protocol version 6 の略。現在主流のインターネットプロト
コルである IPv4 に変わる次世代版プロトコル。

ISP

Internet Service Provider の略。インターネットに接続するサービスの提供を行う企業や団体をいう。

MARID WG

Mta Authorization Records In Dns Working Group の略。

MDA

メール配送エージェント。Mail Delivery Agent の略。第２章参照。

miltermail filter の略で、Sendmail が開発したメールフィルタプラグイン
の仕組み

MTA

Mail Transfer Agent の略。電子メールをクライアント－サーバ間・
サーバ－サーバ間で転送するサーバ。第２章参照。

MUA

Mail User Agent の略。いわゆるメールクライアントであり、電子メールを使用するもののユーザーインターフェイスとなる。例えば
Microsoft Outlook や Mozilla Thunderbird などである。第２章参照。

MSA

Message Submission Agent の略。MUA から発信されたメールを受け取るサーバ。MTA と同義で使用することもあるが MSA は、
SMTP AUTH や POP before SMTP などの認証機能や不完全なメールヘッダの修正を行う機能を提供する。第２章参照。

POP3

Post Office Protocol Version 3 の略。メールサーバから電子メールを取り出すときに使用される通信プロトコル。RFC1939。

115

RFC
実験的 RFC

IETF が正式に発行する技術の標準を定めた文書。
RFC の位置づけで、インターネットに関して有用と考えられる研究
成果や実験結果を広く公開するためのもの

SenderID

送信ドメイン認証技術の一つ。SPF と同様のチェックに加え、Resent-sender: → Resent-from: → Sender: → From: 順序でヘッダ
情報の送信ドメインをチェックし、当該 DNS に確認を行い送信元
情報の真偽を確認する。RFC4406。

SMTP

Simple Mail Transfer Protocol の略。インターネットで電子メールを転送するプロトコル

HELO コマンド

SMTP コマンドの一つ。SMTP セッションを開始するコマンド。

MAIL コマンド

SMTP コマンドの一つ。メールを送るコマンド

DATA コマンド

SMTP コマンドの一つ。メールを転送するコマンド

エラーメール

メールの配送になんらかの問題が発生した場合に送信者に対して送られるメール。エラーの内容が書かれている場合が多い

SMTP AUTH

RFC 2554 によって規定された、SMTP にユーザ認証機能を追加するもの。
Sender Policy Framework の略。送信ドメイン認証技術の一つ。エ

SPF

ンベロープ情報の From メールアドレスのドメイン名をチェック
し 、 当 該 DNS に 確 認 を 行 い 送 信 元 情 報 の 真 偽 を 確 認 す る 。
RFC4408。
SPF レコードSPF で、DNS サーバ上にメールを送信するサーバの情報を公開するためのヘッダーフィールド。

限定子

限定子は、それに続く機構にマッチした場合の認証結果を指定する。

機構

機構には、認証対象の送信元ホストの IP アドレスと照合する条件を
記述する。

修飾子

引数であるドメイン名に指定されたドメインの SPF レコードにより認証処理を実行する「redirect」と、認証が失敗した場合、引数であるドメイン名に指定されたドメインの TXT RR に設定されている文字列を、認証失敗した理由や説明等として利用する「exp」が
ある。

TCP

Transmission Control Protocol の略。インターネットでデータ転送に用いられるプロトコル。複数のエラー制御によって信頼性を確保することができる。

TTL

Time To Live の略。パケットの無限ループを防止するためにあらか
じめ設定されるパケットの生存時間の値。

UDP

116

User Datagram Protocol の略。インターネットでデータ転送に用いられるプロトコル。TCP とは違いエラー制御のための仕組みをもた
ない。

117

送信ドメイン認証技術導入マニュアル第２版
2011 年 8 月発行
企画・著作・制作

迷惑メール対策推進協議会（事務局）（財）日本データ通信協会迷惑メール相談センター〒170-8585 東京都豊島区巣鴨２－１１－１

URL

http://www.dekyo.or.jp/soudan/

TEL：03-5907-5371
本書の全部又は一部の複写、複製及び磁気又は光記録媒体への入力等は、著作権法上での例外を除き禁じられています。これらの許諾については、当事務局までご照会ください。

118