HOME情報セキュリティなりすましメール撲滅に向けたSPF(Sender Policy Framework)導入の手引き

本文を印刷する

情報セキュリティ

なりすましメール撲滅に向けたSPF(Sender Policy Framework)導入の手引き

独立行政法人情報処理推進機構
技術本部 セキュリティセンター

概要

 インターネットで使われる電子メールは、送信元メールアドレスを自由に設定できます。そのため、偽の送信元メールアドレスが設定されている、いわゆる「なりすましメール」が多くあります。「なりすましメール」は、標的型攻撃メールや迷惑メールの中で使われることも多くあり、いかにして「なりすましメール」を減らしていくかが、課題となっています。

 「なりすましメール」をなくすためには、メールの送信側と受信側の連携が必要です。まず送信側は、正しく送信するメールがどのようなものか、情報を提供することが必要です。そのようにして初めて、受信側は受信したメールが「なりすましメール」かどうかを区別でき、「なりすましメール」であれば排除するなどの対応が可能になります。

 このような、送信側と受信側が連携するための方式の1つが、SPF(Sender Policy Framework)です。本ページでは、SPF導入の端緒となる、送信側としての導入方法を説明します。送信側・受信側ともSPFを導入している場合、受信側でSPFによる確認が取れるため、受信側は安心してメールを受信できます(図1)。

図1

図1: 送信側(A社)・受信側(B社)ともSPF対応済みの場合

図2

図2: A社を騙った「なりすましメール」をB社が受信する場合

 また、「なりすましメール」があった場合でも、受信側でSPFによる確認をとった結果、「なりすましメール」だと判断できるため、排除することができます(図2)。

 一方で、送信側がSPFを未導入の場合、受信側は「なりすましメール」かどうかを区別できないため全体として機能せず、攻撃者からの「なりすましメール」をブロックできません(図3)。

図3

図3: 送信側(C社)がSPF未対応の場合

 このため、メールを送信する機会がある組織は、受信側への気配りとしてSPFを導入することが推奨されます。そこを端緒に、社会全体で「なりすましメール」を排除できるようになります。
 一方で、SPFには運用上の注意点もあり、特にメールの転送時に問題を生じやすいことが知られています。SPFを導入する際には、このような注意点も考慮する必要があります。

SPFの導入方法(送信側)

 送信側としてのSPFの導入は、ドメインを保有している組織や個人が、DNS(*1) サーバを設定することで行います。DNSサーバの管理を担当している方は、以下の手順に沿って設定を実施してください。そうでない方は、管理を担当している部署や会社に相談してください。

(1) 送信用メールサーバのリストアップ

 組織で使用している送信用メールサーバを漏れなくリストアップし、その出口のIPアドレスを控えます。日常業務で使用しているメールだけでなく、顧客に配信するメールマガジン、社員向けにグループウェアから送信するリマインダ、システムに異常があった際に送信するアラートメールなども、存在する場合には忘れないでください。この情報は、SPFレコードをDNSサーバに設定する際に使用します。
 もし、このリストアップに漏れがあった場合、リストから漏れたメールサーバから送信されたメールが「なりすましメール」と判定されて、届かなくなる場合があります。このため、リストアップは確実に行ってください。
 詳しくは、下記の資料を参照してください。

(2) SPFレコードをDNSサーバに設定

 ドメインを管理しているDNSサーバに対して、(1) でリストアップした送信用メールサーバのIPアドレスを公開するためのTXTレコードを追加してください。このTXTレコードは、SPFの書式に従って書く必要があります(このTXTレコードを一般にSPFレコードと呼びます)。
 例えば、(1) でリストアップした送信用メールサーバのIPアドレスが192.0.2.1の場合、次のように記述できます。

記述例1: 1つのメールサーバから送信する場合
IN TXT "v=spf1 +ip4:192.0.2.1 -all"   
 また、IPアドレスが複数あり、たとえば192.0.2.1および192.0.2.21の場合、次のように記述できます。 記述例2: 2つのメールサーバから送信する場合
IN TXT "v=spf1 +ip4:192.0.2.1 +ip4:192.0.2.21 -all"    

 このほかにも、SPFレコードには様々な記法があります。詳しくは、下記の資料を参照してください。

(3) 動作の確認

 SPFレコードをDNSサーバに設定した後は、実際にメールを送信して確認します。この確認に使用できるサービスは幾つか存在しますが、ここではport25.comが提供するサービスを例に説明します。下記の手順を、(1) でリストアップしたメールサーバの分だけ実施してください。

まず、次のメールアドレス宛にテスト用のメールを送信します。
check-auth@verifier.port25.com   
すると、次のような内容のメールが自動的に返送されます(抜粋)。
========================================
Summary of Results
========================================
SPF check: pass
DomainKeys check: neutral
DKIM check: neutral
Sender-ID check: passv
SpamAssassin check: ham
  

 SPF Checkの欄が、上記のようにpassとなっていれば、SPFの導入は成功です。それ以外の結果の場合、(1) および (2) の手順を再確認してください。

SPF運用上の注意点

 SPFの導入後は、SPFに起因する問題が生じることがあります。特に、自動的なメールの転送を設定している利用者がいる場合や、メーリングリストを運営している場合には、問題が起きやすいことが知られており、注意が必要です。
 この問題は、メールを受け取った際に、送信者情報をそのままにして、別の受信者に転送する場合に起きます。解決策として、メールを転送する際には送信者情報をそのままにせず、適切な書き換えを行う方法があります。具体的には、Senderヘッダに転送元のドメインのメールアドレスを設定する方法や、SPFの仕組みの中で規定されているSRS: Sender Rewriting Schemeを使用するなどの方法があります。

詳しくは、下記の資料を参照してください。

SPFの導入方法(受信側)

 受信側としてのSPFの導入は、本文書では説明の対象外ですが、受信側としてSPFの検証機能を導入すると「なりすましメール」を区別できるようになります。詳しくは、ご利用のメールサービスや、メールサーバソフトウェアのマニュアルを参照してください。

参考情報

脚注

(*1) DNS: Domain Name System。コンピュータがネットワークのどこに接続されているかを示すIPアドレスという数字の集まりを、www.ipa.go.jp のような人に覚えやすい表記と対応させるための情報を管理する仕組みです。

更新履歴

2012年 5月23日 掲載