間違いから学ぶSPFレコードの正しい書き方

岡山大学
山井成良
2011年4月

1. はじめに
2. 典型的な誤りと正しい書き方
　2.1 SPFレコードが複数行存在する
　2.2 機構（メカニズム）の記述に誤りがある
　2.3 参照方法に誤りがある
　2.4 必要な空白文字がない
　2.5 その他の間違い
3. チェック方法
　

1.　はじめに

迷惑メールは、現在のところ、送信元アドレスが詐称された状態で送られるものが大多数を占めます。これにより、迷惑メールの送信源追跡を困難にしたり、フィッシング詐欺に利用されたりします。そこで、送信元アドレスの詐称を防止する送信ドメイン認証技術が開発されました。

現在までに実用化されている送信ドメイン認証技術はいくつか存在しますが、そのうち最も普及しているものがSPF（Sender Policy Framework）です。平成22年6月時点におけるjpドメインでの普及率はドメイン数ベースで約40パーセントであり、DomainKeysの約0.5パーセントを大きく上回っています(*1)。メッセージ数ベースでは80パーセント以上のメッセージがSPFに対応したドメインから送信されており(*2)、SPFはもはや標準的な技術と言っても過言ではないでしょう。

(*1)　「ドメイン認証の普及率に対する測定結果」（WIDEプロジェクト）
　　　　<http://member.wide.ad.jp/wg/antispam/stats/index.html.ja>
(*2)　「送信ドメイン認証技術の導入状況についての調査結果の公表」2010年7月23日（総務省）
　　　　<http://www.soumu.go.jp/menu_news/s-news/02kiban08_02000047.html>

しかし、総務省の「送信ドメイン認証技術の導入状況についての調査結果の公表」によると、メッセージ数ベースで約10パーセントのメッセージが文法的に正しくないSPFレコード（PermError）により認証処理が実行されませんでした。この場合、SPFレコードを全く宣言していないものとして扱われ、せっかくの設定が無駄になってしまいます。

そこで、よくある間違いを例にとり、SPFレコードの正しい書き方を確認したいと思います。なお、SPF自身の詳細な説明については末政氏の解説(*3)をご参照ください。

(*3)　「SPF（Sender Policy Framework」末政 延浩、有害情報対策ポータルサイト迷惑メール対策編、
　　　　2010年1月（財団法人インターネット協会）
　　　　<https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/>

2.　典型的な誤りと正しい書き方

インターネット協会迷惑メール対策委員会の調査では、co.jpドメインでのSPFレコードの記述誤りのうち、件数が多い事例は以下のとおりです（順不同）。

(1) SPFレコードが複数行存在する
(2) 機構（メカニズム）の記述に誤りがある
(3) 参照方法に誤りがある
(4) 必要な空白文字がない

以下では、それぞれの誤りについて詳しく見ていきます。

2.1　SPFレコードが複数行存在する

よく見られる間違いが、複数のSPFレコードの宣言です。典型的な間違い例を、2つ示します。

【誤】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"
                     "v=spf1 +ip4:10.0.0.0/24 ~all"

【誤】
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 "
                     "+ip4:10.0.0.0/24 ~all"

最初の例では、1つのドメインに対して複数のSPFレコードを記述しており、エラーになります。これは、DNSでは複数のレコードが存在すると応答によってその順序が異なる場合があり、意図とは異なる結果となる危険性があるためです。また、2番目の例では、2行目はSPFレコードではないため無視され、エラーとはなりませんが、意図とは異なる結果となります。両方の例とも、正しくは次のように書いてください。

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 +ip4:10.0.0.0/24 ~all"

中には、1行で収まらないような長い宣言、あるいは複数行にわたる宣言をしたい場合もありえます。そのような場合には、複数のSPFレコードを記述するのではなく、文字列の連結やサブドメインの利用で対処します。その際の注意点は、2.4節をご参照ください。

なお、SPF1とSPF2.0のように、異なるバージョンで記述する場合、あるいはSPF2.0でPRAとmfromを分けて記述する場合には、順序が変わっても正しく解釈できるためエラーにはなりません。

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"
                     "spf2.0/pra +ip4:192.168.100.0/24 ~all"
                     "spf2.0/mfrom +ip4:192.168.100.0/24 ~all"

ただし、SPF1の宣言しかない場合でも自動的にspf2.0/pra,mfromとしても宣言したものと解釈されるため、上記の例は単に

【正】 
example.jp.   IN TXT " v=spf1 +ip4:192.168.100.0/24 ~all"

と宣言すべきです。かなり特殊な場合を除き、SPF1の宣言だけで十分です。

2.2　機構（メカニズム）の記述に誤りがある

機構（ip4など）の未指定やスペルミスも犯しやすい間違いです。たとえば、次のような間違いが多く見受けられます。

【誤】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 +ipv4:10.0.0.0/24 ~all"

【誤】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 10.0.0.0/24 ~all"

IPv4アドレスによる指定の場合、機構は「ipv4」ではなく「ip4」と指定します。また、複数のアドレスを列挙する場合には、アドレスごとに機構が必要になります。したがって、いずれも正しい記述は次のようになります。

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 +ip4:10.0.0.0/24 ~all"

上記の間違いの例のように、一部だけ間違っている場合が数多く見られます。これは、正しい書き方は理解しているにもかかわらず、うっかり間違ってしまったと思われますので、注意深く確認するようにしてください。

2.3　参照方法に誤りがある

includeやredirectによる他のドメインのSPFレコードの参照はSPFレコードの設定を共通化できる便利な機能ですが、一方ではエラーの原因になりやすい機能でもあります。たとえば、次の例

【誤】 
example.jp.   IN TXT " v=spf1 redirect=_spf.example.jp"

において、“_spf.example.jp”というドメインが存在しなければ当然エラーになります。このエラーは、設定当初は発生していなくても、たとえばexample.jpをexample.comに変更した場合などドメイン名の変更や統廃合に伴うDNSレコードの整理により参照できなくなってしまうことがあり、注意が必要です。

また、参照先ドメインは省略形ではなくFQDNである必要があります。SPFレコードは文字列として宣言されるため、$ORIGINディレクティブなどで指定される起点名による補完の対象にはなりませんのでご注意ください。

【誤】 
$ORIGIN example.jp. ; FQDN以外の名前に対して追加されるドメイン名
example.jp.   IN TXT "v=spf1 +a:mta include:_spf ~all"
mta           IN A   192.0.2.1
_spf          IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"

【正】 
$ORIGIN example.jp. ; FQDN以外の名前に対して追加されるドメイン名
example.jp.   IN TXT "v=spf1 +a:mta.example.jp include:_spf.example.jp ~all"
mta           IN A   192.0.2.1
_spf          IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"

また、参照先に関する別のエラーとして、DNSレコードの参照回数超過があります。SPFでは、1回のSPFレコードの検証について、DNSレコードの参照を伴う機構や修飾子（modifier）は10回を越えて指定できません。このような機構や修飾子には、a、mx、ptr、existsがありますが、includeやredirectも含まれます。これらの使用回数が合計で10回を超えた場合には、エラー（PermError）になります。特に、includeやredirectを用いた場合には参照先での使用回数が加算されますので、このエラーが発生しやすくなります。たとえば、

【誤】 
example.com.  IN TXT "v=spf1 redirect=example.org"
example.org.  IN TXT "v=spf1 +a:mta1.example.org +a:mta2.example.org …… +a:mta10.example.org -all"

のような設定をすると、example.orgのSPFレコードの解釈だけではDNSレコード参照を行う機構の使用回数が10回に留まっていますのでエラーにはなりませんが、example.comのSPFレコードの解釈ではさらにredirectにより使用回数が1回増えて11回となるため、エラーになります。また、参照先が循環している場合も同じ理由でエラーとなります。

【誤】 
example.com.  IN TXT "v=spf1 redirect=example.org"
example.org.  IN TXT "v=spf1 redirect=example.com"

includeやredirectは設定の共有化のためには便利な機能ですが、その分間違えた場合の影響も大きくなります。参照先でさらにincludeやredirectは使わないようにするなど、使用に際してはDNSレコード参照回数超過とならないように十分に気をつけましょう。

2.4　必要な空白文字がない

メールサーバの台数が多い組織では、SPFレコードがどうしても長くなってしまう場合があります。このような場合、SPFでは1つのSPFレコードに複数の文字列を記述できます。1つの文字列の最長は255文字に制限されていますが、文字列の連結によりこの制限を超えることができます。

ところが、文字列の連結の際に必要な空白文字を忘れる場合がかなり見られます。典型的な例を、以下に示します。

【誤】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24" "+ip4:10.0.0.0/24 ~all"

この場合には、2つの文字列を連結した次のレコード

example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24+ip4:10.0.0.0/24 ~all"

と解釈され、エラーになります。正しく解釈されるためには、2つの文字列が連結されたときに区切りとなるように、前の文字列の最後に空白文字を追加するか、後ろの文字列の最初に空白文字を挿入する必要があります。

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 " "+ip4:10.0.0.0/24 ~all"

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24" " +ip4:10.0.0.0/24 ~all"

DNS設定の都合上、どうしても行を分割したい場合には、以下のようにすれば可能です。ただし、この場合にも文字列を連結したときに区切りとなる空白文字は必要ですので、ご注意ください。

【正】 
example.jp.   IN TXT ( "v=spf1"
                          " +ip4:192.168.100.0/24"
                          " +ip4:10.0.0.0/24"
                          " ~all" )

なお、連結したレコードの長さは450文字以下であることが目安とされています。これは、DNSの応答メッセージが512バイト以下でないと正しく送られない可能性があるためです。もし、どうしても450文字以上に長くなる場合には、以下のようにincludeを使って分割する方法があります。

【正】 
example.jp.   IN TXT "v=spf1 include:_a.example.jp include:_b.example.jp ~all"
_a.example.jp IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"
_b.example.jp IN TXT "v=spf1 +ip4:10.0.0.0/24 ~all"

ただし、このような設定を行う場合、参照先が正しいかを確認するようにしてください。また、前節で述べたDNSレコード参照回数超過を防ぐため、参照先でさらにincludeやredirectを使うのは避けてください。

2.5　その他の間違い

この他にも、ちょっとした勘違いでエラーとなる例が見られます。以下にいくつかの例を列挙しますので、ご注意ください。

・バージョンの間違い

SPF1の場合には、バージョン番号の指定は「spf1」が正しく、それ以外はエラーになります。

【誤】 
example.jp.   IN TXT "v=spf1.0 +ip4:192.168.100.0/24 ~all"

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"

また、SPF2.0の場合には「v=」は不要で、これを付けるとエラーになります。

【誤】 
example.jp.   IN TXT "v=spf2.0/pra,mfrom +ip4:192.168.100.0/24 ~all"

【正】 
example.jp.   IN TXT "spf2.0/pra,mfrom +ip4:192.168.100.0/24 ~all"

・余分な空白文字

不要な箇所に空白文字が入れたためにエラーとなる場合があります。たとえば、以下の例ではカンマの後に余分な空白文字が入ったためエラーとなります。

【誤】 
example.jp.   IN TXT "spf2.0/pra, mfrom +ip4:192.168.100.0/24 ~all"

【正】 
example.jp.   IN TXT "spf2.0/pra,mfrom +ip4:192.168.100.0/24 ~all"

・記号の間違い

たとえば、“＝”と“：”を間違えて使用したためにエラーとなる場合が見られます。以下の例は、includeやredirectの使用時に見かけられるエラーです。

【誤】 
example.jp.   IN TXT " v=spf1 include=_spf.example.jp ~all"

【正】 
example.jp.   IN TXT " v=spf1 include:_spf.example.jp ~all"

【誤】 
example.jp.   IN TXT " v=spf1 redirect:example.com"

【正】 
example.jp.   IN TXT " v=spf1 redirect=example.com"
　

3.　チェック方法

SPFレコードを間違って設定した場合でも直ちに受信拒否などの影響が出るわけではありませんので、間違いに気付かない場合が多く見受けられます。そこで、公開したSPFレコードが正しいかどうかをまずチェックすることをお勧めします。SPFレコードによる認証結果を返す無料サービスがいろいろ存在しますので、以下にご紹介します。ただし、各サービスを推奨するものではなく、また、各サービスの利用およびこれにより生じた結果に際しては著者および（財）インターネット協会は一切の責任を負いませんので予めご了承ください。

SPFレコードチェック
<http://www.sendmail.co.jp/sa/spfcheck.html>

E-mail Authentication
<http://www.port25.com/domainkeys/>

MX Lookup
<http://www.mxtoolbox.com/>

SPF Record Testing Tools
<http://www.kitterman.com/spf/validate.html>

SPF Validation – Sender Profile Framework Testing and Checking Tool
<http://www.mydigitallife.info/tools/spf-validation-sender-profile-framework-testing-and-checking-tool/>

Beveridge Hosting – SPF Test
<http://tools.bevhost.com/spf/>

Sender Policy Framework : Tools
<http://www.openspf.org/Tools>