SPFレコードの設定方法 ― SPF設定ガイド

なりすまし防ぐSPF

2024年6月3日
著者: Ahona Rudra
翻訳: 岩瀨　彩江

この記事はPowerDMARCのブログ記事 How to Set Up SPF Record? – SPF Setup Guide の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

メールは企業にとって不可欠なツールであり、私たちの多くは日常的にコミュニケーションのために依存しています。
しかし、メール利用者の増加に伴い、スパム、メールなりすまし、フィッシング、ホエーリング、メール詐欺といった問題も拡大してきました。

これらの攻撃は、評判の失墜、金銭的損失、データ漏洩といった重大な被害をもたらす可能性があります。
そのような攻撃を防ぐために、企業はメールシステムを保護するための積極的な対策を講じる必要があります。
その方法のひとつが、SPF設定を構成することです。

Yahoo Mail や Google Workspace のような主要なメールプロバイダは、受信者を詐欺から保護するために、Sender Policy Framework（SPF）、DomainKeys Identified Mail（DKIM）、および Domain-based Message Authentication, Reporting, and Conformance（DMARC）といったメール認証プロトコルを推奨しています。

重要なポイント

1. SPFのようなメール認証プロトコルは、メールなりすまし、フィッシング、詐欺を防ぐために不可欠なツールです。
2. 有効なSPFレコードを設定するには、すべての認可されたメールサーバ（サードパーティを含む）を、ドメインごとに1つのDNS TXTレコードで指定する必要があります。
3. SPFレコードを定期的に更新し、10回のDNSルックアップ制限を遵守すること（「ptr」のような推奨されないメカニズムを避けること）が、維持管理と配信可能性において重要です。
4. SPFレコードをテストすることで、正しく構成され機能しているかを確認できます。
5. SPFは基盤となる保護を提供しますが、包括的なメールセキュリティとコンプライアンスのためには、DKIMやDMARCと併用するのが最適です。

メールセキュリティにおけるSPF ― 解説

SPFとは何か？
SPFは「Sender Policy Framework」の略です。
これは、どのサーバが自分のドメインからメールを送信することを許可されているかを指定できるメール認証プロトコルです。

SPFは、ドメインのDNSゾーンファイルにDNS TXTレコードを追加することで機能します。
そのレコードには、その特定のドメイン名からメール送信を許可されたIPアドレスやホスト名が一覧として含まれています。
受信側のメールサーバは、このレコードを参照してメールの正当性を検証します。
つまり、送信元が認可されたIPアドレスでない場合、受信側サーバは指定されたポリシー（例：拒否または疑わしいとマーク）に従って処理を行うよう指示されるのです。

有効なSPFレコードを設定することは、不正なユーザがあなたのドメイン名を使ってメールを送信するのを防ぐために不可欠です。
例えば、スパマーや攻撃者はあなたのドメイン名を利用してスパムやフィッシングメールを送信したり、ホエーリング攻撃を仕掛けたり、その他の詐欺行為を行ったりする可能性があります。
こうした行為は、ブランドの評判を傷つけ、正規のメールが他のサーバによってブロックまたは拒否される原因となり、顧客や従業員のセキュリティを危険にさらす可能性があります。

SPFの構成要素

DNSにおけるSPFレコードの主な構成要素は以下のとおりです。

Version (v=spf1)

SPFのバージョンを指定します。常に「v=spf1」から始まります。

IP4 と IP6 (ip4: / ip6:)

そのドメインからメール送信を許可されたIPv4およびIPv6アドレスを一覧化します。

A および MX メカニズム (a: / mx:)

• a: ドメインのAレコードのIPアドレス（または指定されたホスト名、例：a:mail.example.com）と一致するサーバからのメール送信を許可します。
• mx: ドメインのMX（Mail Exchange）レコードに記載されているサーバからのメール送信を許可します。ここでは特定のメールサーバのホスト名ではなく、ドメイン（例：mx:example.com）を指定する必要があります。

Include メカニズム (include:)

他のドメインのSPFレコードを参照して送信者を認可することを許可します。
これは、サードパーティのサービスがあなたのドメインに代わってメールを送信する場合に便利です。
includeステートメントで指定する正しいドメイン値については、必ずサードパーティの組織に確認してください。

PTR メカニズム (ptr:)

逆引きDNSルックアップを実行します。
しかし、RFC7208では「ptr」メカニズムの使用は信頼性の問題やパフォーマンスの負担から推奨されていません。
一般的には、「a」「mx」「ip4」「ip6」といったメカニズムを使用することが推奨されています。

All メカニズム (all)

前のメカニズムに一致しなかった送信者に対するデフォルトのルールを設定します。
必ずSPFレコードの一番最後に配置する必要があります。
オプションは以下のとおりです

• -all：ハードフェイル（認可されていないIPを拒否）。運用時に推奨されます。
• ~all：ソフトフェイル（認可されていないIPを疑わしいものとしてマーク）。初期設定やテスト時によく使われます。
• ?all：ニュートラル（認可されていないIPに対して特別な処理を行わない）。保護効果はほとんどありません。
• +all：パス（すべてのIPを許可）。SPFの目的を無効化するため、強く非推奨です。

Redirect (redirect=)

現在のレコードでメカニズムを定義する代わりに、別のドメインのSPFレコードを参照する場合に使用します。
「all」メカニズムの代替として利用できます。

修飾子 (Modifiers)

失敗時の説明を提供する exp= など、微調整のためのオプションルールです。
ただし、利用されることはあまり多くありません。

SPFの例

v=spf1 ip4:192.168.1.1 include:_spf.thirdparty.com -all

この例では、192.168.1.1 からのメール送信を許可し、サードパーティのSPFレコードを取り込みます。
その他のIPからのメールは「-all」により拒否されます。

SPF設定の理解

SPF設定とは、ドメイン所有者のDNSにおけるSPFメール認証プロトコルの構成を指します。
SPF設定により、正規の送信元を認可することができ、受信サーバが正規のメール送信者と、単に正規のドメイン名を装っている送信者とを容易に区別できるようになります。
これは、メールベースのサイバー攻撃から保護するために必要なメール認証のステップです。

SPFレコードの設定と追加方法

SPF設定は、実際にメール送信を行うドメインだけでなく、送信を行わない「パークドドメイン」を含むすべての所有ドメインにとっても不可欠です。
これは、それらのドメインが悪意ある利用から保護されることを保証するためです。
SPFレコードの設定はシンプルな手順で行うことができ、以下のステップを含みます。

ステップ1：メールサーバと送信元の特定

最初のステップは、自分のドメインからメール送信を許可されているすべてのサーバとサービスを網羅的にリスト化することです。
これには、以下のような送信元が含まれます。

• 自社のメールサーバ（例：Microsoft Exchange、GmailなどのWebベースサービス）
• マーケティングや取引メールに利用するサードパーティのESP（Email Service Provider）
• 支払い処理サービス、ECプラットフォーム、CRM、ヘルプデスク、サポート／チケッティングシステムなど、自社に代わってメールを送信するその他のサービス

ステップ2：SPFレコードの作成

すべての認可された送信元を特定したら、SPFレコードを作成します。
これは、SPFレコード生成ツールを使用するか、手動で構文を作成することで可能です。
SPFレコードは、ドメインのDNS設定におけるTXT（テキスト）レコードです。
ドメインごとに必ず1つのSPFレコードだけを作成するようにしてください。

シンプルな構文の例は以下のとおりです。

v=spf1 ip4:<IP address> include:<third-party domain> -all

この例では、

• v=spf1 → SPFのバージョンを示す
• ip4:<IP address> → 認可されたIPアドレスを指定する
• include:<third-party domain> → サードパーティ送信者のポリシーを取り込む
• -all → 記載されていない送信元からのメールは拒否する

という意味になります。
また、誤字（例：includeをinlcudeとしてしまうなど）でもレコードが無効化されてしまうため、入力内容は必ず再確認してください。

ステップ3：SPFレコードの公開

SPFレコードを作成したら、それをドメインのDNSに公開する必要があります。
ドメイン管理者であれば、必要なDNS更新を簡単に行うことができます。

具体的には、DNSプロバイダのWebサイトにログインし、新しいTXTレコードとしてSPFレコードの内容を追加します。
レコードの内容は必ず v=spf1 から始める必要があり、DNSエントリ自体では二重引用符で囲まないようにしてください（ただし、DNS管理画面によっては引用符付きで表示される場合があります）。

また、自分で作業を行わない場合は、ITチームやホスティングプロバイダに依頼することも可能です。
DNSの変更はインターネット全体に反映されるまで時間がかかることがあります（最大72時間程度かかる場合もありますが、多くの場合はもっと早く反映されます）。

ステップ4：SPFレコードのテスト

SPFレコードを公開し、伝播の時間を確保したら、正しく機能しているかを確認するためにテストすることが重要です。
また、SPFレコードが 10回のDNSルックアップ制限 を超えていないかも確認する必要があります。
この制限には、include、a、mx、ptr、exists、redirect といったメカニズムが含まれ、ネストされた include 内のルックアップもカウントされます。

テストには、PowerDMARC や MXToolbox が提供するオンラインのSPFレコードチェッカーを利用できます。
これらのツールを使えば、SPFレコードが有効かどうか、正しい形式で記述されているか、ルックアップ制限内に収まっているか、そして想定どおりに機能しているかを確認することができます。

SPFレコードに関する5つの誤解

インターネット上には、SPFレコードに関する誤った情報や神話のようなものが流布しており、それが間違った判断につながる可能性があります。
ここでは、それらをひとつずつ解消していきましょう。

1. SPFだけでなりすましを防げる

これは誤りです。
SPFを設定するだけでは、すべての種類のなりすましや偽装を防ぐことはできません。
特に、ユーザが目にする「From」ヘッダに関する攻撃には効果が限定的です。

より強力な保護を提供し、失敗時の扱いを受信者に指示するためには、SPFを DKIM および DMARC（Domain-based Message Authentication, Reporting, and Conformance） と組み合わせる必要があります。
DMARCを利用することで、ドメイン所有者は「拒否」や「隔離」など、SPFまたはDKIMの検証に失敗したメールに対して適用するポリシーを指定できます。

2. SPFレコードで +all を使える

これは誤解です。
+all を使用すると、インターネット上のあらゆるサーバがあなたのドメインを使ってメールを送信できることを許可してしまいます。
これでは、SPFプロトコルが本来持つセキュリティ上の目的が完全に失われてしまいます。

その代わりに、SPFを正しく運用するためには、レコードの最後に ~all（ソフトフェイル） もしくは、より望ましい -all（ハードフェイル） を使用することが推奨されます。

3. SPFは転送メールでも機能する

そうであれば理想的ですが、残念ながら多くのメール転送シナリオではSPFは正しく機能しません。
これは、転送サーバのIPアドレスが元の送信者のSPFレコードに記載された認可済みIPと一致しないことが多く、さらにヘッダ情報が変更される可能性があるためです。
このような場合には、転送後も有効であることが多い DKIM、または転送経路全体で認証結果を維持できる ARC（Authenticated Received Chain） といったプロトコルを利用することで、認証を補完できます。

4. SPFレコードには無制限のDNSルックアップが可能である

これは誤解です。
SPF仕様（RFC）では、1回のSPF検証につき最大 10回のDNSルックアップ という制限が設けられています。
include、a、mx、ptr、exists、redirect といったメカニズムはすべてDNSルックアップを行うため、この回数がカウントされます。

もしこの制限を超えると SPF PermError（Permanent Error） が発生し、正当なメールであっても認証に失敗する可能性があります。
そのため、SPFレコードはできるだけ簡潔に保つことが重要です。
また、多くのサードパーティ送信者を利用している場合は、SPFフラッテン（flattening） や 動的SPFマクロ などの最適化手法を活用して制限内に収めることが推奨されます。

5. SPFは「設定して終わり」でよい

これはSPFに関する大きな誤解です。
メール送信の仕組みは時間とともに変化する可能性があります。
新しいサードパーティサービスを追加したり、ESPを変更したり、古いサーバを廃止したりすることがあるからです。

そのため、SPFレコードは定期的に更新し、これらの変更を反映させる必要があります。
更新を怠ると、新しい正規の送信元が認可されず、そのメールが受信サーバによってブロックされたり、スパム扱いされたりする可能性があります。

SPFレコードはどのように機能するのか？

1.SPFレコードの作成

ドメイン所有者は、SPFレコード（DNSにおけるTXTレコード）を手動、またはオンラインツールを使って作成します。
このレコードには、そのドメインの代わりにメール送信を許可された送信元（IPアドレスや include による他ドメインなど）が指定されます。

2.メール受信時の処理

受信側のメールサーバは、受信したメールの Return-Path（エンベロープ送信者、Mail Fromとも呼ばれる） アドレスからドメインを抽出します。

3.DNSクエリによるSPF参照

受信サーバは、その送信者ドメインのSPF TXTレコードを取得するためにDNSクエリを実行します。

4.送信元IPの検証

受信サーバは、メールを送信してきた接続元サーバのIPアドレスが、SPFレコードに記載された認可済みの送信元と一致するかを確認します。

5.SPFチェックの判定

一致した場合 → Pass（成功） としてSPFチェックを通過。
一致しなかった場合 → レコードで定義された all メカニズムに基づいて処理されます。

• -all → Fail（失敗／拒否）
• ~all → SoftFail（疑わしいとしてマーク）
• ?all → Neutral（中立／特別な処理なし）

6.結果の影響

この判定結果は、そのメールが受信者の受信トレイに届くか、迷惑メールフォルダに振り分けられるか、あるいは拒否されるかに影響を与えます。
特にDMARCと組み合わせた場合、その影響力はさらに強まります。

正確なSPF設定のためのヒント

強力で効果的なSPFレコードを構築するために、以下のポイントに注意してください。

認可された送信元をすべて含める

あなたのドメインからメールを送信する権限を持つすべてのサーバやサードパーティサービスを漏れなくリスト化してください。
送信元の記載漏れは、正規のメールが届かなくなる原因になります。

すべてのドメインにSPFを適用する

メールを送信しない（パークド）ドメインにも v=spf1 -all のようなSPFレコードを公開し、そのドメインからメールが送られることはないと明示しましょう。

正しい「all」メカニズムを使用する

初期テストや移行段階では ~all（ソフトフェイル）を使用。
運用に自信が持てたら -all（ハードフェイル）を使用し、認可されていないメールを拒否するよう受信サーバに明確に指示します。
?all（ニュートラル）は避け、+all（すべて許可）は絶対に使用しないでください。

「all」の配置は必ず最後に

SPFレコード文字列内の all メカニズムは、常に一番最後に配置してください。

「include」メカニズムを正しく使用する

サードパーティ送信者を認可する際に必須の仕組みです。
必ずサードパーティが提供する正しいドメインを include で指定してください。

「mx」と「a」メカニズムの慎重な利用

• mx は、あなたのドメインのMXレコードに登録されているサーバを認可します（例：mx:yourdomain.com）。
• a は、ドメインのAレコードに関連付けられたIPアドレス、または特定のホスト名（例：a:mail.yourdomain.com）を認可します。 特定のメールサーバのホスト名とともに mx を使うのは避けてください。

推奨されないメカニズムは避ける

ptr メカニズムは非推奨で信頼性が低いため使用しないでください。

10回のDNSルックアップ制限を守る

include、a、mx、exists、redirect はDNSルックアップを行います。
ネストされた参照もカウントされ、10回を超えると PermError が発生します。

タイプミスに注意

公開前にSPFレコードを慎重に見直し、構文エラーや誤字脱字がないことを確認してください。

DNSに正しく公開する

レコードは必ずTXTレコードとして公開し、内容は v=spf1 から始めてください。
DNSデータフィールド内では引用符で囲まないようにしてください。

SPFレコードを常に最新に保つ

メール基盤や利用しているサードパーティ送信元が変わった場合は、必ずSPFレコードを更新してください。
定期的にレビューして、正しい状態を維持することが重要です。

PowerDMARCでSPF設定を最適化するメリット

SPF標準では、受信サーバがメールのSPFレコードを検証する際に実行できるDNSルックアップの数に制限が課されています。
この制限は 最大10回 です。
もしSPFレコードの評価に10回以上のルックアップが必要になった場合（include メカニズムのネストも含む）、SPF PermError が発生し、正規のメールであっても認証に失敗して配信上の問題を引き起こす可能性があります。

SPFフラッテン（flattening） は、この問題を解決するための手法です。
include などのメカニズムを、それらが解決する実際のIPアドレスに置き換え、SPFレコードに直接統合することで、検証時に必要なDNSルックアップ数を削減できます。
これにより、メール認証に必要なDNSクエリ数を大幅に減らすことが可能です。

PowerDMARCは、自動SPFフラッテン機能や、動的マクロベースのソリューションを提供しており、複雑なSPFレコードを効率的に管理しながら制限内に収めることができます。
SPFフラッテンの効果の例

あなたの会社が複数のサードパーティサービスを利用してメールを送信しているとします。
例）

• マーケティングオートメーション（include:spf.marketing.com）
• ヘルプデスクシステム（include:spf.support.com）
• 中小企業向けCRMツール（include:spf.crm.com）

これらの include ステートメントごとにDNSルックアップが必要であり、それぞれの参照先がさらに追加のルックアップを含んでいる場合、合計が10を超えるとSPFレコードは機能しなくなります。
SPFフラッテン（またはマクロソリューション）を使えば、これらのサードパーティが認可するIPアドレスを事前に解決して統合できるため、必要なルックアップ数を効率的に減らせます。
その結果、受信サーバがSPFレコードを検証する際にPermErrorの上限に達することなく、正しく評価を完了できるようになります。

まとめ

SPF設定は、メールシステムを保護し、メール詐欺を防ぐために不可欠なステップです。
正確なSPFレコードを作成し、ドメインのDNSに正しく公開し、継続的に管理していくことで、あなたのドメインから送信される正規のメールが認証され、不正な利用者によるドメインの悪用を防ぐことができます。

ここまで紹介したベストプラクティスやヒントに従うことで、強力なSPFレコードを構築し、メールセキュリティ体制を強化できます。
特に、SPFを DKIM や DMARC と組み合わせることで、より包括的で堅牢なメール認証とセキュリティを実現できます。

SPFレコード設定に関するFAQ

Q: 1つのドメインに複数のSPFレコードを持つことはできますか？

A: いいえ。ドメインには必ず 1つのSPFレコード しか設定できません。
同じドメインに複数のSPFレコードを公開するのはよくある間違いであり、SPF検証が失敗したり、予測不能な結果（多くの場合「None」や「PermError」）を返したりします。
複数の送信元を認可する必要がある場合は、すべてを1つのSPF TXTレコード文字列にまとめて記述する必要があります。

Q: 大きなSPFレコードを分割できますか？

A: いいえ。論理的に大きなSPFポリシーを、同じドメインで複数のTXTレコードに分割することはできません。
これは「1ドメイン＝1レコード」というルールがあるためです。
さらに、個々のDNS TXTレコードには文字列の制限があります（古い仕様では255文字制限がありますが、最新のDNSシステムでは1つのレコード内に複数の文字列をサポートして回避可能です）。

もしSPFレコードが複雑になりすぎたり、10回のDNSルックアップ制限を超えたりする場合でも、単純に分割することはできません。
その代わりに以下の対策を検討してください。

1. レコードを簡素化する：冗長または不要なエントリを削除し、可能な限りCIDR表記を使ってIPレンジを統合する。
2. ルックアップを発生させるメカニズムを最小化する：include、a、mx、exists、redirect の数を減らす。
3. SPF管理ソリューションを利用する：SPFフラッテンや動的SPF（マクロベース）ソリューションを提供するサードパーティサービスを活用し、複雑なレコードを管理しつつ制限内に収める。

Q: なぜSPFレコードを使うのですか？

A: SPFレコードは、メールのなりすましを防ぐために使用されます。
ドメイン所有者が、自分のドメインの代わりにメールを送信することを許可されたメールサーバを公開的に宣言できる仕組みです。

受信サーバはこのレコードを参照して、送信サーバの正当性を確認します。
これにより、フィッシング、スパム、その他の不正なメールがドメイン名を利用して受信者の受信トレイに届く可能性を減らすことができます。

Q: いつSPFが必要ですか？

A: SPFは、メールを送信するすべてのドメインに必要です。
SPFは、メールの到達率を改善し、ブランドの信頼を守り、送信元の正当性を検証し、さらにGoogleやYahooなど主要プロバイダによる最新の要件を含む、受信サーバのポリシーや業界のベストプラクティスに準拠するための、基本的なメール認証プロトコルです。
SPF設定の重要性についてさらに詳しく学びましょう。メールを送信しないドメインであっても、不正利用を防ぐために v=spf1 -all のような制限付きのSPFレコードを設定しておくことが推奨されます。

Q: SPFレコードを最適化するにはどうすればよいですか？

A: SPFレコードは、以下の方法で手動で最適化できます。
認可された送信元を丁寧に確認・統合し、使用していない送信元を削除し、効率的なIPレンジ表記（CIDR）を使用し、DNSルックアップを発生させるメカニズムを最小限に抑えます。
ただし、構成が複雑な場合や、10回のDNSルックアップ制限を確実に超えないようにするためには、自動フラッテン化や動的SPFマクロなどを提供するサードパーティのSPF最適化サービスを利用する方が、手間がかからず安全です。
これらのサービスを使えば、SPFレコードを継続的に管理しながら、最適な状態を保つことができます。

Q: 自分のSPFレコードが正しく設定されているかどうかは、どうすれば分かりますか？

A: オンラインのSPFレコード検索ツールを使用して確認できます。
これらのツールは、SPFレコードの構文を検証し、DNS上に正しく存在しているかを確認し、10回のDNSルックアップ制限内に収まっているか、そして全体的に正しく構成されているかをチェックします。