センドメール株式会社 (Sendmail, K.K.)
末政 延浩
2010年1月
1. SPFの背景
2. SPFの標準化
3. SPFの仕組み
SPF送信側の設定
4. SPFレコードの記述法
5. SPF受信側の処理
6. SPF認証結果
7. SPFにおける課題
転送問題
第三者サーバ利用問題
8. Sender ID とSPF
spf2.0とspf1
9. SPFの実装
10. SPFレコードの記述例
11. SPFレコードの間違い
有用な参照先
電子メールの送信者偽称を防ぐ送信ドメイン認証技術には、ここで説明する「Sender Policy Framework（SPF）」のほかに、「DomainKeys Identified Mail（DKIM）」、「Sender ID」など様々な方式が標準化されている。その中でもSPFは、他の方式に比べて既存システムに影響を与えず早期に導入できる点が評価されている。
1. SPFの背景
Sender Policy Framework（SPF）は、SMTPを利用したインターネット電子メールの送受信において送信者のドメインの偽称を防ぎ、正当性を検証する仕組みのひとつとして元Pobox社のMeng Wong氏により提唱された送信ドメイン認証方式である。
迷惑メールは、一般的に送信元アドレスを偽称して送信してくることが多い。送信元を偽ることで、受信者が迷惑メールの送信者を突き止めることを困難にするためである。インターネット上では、一般にSMTP（またはESMTP）で電子メールの配送を行う。SMTP通信による電子メールの配送では、送信者メールアドレスが2種類与えられる。電子メールのFrom:ヘッダー上に示される送信者アドレスと、SMTP通信でのMAIL FROM:コマンドの引数として与えられるメールアドレスである。SMTPでは、この2つが同じでなくてはいけないという規則はなく、また、一般に任意のアドレスを指定可能であるため送信者の偽称が非常に簡単に行える。
図1 インターネット電子メールでは送信者の偽称が可能 （図をクリックで拡大）
SMTP通信においてSPFの仕組みを利用すると、あるメールを受信したとき、本当にそのメールが、そのメールを配送しようとするSMTP通信において送信者であると唱えられているメールアドレス（エンベロープ送信者）のドメインから送られてきたものかどうかを確認することが可能になり、迷惑メール対策の実施を容易にする。
2. SPFの標準化
SPFは、IETFのMARID等において数々の議論と検討を経て、現在、実験的カテゴリのRFCとして（RFC 4408）標準化されている。SMTP通信において送信者のドメインの正当性を検証する技術を一般に「送信ドメイン認証（Sender Authentication Technology）」と総称するが、SPFはそのひとつであり、SMTP通信において送信側のホストのIPアドレスを基に認証を行うIPアドレスベースの認証方式のひとつとして分類されている。
3. SPFの仕組み
図2にSPFの動作の概要を示す。
図2 SPF送信ドメイン認証の仕組み （図をクリックで拡大）
送信側は、あらかじめ自ドメインの権威DNSサーバ上に自ドメインの送信者がメールを外部に向けて送出する可能性のあるメールサーバのIPアドレスの一覧を記述（公開）する。この宣言を行うDNSリソースレコード（RR）が「SPFレコード」である。受信者はメールの受信時、送信者として指定されたメールアドレスのドメイン部分に示されるドメインのSPFレコードをDNSより取得して、SMTP接続先のIPアドレスが取得したSPFレコードと一致するか確認することで、送信ドメインの認証を実施する。
なお、DNSにおいてSPFを宣言するものが「SPFレコード」である。ただし、現状で「SPFレコード」を実際に宣言するにはDNSの「SPFリソースレコード（SPF RR）」を使用する方法と「TXTリソースレコード（TXT RR）」を使用する方法の2通りが存在する。この違いを明確にするために、本稿では概念としてのSPF情報を示す場合には「SPFレコード」を使用し、DNSにおける具体的なリソースレコードとしての説明の際には「SPF RR」と「TXT RR」を使用するものとする。
■ SPF送信側の設定
メールの送信側としては、DNS上でSPFレコードを公開することだけでSPFの運用を開始できる。RFCでは、SPFレコードはDNSのTXT RRかSPF RRとして公開するよう定義されている。だが、現時点ではSPFという新しいリソースレコードを取り扱えないリゾルバやDNSサーバの実装が存在するため、SPF RRとTXT RRの両方を利用して公開する。
SPFレコードには、当該ドメインに属するメールアドレスを送信者とする電子メールをそのドメイン外に送出する可能性のある電子メール配送エージェント（MTA）の外向けのIPアドレスのリストを記述する。また、SPFレコードはSPF RRとTXT RRを使用して同時に公開可能であるが、SPF RRが存在する場合はTXT RRは廃棄される。SPFではIPv6を含むIPアドレスの直接記述や、その他、簡略に公開可能にする記述法を提供している。SPFレコードの簡単な記述例を次に示す。
example.com. IN TXT "v=spf1 -all" example.net. IN TXT "v=spf1 ip4:192.0.2.1 -all" example.jp. IN SPF "v=spf1 ip4:192.0.2.1 -all"
1つ目の例では、example.comをドメイン名として持つアドレス（たとえば user@example.com）からは一切メールを送信しないという意味であり、2つ目の例では、example.netをドメイン名として持つメールアドレス（たとえば user@example.net）からのメールは192.0.2.1のIPアドレスを持つホストからのみ送信されると意味を持つ。記述方法については、以降で詳細に説明する。
4. SPFレコードの記述法
SPFレコードは、次の構造を持つ。
バージョン 空白 定義 空白 定義 ・ ・ （以下繰り返し）
バージョンは、“v=spf1”である。このSPFレコードでの記述方法が、バージョン1の文法に従って定義されていることを示す。
RFC 4408で定義されているSPFレコードの文法はバージョン１のみであり、v=spf1以外の指定（たとえば“v=spf10”など）と記述するとそのレコードは不正であるとして廃棄される。重要な点は、文法的に誤ったSPFレコードを記述すると受信側ではそのSPFレコードを無効（PermError)として扱うということである。したがって、記述は慎重に行い、公開に際してはSPFの試験を行えるサイトなどを利用して試験を行い記述ミスが無いことを確認するべきである。
定義は、ディレクティブ（directive）と修飾子（modifier）で構成される。ディレクティブは、限定子（qualifier）と機構（mechanisms）で構成される。前述の例
example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" example.com. IN SPF "v=spf1 ip4:192.0.2.1 -all"
において、ディレクティブは“-all”と“+ip4:192.0.2.1”になる。“-all”においては、“-”が限定子であり、“all”の部分が機構である。“+ip4:192.0.2.1”においては、“+”が限定子であり、“ip4:192.0.2.1”が機構である。少し余談めくが、“+”の限定子は省略可能である。DNSレコードのサイズ制限などを考えると、省略できるものは省略したほうが良いと考えている。したがって、本原稿における記述例も“+”の限定子は省略した形で統一する。
修飾子の例としては、“redirect=example.com”などがある。認証処理では、定義は左から右へと評価される。与えられたIPアドレスに対して最初にマッチした定義の限定子が示す結果が認証結果として与えられる。いずれの定義にもマッチしない場合は、Neutralと評価される。
限定子
限定子は、それに続く機構にマッチした場合の認証結果を指定する。限定子について、その意味を次の表に示す。
| 表記 | 意味 | 意味 |
| + | Pass | 当該ドメインの送信メールサーバとして認証する |
| – | Fail | 当該ドメインの送信メールサーバとして認証しない |
| ~ | SoftFail | 認証情報を公開しているが、正当なメールであっても認証失敗する可能性もある |
| ? | Neutral | 認証情報を公開しない |
機構
機構には、認証対象の送信元ホストのIPアドレスと照合する条件を記述する。機構には次のものがある。
| 機構 | 引数 | 機能 |
| all | なし | すべての送信元ホストにマッチする。SPFレコードの末尾に置かれ、デフォルトの動作を定義するために利用される |
| include | ドメイン名 | 引数に与えられたドメインのSPFレコードを使って認証処理を行い、その結果がPassかTempError、またはPermErrorの場合のみ値が採用される。includeに指定された先のドメインのSPFレコードによってFailの判定が与えられても、それが認証結果としては採用されない |
| a | ドメイン名 | 送信元ホストのIPアドレスが、ドメイン名に与えられたFQDNのAレコードのいずれかであれば条件マッチする |
| mx | ドメイン名 | 送信元ホストのIPアドレスが、ドメイン名に対応するMXレコードに指定されているホストのAレコードのいずれかであれば条件マッチする。 MXは複数与えられる場合があるが、10個までのMXホストに対して検査を行う |
| ptr | ドメイン名 | 送信元ホストのIPアドレスをリバースルックアップし、得られたホスト名でさらに正引きを実施し、IPアドレスを得る。そのIPアドレスと送信元ホストのIPアドレスが含まれる場合、そのホスト名が引数に与えられたドメイン名と一致するかそのサブドメインである場合、認証成功となる。リバースルックアップに失敗した場合はFailとみなす。負荷の多い処理となるため、あまり利用は推奨されない |
| ip4 | IPネットワークアドレス（CIDR表記可能）またはIPアドレス | 送信元ホストのIPアドレスが、引数に指定されるIPネットワークに含まれているかIPアドレスにマッチする場合、認証成功となる |
| ip6 | IPv6ネットワークアドレスまたはIPv6アドレス | 送信元ホストのIPv6アドレスが、引数に指定されるIPv6ネットワークに含まれているかIPv6アドレスにマッチする場合、認証成功となる |
| exists | ドメイン名 | 引数であるドメイン名に指定された表記でAレコードルックアップを実施し、該当のAレコードが存在すればマッチする。SPFのマクロ機能とあわせての利用を想定している |
修飾子
修飾子について次に示す。
| 修飾子 | 文法 | 機能 |
| redirect | redirect=ドメイン名 | 引数であるドメイン名に指定されたドメインのSPFレコードにより認証処理を実行する。複数のドメインが、1つのSPF定義を共有するような場合での使用を想定している。この修飾子を利用する場合、SPFレコードの末尾に配置することが推奨されている |
| exp | exp=ドメイン名 | 認証が失敗した場合、引数であるドメイン名に指定されたドメインのTXT RRに設定されている文字列を、認証失敗した理由や説明等として利用する。SMTPセッションでのエラーメッセージなどでの利用を想定している |
5. SPF受信側の処理
受信側は、SMTP接続してくる相手のIPアドレスと、SMTP通信でのMAIL FROM:コマンド（およびHELOコマンド）の引数として与えられるドメイン名（FQDN）を元に認証を実施する。ドメイン名を元にSPFレコードを取得し、相手ホストのIPアドレスと照合して認証結果を得る。
SMTP接続の相手のIPアドレスを知る必要があるため、SPF認証は受信するドメインにおいてインターネットに直接アクセスしているMTAにて実施する。MAIL FROM:コマンドの引数から認証対象になるドメイン名が得られない（たとえば、エラーメールであるDSNはエンベロープ送信者が<>アドレスであり、認証対象のドメインが得られない）場合、RFCにおいてはHELOコマンドの引数であるFQDNを対象にして認証を行うように定義されている。ただし、一般にHELOコマンドの引数は該当ホストのFQDNである場合が多く、ドメイン名ではなかったり、正しく設定していなかったりするために認証に利用できないケースが多く、そうした処理をあえて実施しない実装も存在する。
6. SPF認証結果
認証結果は次のものが存在する。
| 認証結果 | 意味 |
| None | SPFレコードが公開されていない |
| Neutral | SPFレコードが“?”として公開されている条件にマッチした |
| Pass | 認証処理に成功した |
| Fail | SPFレコードが公開されているが、認証に失敗した |
| SoftFail | SPFレコードが“~”として公開されている条件にマッチした |
| TempError | 一時的な障害で認証処理が失敗した |
| PermError | SPFレコードの記述に誤りがあるなどで認証処理に失敗した |
それぞれの処理結果について説明する
None
SPFレコードが公開されていないため、認証できなかったことを示す。送信ドメイン認証では送信元についての評価が下せないため、従来どおりスパムフィルタを通すなどしてメールの扱いを決定する。結果がNoneだったからといって、メールを即座に受信拒否すべきではない。
Neutral
送信ドメインのSPFレコードが、たとえば“v=spf1 ?all”のように定義されている場合、あるいは“v=spf1 +ip4:192.0.2.1 ?all”のようにレコードの末尾が“?all”と定義されていて、先立つ他の条件にマッチせず“?all”にマッチした場合、Neutralとなる。
RFCでは、NeutralはNoneと同じように扱うべきであるとされている。また、SoftFailよりは正当性が高いものとして扱う可能性があるとも説明されている。結果がNeutralだった場合には、メールを即座に受信拒否すべきではない。
Pass
送信元のIPアドレスがSPFレコードにマッチし、認証に成功した場合である。送信ドメインは認証されたと評価できる。しかし、送信元のドメインが認証されたとしても、そのメールの内容（本文等）についてはSPF認証結果が保証するものではないことには注意が必要である。迷惑メール送信者もSPFレコードを公開できるという現実を考慮し、認証されたドメインに対してホワイトリストやブロックリスト、また、ドメインのレピュテーションなどと組み合わせて、受信したメールの最終的な処理方法を決定すべきである。認証されたドメイン名によってホワイトリストやブロックリスト等の運用がより正確に行える。
Fail
SPFレコードが公開されているが、送信元のIPアドレスが“-”限定子の条件にマッチする場合である。SPFレコードを公開していない場合、また、“?all”や“~all”が末尾に設定されているSPFレコードが公開されているドメインからのメールに対しては、この結果は発生しない。つまり、送信元のドメインを偽称している可能性が非常に高いと見なすことができる。RFCにおいてはこの結果に従って通信中のSMTPセッションにおいて該当メールの受信拒否を行う場合、550番エラーの利用を勧めている。
SoftFail
SPFレコードが公開されており、送信元のIPアドレスが“~”限定子の条件にマッチする場合である。RFCでは、FailとNeutralの中間位の扱いをすべきであるとされている。結果がSoftFailである場合には、メールを即座に受信拒否すべきではない。
TempError
一時的な障害で認証処理が失敗した場合である。対応としては、メールを一時エラー（4XX）で受信拒否するか、そのまま受信することになる。受信した場合は、少し厳しく扱うべきである。
PermError
SPFレコードは公開されているが、SPFレコードの記述に誤りがある場合などにPermErrorとなる。この結果であっても、永続的な受信拒否をすべきではない。
一般的に、SPF認証はインターネットに直接アクセスしているMTAで実施する。RFCでは、SPF認証はSMTPの通信中に実施すべきとされており、さらに、SPFの認証結果に従って何らかのアクション（受信拒否など）を行う場合は、メールを受信し終わった後ではなく、そのSMTP通信中に実施することを勧めている。そうすることで、メールを受信したのち、偽称されている送信者に対してエラーメールを返送することを防ぐことができる。
認証結果によって通信中のSMTP接続においてメールの受信拒否を行わない場合、認証結果は該当のSMTP通信で配送されてきたメールのヘッダに記録することを想定している。RFC4408では”Received-SPF”ヘッダを利用してメールに記録することが勧められているが、その後の検討により、送信ドメイン認証（SPF、DKIM、Sender ID等）やその他電子メールに関連する認証結果を記録するヘッダとして、Authentication-Resultsヘッダを利用することがRFC 5451にて標準化されたため、現在では、Authentication-Resultsヘッダに記録することが実装における主流となっている。それぞれのヘッダの書式については、それぞれのRFCを参照されたい。
7. SPFにおける課題
■ 転送問題
SPFでは、送信元のIPアドレスを元に認証を行うため、認証時に送信元ホストが本来の送信元に属していないようなケースでは認証に失敗する。
図3 転送時の問題 （図をクリックで拡大）
これについてSPFでは、Sender Rewrite Schemeという仕組みが提供されている。ただし、これには転送時にエンベロープ送信者アドレスについてやや複雑な書き換えが必要であり、既存のMTAの大幅な機能変更が必要になるため、現時点ではほとんど普及していない。
現実的には、転送する際にオリジナル受信者をエンベロープ送信者として置き換えて送信するなどの対処が勧められる。また、メーリングリストでも同様の原因で投稿したメールをメンバーに再配布する際に認証不能になるため、メーリングリストサーバでは、配布時にエンベロープ送信者をそのメーリングリストを運営するドメインのメールアドレスに書き換えるなどの対処が勧められている。
■ 第三者サーバ利用問題
転送時と同様に、たとえばビジネスで、出張先のホテルや自宅などから自身がプライベートで利用しているISPのメールサーバを利用しながら、かつ、会社で利用しているメールアドレスを送信者にして送信すると、エンベロープの送信者のドメインに紐付くSPFレコードにはISPのメールサーバのIPアドレスは一般に含めることができないため、認証に失敗する。
ただし、こうした利用法は潜在的に情報漏洩につながる可能が高いため、本来は、会社側の正規のメールサーバが利用可能なように、VPNやSSL通信を利用したサブミッションポートでのメールの送信を会社のシステムにて提供可能にしておくことが重要である。
8. Sender ID とSPF
Sender IDは、マイクロソフト社が提案したネットワーク方式の送信ドメイン認証である。Sender IDの仕様は、SPFのRFC 4408と同じく実験的RFCとしてRFC 4406とRFC 4407にまとめられている。SPFの影響を強く受けており、送信側ではSPF（RFC 4408）で規定されているSPFレコードを利用して認証情報を公開できる。さらに、Sender ID独自の送信側宣言書式もあり、“spf2.0”として定義されている。
SPFとSender IDの大きな違いは、SPFがエンベロープの送信者アドレスを対象に認証するのに対し、Sender IDではヘッダ上の送信者アドレスを対象に認証する。実際に受信者が見るヘッダ上のアドレスを検査することで、フィッシィング対策としての効果を強める狙いがある。
また、複数の送信ヘッダ（Purpoted Responsible Address、PRAと呼ばれる）を利用することで転送時問題を回避できる。RFC 4407は、このPRAの扱いを定義したRFCである。ヘッダに対して認証処理を行うため、SMTP通信上では、メールデータをある程度読み込んだうえでないと認証が行えない。したがって、MAIL FROM:コマンドを受信した段階で認証結果が得られるSPFに対して、ややシステム負荷が高いといえる。
■ spf2.0とspf1
Sender IDでは、SPFで定義されているSPFレコードをspf1（バージョン1）として扱い、Sender IDのSPFレコードを“spf2.0（バージョン2.0）”として扱う。
spf1のレコードしか公開していないサイトからのメールについてもSender IDでは認証対象としており、その場合、spf2.0/mfrom,pra として扱うとしている。ひとつのサイトにおいて、spf1とspf2.0の2つのSPFレコードを同時に公開できる。ただし、spf2.0のレコードは受信側がSender IDの認証処理を行う場合にのみ有効であり、受信側がSPFの認証のみを行う場合では無視される。以下にspf2.0とspf1のレコードの例を示すが、バージョンの宣言方法が微妙に異なるので公開するときは間違えないように気をつける必要がある。
(spf2.0) example.org. IN TXT "spf2.0/pra include:example-example.org -all" (spf1) example.org. IN TXT "v=spf1 include:example-example.org -all"
9. SPFの実装
SPFの実装としては、SPFの仕様ドラフトの段階から試験的な実装として提供されていたsenderid-milterや、IIJの山本氏らが中心になって開発を進めたENMAなどがある。どちらもsendmailのMilter APIをサポートしているメールフィルターである。Milter APIをサポートしているsendmailやPostfixといったMTAと共に利用できる。
IIJ、送信ドメイン認証機能を実装するメールフィルタプログラムを無償公開
http://www.iij.ad.jp/news/pressrelease/2008/0828.html
senderid-milter
http://sourceforge.net/projects/sid-milter/
10. SPFレコードの記述例
記述ミスを防ぐため、なるべくシンプルにSPFレコードを記述するよう心がける。includeやredirect、また、マクロの機能等については間違いを起こしやすいので本当に必要な場合にのみ利用する。
ip4やip6の記法で簡潔に記述することを推奨する。 一般的な企業で、外部の業者にメールの送信を委託したりしない場合、次のような記述法を推奨する。
Sample 1: ホストのIPアドレスで記述
メールを外部に送出するメールサーバのIPアドレスを直接指定する。送信メールサーバ数があまり多くない場合は、記述ミスを防ぐためや、受信側でのDNSクエリを抑制するため、この記述方を強く推奨する。
example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 -all"
Sample 2: ホスト名で記述
メールを外部に送出するメールサーバのホスト名を指定する。前述のIPアドレス直接指定に比べてメンテナンスが簡単であるが、受信側の認証処理においてDNSへの負荷が少し増える可能性がある。ホスト名は必ずFQDNで指定する。
example.org. IN TXT "v=spf1 a:mx01.example.org a:mx02.exmaple.org a:ns.example.org -all"
Sample 3: ネットワークでの指定
メールを送出する可能性のあるホストが存在するネットワークをCIDR方式で指定する。
example.org. IN TXT "v=spf1 ip4:192.0.2.0/28 -all"
“d”にあまり小さい値を指定すると（つまり、ネットワークの領域を広く指定すると）SPFレコード自体の意味が無くなるため。最小限のネットワーク範囲で利用する。
Sample 4: ホストのIPアドレスとネットワークアドレスの混在
ネットワークの指定と、ホストのIPアドレスの指定を混在させることも可能である。
example.org. IN TXT "v=spf1 ip4:192.0.2.101 ip4:192.0.2.102 ip4:192.0.2.103 ip4:192.0.2.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"
顧客へのアナウンスメールやキャンペーンメールを外部業者に委託しているような組織の場合、それらの配信メールの送信元サーバのIPアドレスをSPFレコードに追加する必要がある。しかし、外部業者が多数にのぼる場合など、レコードの管理が複雑になることが考えられるため、可能であれば、それらの業者ごとに専用のサブドメインを払い出して、本来の業務用のドメインと切り離して管理するという方法もある。
業者がすでにSPFレコードを公開していれば、includeを利用してそのレコードを利用できる。ただし、includeする場合、参照先のSPFレコードに記述ミスが無いか、includeやredirectで参照元を相互参照していたりしないかといったことを十分に確認した上で行うこと。
Sample 7: サブドメインに個別のSPFレコードを定義する
サブドメインに個別のSPFレコードを定義する場合の記述例を以下に示す。
example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 -all"
announce.example.org. IN TXT "v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 -all" campaign.example.org. IN TXT "v=spf1 include:advertise.example.com -all"
Sample 8: redirectを利用してマルチドメイン環境での記述を簡略化する
次に、単独の企業でも複数のドメインを利用している場合がある。複数のドメインのメールで1つのメールシステムを共有するケースでは、redirectを利用して共有化を図ることでメンテナンスの負荷を軽減し記述ミスを防ぐことが考えられる。
ただし、参照先が必ず存在するように気をつける、また、相互参照によって参照のループを発生さないように、参照先のレコードではincludeやredirectを利用しないようにする。
example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 -all"
example.net. IN TXT "v=spf1 redirect=example.org" example.com. IN TXT "v=spf1 redirect=example.org"
Sample 9: 大きなレコードを複数の文字列で記述する
通信業者や大きな組織ではメールサーバの台数が多く、SPFのレコードサイズが大きくなる可能性がある。SPFのRFCにおいて、1つのSPFレコードでは複数の文字列を含むことが可能であり、1つの文字列の最大長は255バイトであると説明されている。1つのSPFレコードが複数の文字列で構成されている場合、認証を実施する受信側ではその文字列はすべてつなぎ合わせて1つの文字列として評価する。ただし、複数の文字列を1つの文字列に連結するとき、そのつなぎ目に空白文字は挿入されないので注意が必要である。
example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3" " ip4:192.0.2.4 ip4:192.0.2.5 ip4:192.0.2.6" " include:example.net -all"
Sample 10: 大きなレコードをサブドメインを利用して記述する
さらにRFCでは、連結したあとの1つのレコードが450バイト以下であることが目安とされている。DNSのクエリに対する応答が全体で512バイト以下でないと、フラグメーテーションの影響によってDNS応答の後半部が切り捨てられてしまう可能性があるからだ。450バイトを超えるような長いレコードを記述するのはあまり勧められないが、どうしても必要な場合はサブドメインを定義してそれらにレコードを分割して記述した上で、それらをincludeするような対応も考えられる。
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:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 ip4:192.0.2.4 -all" _spf-b.example.org. IN TXT "v=spf1 ip4:192.0.2.11 ip4:192.0.2.12 ip4:192.0.2.13 ip4:192.0.2.14 -all" _spf-c.example.org. IN TXT "v=spf1 ip4:192.0.2.21 ip4:192.0.2.22 ip4:192.0.2.24 ip4:192.0.2.24 -all"
繰り返すが、相互参照やループの発生を防ぐため、include文を利用する場合、参照先ではなるべくinclude文やredirect文を利用しないようにする。
11. SPFレコードの間違い
文法的に間違ったSPFレコードを公開すると受信側ではPermErrorと扱われ、せっかく公開しても正しく扱われない。以下に、間違いやすい例を示す。
Sample 1: バージョンの間違い（その1）
【誤】example.org. IN TXT "v=spf1.0 include:example.net -all"
“v=spf1.0”は間違っており、“v=spf1”でなければいけない。
【正】example.org. IN TXT "v=spf1 include:example.net -all"
Sample 2: バージョンの間違い（その2）
【誤】example.org. IN TXT "v=spf2.0/pra include:example-example.org -all"
spf2.0のレコードを公開する場合、上記のようなバージョンの記述“v=spf2.0/pra”は間違っており、正しく“spf2.0/pra”でなければいけない。
【正】example.org. IN TXT "spf2.0/pra include:example-example.org -all"
Sample 3: 機構が省略されている
【誤】example.org. IN TXT "v=spf1 mx nm nm1 ~all"
上記の例では、機構が省略されているうえにドメイン名がFQDNではないため、エラーとなる。“+a:ホスト名（FQDN）”と記述する必要がある。
【正】example.org. IN TXT "v=spf1 +mx +a:nm.example.org +a:nm1.example.org ~all"
Sample 4: 1つのドメインに対して複数のspf1レコードを公開している
【誤】example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all" example.org. IN TXT "v=spf1 a:mx01.example.org ~all" example.org. IN TXT "v=spf1 a:web.example.org ~all"
1つのドメインに対しては1つのspf1レコードだけが公開可能である。複数公開すると、エラーとなる。ただし、spf2.0のレコードとspf1のレコードを1つずつ同時に公開することは可能である。
【正】example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 a:mx01.example.org a:web.example.org ~all"
または、以下のように記述する。
【正】example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 a:mx01.example.org a:web.example.org ~all" example.org. IN TXT "spf2.0 ip4:192.0.2.1 ip4:192.0.2.2 a:mx01.example.org a:web.example.org ~all"
Sample 5: タイプミスの例
【誤】example.org. IN TXT "v=spf1 ipv4:192.0.2.1 mx ~all"
“ipv4:”は間違い。
【誤】example.org. IN TXT "v=spf1 ip:192.0.2.1 mx ~all"
“ip:”は間違い。
【誤】example.org. IN TXT "v=spf1 ip192.0.2.1 mx ~all"
“:”が抜けている。
【誤】example.org. IN TXT "v=spf1 ip4=192.0.2.1 mx ~all"
“:”の代わりに“=”を使っている。
【誤】example.org. IN TXT "v=v=spf1 ip4:192.0.2.1 mx ~all"
“v=v=”とバージョン記述を間違えている。
【誤】example.org. IN TXT "v=spf1 ip4"
書きかけで終わっている。
【誤】example.org. IN TXT "v=spf1 ip4:192.0.2.1 mx \150all"
“~”が文字化けしている
“ip4:”を“ipv4:”や“ip:”などと間違えるケースは非常に多く見受けられる。最後の例のように、レコードを作成するために使ったツールなどが“~”文字を間違って変換してしまう場合などもあるので、注意が必要である。
【正】example.org. IN TXT "v=spf1 ip4:192.0.2.1 mx ~all"
Sample 6: 空白文字（SP）が抜ける
【誤】example.org. IN TXT "v=spf1 ip4:192.0.2.64/26" "ip4:192.0.2.101 ~all"
上記のように二重引用符で複数に分けて記述することは可能だが、そうした場合、“ip4:192.0.2.0/26”と“ip4:192.0.2.101 ~all”は“v=spf1 ip4:192.0.2.64/26ip4:192.0.2.101 ~all”という大きな1つのレコードとして扱われる。” ” でくくられた2つの部分を接続するとき空白文字は補われないため、区切り文字として空白文字が入らない。
【正】example.org. IN TXT "v=spf1 ip4:192.0.2.64/26 ip4:192.0.2.101 ~all"
Sample 7: redirectやincludeの先がない
【誤】example.org. IN TXT "v=spf1 include:_spf.example.org ~all"
* Can’t find _spf.exmaple.org: Non-exisitent domain
includeしている_spf.example.orgのレコードが存在していないためにエラーとなる。公開当初は存在したが、その後のDNSレコードの整理などでの変更を反映していないことなどが原因として考えられる。
Sample 8: redirectやincludeのループ（相互参照）
【誤】example.org. IN TXT "v=spf1 include:_spf.example.org ~all" _spf.example.org. IN TXT "v=spf1 include:example.org ~all"
example.orgと_spf.example.orgがお互いに相手を参照し合っているためにエラーとなる。
有用な参照先
- RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
http://www.ietf.org/rfc/rfc4408.txt - SPF Project Overview
http://www.open-spf.org/
※2019年にopenspf.orgはopen-spf.orgへ移行しました。
https://www.getmailbird.com/what-spf-resources-are-available-now-that-openspf-org-is-gone/