送信ドメイン認証技術解説

Sender ID：送信者側の設定作業

末政 延浩
センドメール株式会社
テクニカルディレクター
2005/10/27

---

　送信ドメイン認証は、Yahoo!やGmailで「DomainKeys」が、Hotmailで「Sender ID」が利用されているほか、多くのISPが対応を表明したことにより一段と普及が進んでいる。すでに米国などでは、送信ドメイン認証に対応しているドメインからのメールを優遇して通すなど、利用することのメリット、また利用しない場合のデメリットなどが現れてきている。

　本稿では2回にわたって、IPアドレスベースの認証方式に分類される「SPF（Classic SPF）」およびSender IDについて解説する。前編では、SPFおよびSender IDを導入するに当たって、実際にどのように手を動かせばいいのかについて説明したい。

　IPアドレスベースの送信ドメイン認証

　まず、IPアドレスベースの送信ドメイン認証について説明する（図1）。送信側は、「Sender Policy Framework（SPF）レコード」と呼ばれるデータをDNS（Domain Name Server）上に公開する。受信側は受信中のメールの送信ドメインを検証し、そのドメインのDNSからSPFレコードを取り出して、現在接続している相手サーバのIPアドレスと照合する。照合の結果、相手サーバがSPFレコードにマッチすれば認証OKとなる。

図1　IPアドレスベースの送信ドメイン認証 （1）　AA.COMのメールサーバからBB.COMのメールサーバへSMTP通信を開始 （2）　BB.COMのメールサーバはFrom：に記述されたメールアドレスのドメイン部を基にAA.COMのDNSサーバへSPFレコードを問い合わせる （3）　AA.COMのSPFレコードに示されるIPアドレスのリストに送信側のメールサーバが含まれていれば認証成功

　IPアドレスベース認証方式には、Microsoftが提唱しIETFのMARIDにおいて調整が進められたSender IDと、poboxのMeng Wong氏が提唱したSPFの2つがある。なお、Sender IDはSPFとの互換性を持っている。

　送信ドメイン認証の基盤となる送信ドメインとは、メールの送信者が名乗るメールアドレスのドメイン部分を指す。SPFとSender IDでは送信ドメインを決定する方法が異なる。SPFはSMTP通信中にやりとりされるエンベロープから送信ドメインを決定する。

　一方、Sender IDはヘッダ情報から送信ドメインを決定する。このヘッダ上のアドレスを「Purported Responsible Address（PRA）」と呼ぶ。Sender IDは、それ以前からMicrosoftが提唱していたCallerIDとSPFをマージしてできた規格であり、SPFレコードの文法はSPFの規格を共有している。

　Sender ID、使っても大丈夫？

　Sender IDについて、そのライセンスをめぐって大きな議論が起こったのは記憶に新しいところだ。実際に使うときにはどのようにライセンスを考えるべきであろうか。

　その答えはMicrosoftのWebサイトで公開されている文書「Sender ID Frameworkと知的財産についての概要とよく寄せられる質問」にまとめられている。この中から重要な点を説明する。

【参考リンク】 Sender ID リソース 上記のライセンスに関するPDF文書などがまとめられている

・ライセンス料は無料である

　同文書にあるQ4の回答に「マイクロソフトは、ライセンスに料金またはその他の特許使用料を要求しないことを明確にすることで、IETFの要件も満たしています」と記述されている。

・送信側としてSPFレコードを公開するだけならば、ライセンスにサインしてMicrosoftに送付する必要はない
・受信側としてMicrosoftが知的所有権を主張するPRAのチェックを実施する場合において、ISPや企業などでは契約書にサインする必要がある

　同文書のQ5に対する回答として、「ライセンスが、Sender ID FrameworkのPRAチェック手段を使用して電子メールを確認する組織（ISP、大企業）に関連する場合だけ、ライセンスを取得する必要があることに注意することが重要です。単にSender IDレコードを公開するだけの組織には、ライセンスは必要ありません」とある。

　つまり、送信側でSPFレコードを公開するだけの場合は、ライセンスを気にする必要はないということである。また、受信側でPRAをチェックする場合には契約書にサインしMicrosoftに送付する必要がある場合があるが、その場合でもライセンス料は無料である。

　送信側のベネフィット、受信側のベネフィット

　送信ドメイン認証において送信側のベネフィットは、自ドメインから送信された正当なメールについて、受信側にその正当性を確認させることが可能になるということである。いい換えるならば、スパム送信者らがあなたの所有するドメインを送信ドメインとしてスパムメールを送信したとき（ドメイン詐称）、受信者はそれが正当なメールではないということを確認できる。

　受信側のベネフィットは、スパムメールの多くが送信者を詐称していても正当なメールかどうかをチェックできるため、スパムメールやフィッシィング詐欺への対策として利用できるということである。

　送信ドメイン認証を導入する際の重要な点としては、送信側と受信側それぞれに設定があり、どちらも別々に運用が可能であるという点である。つまり、送信側でも受信側でも、可能な方から運用を始められるということだ。特にIPアドレスベースの認証方式の場合は、送信側はDNSにSPFレコードを公開するだけなので簡単に開始できる。

1/4

Index
Sender ID：送信者側の設定作業
	Page1 IPアドレスベースの送信ドメイン認証 Sender ID、使っても大丈夫？ 送信側のベネフィット、受信側のベネフィット
	Page2 送信側での準備 チェック対象とされる送信ドメイン SPFレコードの記述法
	Page3 SPFレコードの定義 SPFレコードのサンプル
	Page4 SPFレコードを公開する場合の注意点

ドメイン認証技術解説
	Sender ID：送信者側の設定作業
	Sender ID：受信者側の設定作業

Sender ID：送信者側の設定作業

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）