Sender Policy Framework
Sender Policy Framework（センダー・ポリシー・フレームワーク）とは、電子メールにおける送信ドメイン認証のひとつ。差出人のメールアドレスが他のドメイン名になりすまししていないか検出する技術である。 SPF もしくは SPF認証 とも呼ばれる。
インターネット上の電子メールに用いられる「SMTP」は、差出人のメールアドレスを誰でも自由に名乗ることができる。これが事実上の標準として普及したため、セキュリティ上の欠陥として表面化することになった。これにより、迷惑メール送信者、いわゆる「スパマー」による差出人アドレスの詐称が世界各地で行われ、利用者を悩ませてきた。
そのため、議論は次第に本格化し、対策のひとつとして、SPFが登場した。これは、IPアドレスの詐称は難しいという前提のもとに策定されており、原則として、DNSサーバ上に記載される情報を取得するだけで、認証を完了できる。SPF対応したドメインにするには、そのドメインが属するDNSサーバ内のゾーンファイルに対して、 SPFレコード と呼ばれる構文を追記することで容易に実装できる。
SPFは、全ての迷惑メールを防御できるわけではない。SPFが行うのは、あくまで「差出人アドレスに記載されたドメイン名を読みとり、正しいメールサーバから送信されているかどうかを検出すること」である。そのため、例えば大企業や政府などのドメインになりすました電子メールを経由したフィッシング詐欺などには効果があるものの、差出人アドレスを詐称していない迷惑メールは検出できない。また、同一ドメイン内で、アカウント部分のみを詐称してメール送信ができる場合、SPFでは検出ができない。
しかし、SPFは、ドメイン所有者側での対応が比較的容易であることもあり、普及は進んでいると言える。日本においては、携帯電話事業者を中心に、電子メールで用いられるフィルタリングサービスのひとつとして提供されており、「ドメイン認証」のほか「なりすましメール対策」などと称されて急速に普及している。
SPFは、RFC 7208で定められており、その仕様が公開されている。
SPFレコードの一般的な内容を示す。以下の内容が指定されたドメインは、「指定したIPアドレス帯域から送信された電子メールなら信頼して欲しいが、それ以外のIPアドレスからの電子メールは拒否して欲しい」と宣言することになる。
実際にSPFレコードを反映したゾーンファイルの、一般的な内容を示す。以下の内容が指定されたドメインは、「 203.0.113.1 または 203.0.113.2 から送信された電子メールは信頼して欲しいが、それ以外のIPアドレスからの電子メールは拒否して欲しい」と宣言することになる。
古いDNSサーバとの互換性を維持するため、SPFレコードは450文字以内に収めることが推奨される。しかし、DNSサーバのTXTレコードは、1行につき255文字しか記入できないことに注意を要する。例として、電子メールを送信するIPアドレス帯域が非常に多くあり255文字を超える場合には、以下のようにレコードの途中でダブルクウォートを閉じ、区切りながら記述する必要がある。区切られた部分は、DNSサーバによってそのまま結合され解釈される。
以下の内容が指定されたドメインは、「 sp.example.jp や sp.example.com で指定されている SPF レコードの記述に準じる」と宣言することになる。後述するが、ip4 ip6 all 以外の項目が1レコード内に10個を超えてはならない。
SPFは、あるドメインのための電子メールを送信することが正式に認められているマシンはどれかという事（以下送信者ポリシー）を、ドメイン所有者が専用の書式を使ってDNSのTXTレコードに明示することを可能にする。例えば、送信者アドレスが「〜@example.jp」で終わっている電子メールを送信することを、正式に認めていないマシンはどれかということを、「example.jp」所有者が指定できる。SPFを検証する配送先メールサーバは、電子メールの通信文を受け取る前に、権限がないマシンから届いた電子メールを拒否することができる。したがって動作原理は、SPFが本当のDomain Name Systemの権威委任を利用することを除いて、DNSブラックリスト（DNSBL: DNS-based Blackhole List）による物と全く同様である。
SPFは、エラーメールの通知先である Return-Path のメールアドレスを保護する。
送信者アドレスはSMTPによる通信を開始する最初に伝えられる。もし送信先メールサーバがその送信者アドレスを拒否する場合は、権限のない送信元メールサーバはエラーメールをそのメールアドレスに送信するべきである。もし送信先メールサーバがその送信者アドレスを受け入れ、また続けて宛先メールアドレスと通信文も受け入れる場合は、送信者アドレスを保持するためにReturn-Pathヘッダを挿入するべきである。Return-Path のメールアドレスは、「From:」や「Sender:」のようなメールヘッダの発信者メールアドレスと一致することが多いが、必ずしもそういう訳ではない。またSPFはこれらのメールアドレス詐称を防止するものではない。
スパマーは、送信者ポリシーが記載されているドメインのアカウントを持っていたり、そのドメイン下の危殆化したシステムを不正利用することで、SPFの検証に合格（Pass）する電子メールを送信できる。また、登録ユーザーに対して任意の送信者アドレスからのSPF認証を合格させるようなサービスを提供する不正な認証サーバーを経由することでも、SPFの検証に合格する電子メールを送信できる。しかしながら、そうして作られた迷惑メールは、送信元メールサーバを容易に特定できる。
SPF の主な利点は、Return-Path の詐称にメールアドレスが使われる人々にもたらされる。彼らは頼んでもいない膨大なエラーメールやその他の自動返信メールが送りつけられ、それが電子メールを普通に使うことを難しくしている。もしそのような人々が、正規の送信IPアドレスと同時に、検証に不合格（Fail）するそれ以外の全IPアドレスをSPFレコードに明示すれば、SPFを検証する配送先メールサーバが詐称メールを拒否できるようになり、後方散乱メールの総量が減少する。
SPFは、迷惑メールの身元確認の助けとなる域を越えて、利益をもたらす可能性がある。特に送信者がSPF情報を提供する場合は、配送先メールサーバはSPFの検証に合格した結果を、既知の信頼できる送信者を識別するためのホワイトリストに結合して使うことができる。しかし、危殆化したシステムや共有メール送信システムのようなものは、この使い方を制限するだろう。
あるドメインが検証に不合格となるSPFレコードを宣言した場合、そのドメインから送信され、配送先メールサーバから第三者へ転送された正当な電子メールは、以下の条件で配送が拒否され、エラーレスポンスが返されることがあり得る。
(1)メーリングリストと異なり、転送元メールサーバがReturn-Pathを書き換えない
(2)転送先メールサーバのホワイトリストに転送元メールサーバが存在しない
(3)転送先メールサーバがSPFを検証する
これは必要にして明確なSPFの特徴である。配送先の「境界」メールサーバ（メールエクスチェンジャ〈MX 〉）の背後では、SPFを直接検証することはできない。
SPFの検証に不合格となる宣言をする者は、潜在的な問題を受け入れなければならない。彼らは全ての配送先メールサーバが転送処理を変更することを要求することはできない。つまり少なくともここに挙げた三つの重大な条件の内一つは明白である。
センダー・リライティング・スキーム (SRS) と呼ばれる手法は、メール転送サービスがこの問題を回避するための方法である。
エラーメールやその他の自動返信メールで用いられる空（から）のReturn-Pathのため、HELOアイデンティティによるSPF検証はほぼ義務と言える。「HELO mail.example.jp」や「EHLO mail.example.jp」では、実際には人為的に「postmaster@mail.example.jp」を検証する。
偽のHELOアイデンティティではSPF無し（None）結果は役に立たないが、有効なホスト名のために、SPFはHELOアイデンティティを保護する。このSPFの特徴は配送先メールサーバのための選択肢として常に対応され、また後のSPF草案では常にHELOを検証することが推奨される最終仕様が含まれた。
これはHELOに合格することに基づいた送信元メールサーバのホワイトリストや、またHELOに不合格となる全てのメールサーバを拒否することを可能とする。格付け（レピュテーション）システムに使われることもできる。（ホワイトリストやブラックリストは格付けシステムの単純な事例である）
SPFの実装は2つの部分から成る。
ドメインが彼らを代表して電子メールを送信するために正式に認めたメールサーバを特定する。ドメインは彼らの既存のDNS情報へこの付加情報を追加する。
配送先メールサーバはSPF情報を要求しそれを用いることができる。メールサーバは普段どおりのDNS問合せを使い、一般的にはDNSの性能向上のためにキャッシュされる。配送先メールサーバはSPFに記載された情報を解釈し、その結果に従い行動する。
このように、ドメインが設定し配送先メールサーバが用いる、新しいDNS情報の仕様がSPFの核心である。SPFレコードは下記のように標準的なDNS構文で設定される。
example.jp. IN TXT "v=spf1 a mx -all"
「v=」は使用されたSPFのバージョンを定義する。以下の語は、あるドメインが電子メールを送信する資格があるかどうかを、決定するために用いる機構（Mechanism）を規定する。「a」および「mx」は、所定のドメインのために電子メールを送信することが許可されたコンピュータシステムを示す。SPFレコードの最後にある「-all」は、もしそれまでの機構が一致しなければ、メッセージは拒否されるべきということを示す。
8つの機構が定義されている。
各々の"機構"は4つの"限定子"の内1つと結合させることができる。"変更子"はSPFの将来の拡張を考慮する。これまでのところ、RFC 7208で定められた2つの"変更子"については、広く展開された。
「exp=some.example.jp」は、DNSのTXTレコードにドメイン名を挙げる。それはSMTPエラーコードに加え失敗（Fail）の説明（一般的にはURL）を得るためにSPFのマクロ言語を用いて解釈される。この過度に装飾的な機能はほとんど使われない。
「redirect=some.example.jp」は、他ドメインのSPFレコードに「all」を結び付ける代わりに使うことができる。この"変更子"は幾らか類似した"機構"である「include」を理解するより簡単である。
SPF実装がSPFレコードの文法エラーを検出すると、直ちに恒久的エラー（PermError）として評価を中断しなければならない。誤っている"機構"を読み飛ばして続けると、その結果は予想できない。したがって「include:bad.example」や「redirect=bad.example」もまた「PermError」となる。
その他の安全策としては、DNSへ問合せる機構、すなわち「ip4」「ip6」「all」以外のあらゆる"機構"が、SPFレコード当たり最大10までに制限されている。SPF実装では、評価が長時間に渡る場合やDNSの問合せがタイムアウトとなった際に、一時的エラー（TempError）として評価の中断ができる。もしSPFが直接または間接的に10を超える問合せを必要とした場合は恒久的エラー（PermError）を返さなければならない。「redirect=」もまたこの"処理制限"に数えられる。
標準的なSPF宣言である「v=spf1 a -all」は、(1)TXTレコード、(2)SPFレコード、(3)AまたはAAAAレコードのように、DNS問合せが3回必要である。この最後のDNS問合せの数は、最初の"機構"から制限（10）に向かって合計された物であり、今回の例では「all」がDNS問合せを必要としないため、最初の機構が最後でもある。
SPFは通常は送信者アドレス（Return-Pathに表示されるenvelope sender）のドメインが正当であると確認するだけである。送信メールサーバを共有するドメイン（例えば仮想ホスティング）は、それぞれ別々のドメイン名を名乗ることができる。SPFはネットワーク層で機能するため、送信者と称された人から所定の電子メールが実際に届くのかどうか確認しない。
検証に不合格となる宣言は、効果的な物となり得るが危険な手段でもある。そこで危険を回避するため、Failの代わりに（限られた試験期間のために作られた）SoftFailが宣言されることがある。しかしFailとなった電子メールを配送先メールサーバが拒否し、SoftFailとなった電子メールは迷惑メールの可能性がある物として受け入れることで、SoftFailはFailより以上に危険な物となり得る。
転送メールを拒否した時の挙動は明白である。その場合は、転送元のメールサーバはReturn-Pathで示されたメールアドレスにエラーメールを送信する。一般的なエラーメール（レスポンス）には、SMTPエラーの説明と配送に失敗した（転送先の）アドレスが含まれる。通常のSMTPエラーコードである「551 User not local; please try 」を模倣して、元の送信者は転送元のメールサーバを迂回し、転送先アドレスへ直接電子メールを再送することができる。
しかしながら、"迷惑メールの可能性がある物"として受け入れたSoftFailの電子メールは、最終的な受信者によって削除されることもある。SPFを考慮しない転送設定の経験がある利用者は、"迷惑メールの可能性がある物"とされた電子メールを、注意深く確認せずに簡単に削除することもある。
同じ論法は、本当の検証不合格メールを拒否するために配送先メールサーバはSPF提案を受けるべきということも示唆する。迷惑メールの可能性がある物として検証不合格メールを受け入れることは、検証不合格メールを簡単に拒否する事よりさらに危険となり得る。送信者ドメインにおいて検証に不合格となる宣言がされていて、それが何を意味するか知った上で宣言されていると期待できる場合は、検証不合格となったとしても、それは明らかにSPFを考慮しない転送設定により転送された物ではない。
「境界」メールサーバ（メールエクスチェンジャ〈MX 〉）の背後でSPFを検証することは不可能ではない。通常、検証に関係する情報は、配送された電子メールにメールエクスチェンジャが追加した、Receivedヘッダ行に記される。しかしこの場合、検証不合格メールを拒否するのは非常に時間が掛かり、検証地点においては原則として検証不合格メールを削除することだけ可能である。
専門家はこの権利を得られるべきだが、"プラグ・アンド・プレイ"ができる状況ではない。したがってSPF仕様では、メールエクスチェンジャの後ではなく、SMTPセッション中のメールエクスチェンジャだけが、SPFの検証をすることが推奨されている。もしSPFレコードの宣言者が彼らの方針の改善を計画する時に、一緒にDNSキャッシュの満了を考慮して慎重に計画しないと、メールエクスチェンジャの後でSPFを検証することは予想外の結果を得ることもある。
2006年のIETF Internet-Draft（SPFがDoSを引き起こす危険性〈SPF DoS Exploitation 〉）では、SPFに関するDNS回答の規模によっては、SPFをDNSへ打撃を与える手段とするネットワーク攻撃に繋がるという懸念について議論された。この問題は、SPFに関するRFCの「セキュリティに関する考察」（Security Considerations）でも取り上げられている。SPFプロジェクトはこの草案の詳細な分析を行い、SPFはDNSサービス拒否攻撃の原因とならないという結論を下した。
この結論で見落とされていることは、SPFの機構は10個までに制限されているが、それぞれの機構が名前解決をするごとに10個のDNS問合せが行われ、攻撃対象に対して合計100個の問合せを一度に引き起こすかもしれないということである。その上、送信者アドレスのlocal-part（@の左側部分）に展開されるマクロ文字は、それ以降の問合せを無作為化するために用いることができるため、スパマーの資源は何も消耗されない。そのようなネットワーク通信は、DNSは問合せより回答の方がデータ量が多い（つまりデータ量を増幅させる）という特性を悪用した攻撃（DNS amplification attack）を無限に引き起こすことを意味する。この起こり得る弱点の重大性は他の通信規約（ネットワーク・プロトコル）ではみられない物である。
2003年に開催されたYAPC（Yet Another Perl Conference）とOSCON（O'Reilly Open Source Convention）において、SPFの概念が紹介された。2002年にポール・ヴィクシー（Paul Vixie）により著された"Repudiating Mail-From"（『Mail-Fromの否認』）という短い論説である。その前身は、Hadmut Danischによる"Reverse MX"（RMX）と、Gordon Fecykによる"Designated Mailer Protocol" （DMP）であった。
2003年6月、メン・ウェン・ウォン（Meng Weng Wong）はRMXとDMP仕様を融合し、他のプログラマからの提案を求めた。その後6ヶ月以上に渡り多くの改良が為され、コミュニティはSPFの取り組みを始めた。
当初、SPFは"Sender Permitted From"の略であり、時には"SMTP+SPF"とも呼ばれた。その後2004年2月には、SPFの正式名称が"Sender Policy Framework"に変更された。
2004年前半には、Internet Engineering Task ForcIETFはMARID（MTA Authorization Records in DNS）ワーキンググループを組織し、SPFとマイクロソフトのCallerID提案を基にして、現在Sender IDとして知られていることの制定を試みた。
しかしMARIDによる検討が失敗に終わり、SPFコミュニティは元の"Classic"バージョンのSPFに立ち返り、RFC化を目指すことを決定した。2005年7月にはClassicバージョンの仕様がIETF experimentとしてIESGにより承認、そして2006年4月28日、SPFはRFC 4408としてRFC化された。
2004年1月5日、スティーヴン M. ベロヴィン（Steven M. Bellovin）は長い電子メールを書き、SPFに関する幾つかの懸念について議論した。それは次のような内容だった。
彼がこの声明文を書いた時は、これが正しい方法であるという合意はなかった。幾つかの主要なメールサービス業者はこの理論に同意しなかった。多くの利用者を抱える主要なメールサービス業者が対応するまで、それらのメールサービスを直接利用する者や、それらのメールサービスのドメインを詐称した電子メールを受け取る者に対して、SPFはあまり効果を上げることができない。SPFに対する関心が高まった時から、特にAOLがSPFを採用した点に注目する価値がある。
Jonathan de Boyne Pollardは、SPFが電子メールに関するRFCと矛盾するという議論において、SPFに反対して別の痛烈な非難を書いた。ISPの顧客に特定の方法で電子メールを使用させることをISPに押し付けることと、転送時の問題がSPFの能力である。
その限界にもかかわらず、多くの人はSPFの利点がその欠点に勝ることを確信し、SPFの実装を始めた。SpamAssassin version 3.0.0やAnti-Spam SMTP Proxy（ASSP）といった迷惑メール対策ソフトウェアがSPFに対応した。多くのメールサーバ（MTA: Message Transfer Agent）は、CommuniGate Pro、Wildcat、Microsoft Exchange、SmarterMailのように直接SPFに対応したり、またPostfix、Sendmail、Exim、qmailのように修正パッチやプラグインの形でSPFに対応した。Amazon、AOL、EBay、Google、GMX、Hotmail、マイクロソフト、W3Cといった多くの有名なドメインは、2004年中頃にはSPFデータを宣言することを決めた。
2007年に発表された調査によると、.comドメインおよび.netドメインの5%が、何らかの送信者ポリシーが宣言されていた。ただしこれには「v=spf1 ?all」のように全く役に立たない宣言も含まれている可能性がある。
現在、日本の下記携帯電話会社においてSPF認証が導入または導入予定である。ただし、その実装は標準とは一部異なり、検証の対象や条件は各社で異なる。
前述の通り、SPFは部分的にではあるものの、迷惑メールの防御に役立つと言われている。しかし、実効性には疑問の声がある。