SPFレコードの書き方と設定方法：メカニズムと限定子の構文

SPFレコードの要件

SPFバージョンで始まり、TXTレコードは1つだけ

RFC 7208は、SPFバージョン1のレコードをv=spf1で始まるDNSのTXTレコードと定めています。残りは、スペースで区切った項目で構成します。一つのドメインに、SPFバージョン1を名乗るレコードを複数公開してはいけません。複数のレコードを見つけた受信側はPermerrorを返します。

v=spf1 ip4:192.0.2.0/24 include:spf.sender.example ~all

これはあくまで例です。IP範囲とincludeするドメインは、自社の正規の送信元向けに生成された値、または送信元が文書で示す値に置き換えてください。他の組織のSPFレコードをコピーしないでください。

この記事では、レコード自体の文法と評価の仕組みを扱います。

メカニズムは接続元の送信者を判定する

SPFのメカニズムは、SMTPクライアントのIPを判定するか、別のSPFポリシーを評価します。RFC 7208が定めるメカニズムは次のとおりです。

• allはすべての送信者にマッチします。allより後ろの項目には到達しないため、通常は末尾に置きます。
• include:<domain>は、指定ドメインのSPFレコードを評価します。
• aは、ドメインのAまたはAAAAレコードが返すアドレスを判定します。
• mxは、ドメインのMXホストに対応するアドレスを判定します。より限定的な動作はSPFのMXメカニズムの解説を参照してください。
• ip4:<address-or-network>とip6:<address-or-network>は、IPv4またはIPv6のアドレス範囲を直接判定します。
• exists:<domain-spec>はDNSルックアップを実行し、その結果でマッチするかどうかが決まります。
• ptrは逆引きDNSの処理を使います。RFC 7208は推奨しておらず、公開者は使うべきではないとしています。

限定子はマッチ時の結果を決める

限定子（qualifier）は、メカニズムの直前に付ける一文字の記号です。限定子がなければ、既定値は+です。

+ip4:192.0.2.10  -ip4:198.51.100.10  ~all  ?all

これはあくまで例です。これらのアドレスは文書用の範囲で、実際の送信インフラではありません。

RFC 7208が定める限定子は4つです。

• +：メカニズムにマッチするとPassになります。
• -：メカニズムにマッチするとFailになります。
• ~：メカニズムにマッチするとSoftfailになります。
• ?：メカニズムにマッチするとNeutralになります。

allメカニズムは必ずマッチするため、最後の項目としてよく使われます。SPFのallメカニズムの解説では、-all、~all、?allがそれぞれ異なるポリシー結果を伝える理由を説明しています。

includeとredirectの役割の違い

include:<domain>は、現在のレコード内のメカニズムです。includeされたドメインは、元のSMTPクライアントのIPアドレスで評価されます。その評価がPassならincludeメカニズムはマッチし、その限定子が結果を決めます。includeされたポリシーがFail、Softfail、Neutralを返した場合、includeはマッチせず、評価は続きます。TemperrorとPermerrorはエラーとして返されます。

redirect=<domain>はメカニズムではなく修飾子（modifier）です。どのメカニズムにもマッチしなかった場合にだけ使われ、最終的な評価を指定ドメインのSPFレコードに委ねます。redirect修飾子は1つのレコードに1つまでで、すでにメカニズムがマッチしている場合、redirectは無視されます。

v=spf1 include:spf.sender.example ~all
v=spf1 ip4:192.0.2.10 redirect=spf.policy.example

これらはあくまで例です。includeなら、includeされたポリシーがPass以外を返しても、現在のレコードの評価を続けられます。redirectは、現在のレコードでマッチしなかった後にだけ評価を引き渡します。正規の送信元ごとに期待される結果をたどらずに、一方をもう一方に置き換えないでください。

exp修飾子もRFC 7208で定義されています。SPF Failの結果に説明文を付けるもので、送信者を許可することも、結果を変えることもありません。

受信側によるSPFレコードの評価

次の例のレコードで考えます。

v=spf1 ip4:192.0.2.0/24 include:spf.sender.example ~all

受信側はまずv=spf1をバージョンとして認識します。次に、接続元IPが192.0.2.0/24に含まれるかを判定します。マッチしなければ、includeされたポリシーを評価します。どちらの許可にもマッチしなければ、最後の~allによりSPF SoftFailになります。メカニズムがマッチした時点で評価は止まります。

アドレス範囲とincludeするドメインは例であり、本番用の値ではありません。承認済みの送信元ごとに、提供されたメカニズムを使ってください。同じ名前に完全なSPFポリシーが2つ見つかった場合は、1つの長いレコードとして扱わず、複数のSPFレコードを修正する方法に従ってください。

DNSを参照する項目は十個まで

RFC 7208は、SPFの評価ツールに対し、SPFチェック中に処理するDNS参照項目を十個までに制限するよう求めています。対象はinclude、a、mx、ptr、existsの各メカニズムとredirect修飾子です。これらの項目がDNS問い合わせを発生させるたびに、評価の上限にカウントされます。

ip4、ip6、allの各項目はDNSルックアップを発生させません。ただし、見た目が短いレコードでも、includeがさらに多くのDNS参照項目に展開されると上限を超えることがあります。

十回の上限は、見えているincludeの数ではなく、評価全体の上限として扱ってください。送信元のincludeを一つ追加しただけで、レコードのその部分に到達するすべての送信元でSPFが壊れることがあります。

当てはまらないケース

サービスが表示上のFromにそのドメインを使って送信しているからといって、SPFの例を表示上のFromドメインのレコードに統合しないでください。SPFが評価するのはSMTPのMAIL FROMまたはHELOのアイデンティティです。サービスが独自のエンベロープドメインを使っている場合、表示上のFromドメインのSPFポリシーは、そのメッセージのSPF結果に関わらないことがあります。

承認済みの送信元が別々のエンベロープ用サブドメインを使う場合は、ポリシーも分けてください。bounce.example.comのポリシーはそのアイデンティティに置くもので、example.comのレコードに統合する必要はありません。どのDNS名にレコードが必要かを決める前に、smtp.mailfromまたはsmtp.heloに表示される実際のドメインを確認してください。

SPFのサンプルは、送信元の棚卸しや、実際に届いたメッセージでの検証の代わりにはなりません。プラットフォームがアライメントの取れたDKIMで署名しているか、DMARCにPassするか、受信側がメッセージを受け入れるかは分かりません。追加するincludeで評価経路のDNS参照項目が十個を超えるなら、統合したレコードに加えても安全な修正にはなりません。公開前に経路をたどり、サポートされている許可の設計を選んでください。

SPFレコードの書き方と設定手順

1. 送信元が使うSMTPアイデンティティを特定する

正規の送信サービスをすべて洗い出し、それぞれが実際に使うMAIL FROMドメインとHELOアイデンティティを確認します。表示上のFromアドレスからSPFアイデンティティを推測しないでください。

ESPがプロバイダー所有のMAIL FROMドメインで送信している場合、SPFの結果は自社ドメインではなくそのプロバイダーのドメインに適用されることがあります。SPFの項目を追加する前に、サービスが文書で示す送信ドメインの設定を確認してください。

2. 正しいドメインにv=spf1のTXTレコードを1つ公開する

ポリシーが必要なドメインごとに、SPFバージョン1のTXTレコードを1つ公開します。送信元が使うMAIL FROMまたはHELOのドメインそのものにレコードがあることを確認してください。

長いTXTデータがDNSツールで引用符付きの複数の文字列に分かれて見えても、1つの論理的なSPFポリシーとして保ちます。1つのTXTレコード内の複数の文字列は認められます。SPFバージョン1のレコードを複数置くことは認められません。

3. 個別の許可を最後のポリシーより前に置く

IPアドレス範囲と、サービスが提供するincludeの項目はallより前に置きます。既知の送信経路に対応するメカニズムだけを使ってください。

まず実際の送信元を許可する項目を書きます。次に、運用できるポリシーに合った最後のallの限定子を選びます。-allは明確な許可の宣言になるため、メールを送信しないドメインに向いています。送信するドメインは~allで終えるべきです。この選び方はSPFのhard failとsoftfailの違いで解説しています。

4. includeとredirectの経路をたどる

すべてのincludeの経路をたどり、評価経路全体でDNS参照項目を数えます。include値を変更する前に、サービスの最新ドキュメントを確認してください。

redirectは、ローカルのメカニズムがどれもマッチしなかったときに、別ドメインのSPFポリシーを代わりに使う意図がある場合にだけ使います。includeの汎用的な代わりではありません。

5. 厳しいポリシーを公開する前に変更を再確認する

提案するレコードを、そのドメインを使う送信元と照らし合わせます。DNSの反映後、本番の各送信経路からテストメッセージを送ってください。

DNSの構文チェックは役立ちますが、棚卸しから漏れた送信元は見つけられず、特定の受信側がローカルポリシーをどう適用するかも証明できません。

正しく設定できたかの確認方法

まず、権威DNSと少なくとも1つの公開リゾルバーで、v=spf1で始まるSPFのTXTレコードが1つだけあることを確認します。組織ドメインだけでなく、SMTPアイデンティティそのものに公開されていることも確認してください。

次に、該当するすべての評価経路をたどり、DNS参照項目を数えます。PalisadeのSPFチェックツールは、公開中のSPFレコードを調べ、構文やルックアップ数の問題を見つけるのに役立ちます。公開情報の照会では、本番の送信経路、DNSの継続的な状態、受信側の非公開の判断、今後の配信先までは証明できません。

そのうえで、承認済みの本番送信元からそれぞれ実際にメッセージを送り、届いたヘッダーを確認します。RFC 8601は、smtp.mailfromとsmtp.heloのプロパティを含め、受信側がSPFの結果をAuthentication-Resultsに記録する方法を定めています。プロパティが期待どおりのSMTPドメインを示し、評価結果が意図した送信元と一致することを確認してください。

最後に、データがたまったらDMARCの集計レポートを確認します。SPF Passだけでは、DMARCのアライメントは成立しません。集計レポートを見れば、実際のトラフィックでSPF認証済みのドメインが表示上のFromドメインと一致しているかが分かります。

ポリシーを変える前にSPFレコードをチェック

SPFチェックツールで、SMTPのMAIL FROMまたはHELOのアイデンティティに現れるドメインに公開されたレコードを調べます。includeを追加したり最後のallポリシーを変えたりする前に、その構文とルックアップ経路を、届いたメッセージのAuthentication-Resultsヘッダーと比べてください。

Palisadeで始める

IT部門やMSP向けに、PalisadeのDMARC Agentは、DMARC集計レポートで見つかった送信元を調査し、SPFの修正案を作成し、ポリシーの各段階を提案します。反映前に必ずお客様が承認します。DNSの変更を承認すると、Smart DNS Deploymentがお客様自身のDNSプロバイダーにある自社ゾーンへレコードを書き込みます。エージェントがすべての送信元を見つけたり、今後のすべてのメッセージの認証や受信側の配信判断を保証したりするわけではありません。