自社ドメインに必要なSPFレコードとは？
著者: Yunes Tarada
翻訳: 古川 綾乃
この記事はPowerDMARCのブログ記事 What SPF Record Do I Need For my Domain? の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
主なポイント
- SPFレコードは、「include」、「a」、「mx」、「ip4/ip6」などのメカニズムを含む定義済みの構文で記述されます。
これらのメカニズムにより、ドメイン所有者は信頼できるサーバを構造化された方法で指定できます。 - 必要となるSPFレコードは、組織が独自のメールサーバを使用しているのか、サードパーティプロバイダに依存しているのか、あるいはハイブリッド環境を運用しているのかによって異なります。
- SPFをDKIMおよびDMARCと組み合わせることで、多層的な認証戦略を構築でき、フィッシング、なりすまし、およびドメイン悪用に対する防御を強化できます。
メールのなりすましやフィッシングは、世界中の企業にとって依然として継続的な脅威であり、メール認証の重要性はこれまで以上に高まっています。
「どのSPFが必要なのか」と考えているのであれば、それは自社ドメインを保護し、ブランドの評判を守るための重要な第一歩を踏み出していることになります。
SPF（Sender Policy Framework）はDNS TXTレコードの一種であり、自社ドメインからメールを送信することが許可されているIPアドレスおよびサーバを、受信側メールサーバが確認できるようにします。
SPFが適切に設定されていない場合、正当なメールが迷惑メールフォルダに振り分けられる可能性がある一方で、サイバー犯罪者が容易に自社ドメインになりすますことができます。
どのSPFが必要かを理解するには、現在のメール環境を評価し、正当な送信元をすべて適切に認可する必要があります。
メールにおけるSPFとは？
SPFは、DNS TXTレコードとして実装されるメール認証プロトコルです。
その目的は、自社ドメインを代表してメールを送信することが許可されているメールサーバおよびIPアドレスを指定することです。
この情報を公開することで、受信側メールサーバは、メッセージを受け入れるべきかどうかを判断する際の参照情報として利用できます。
SPFレコードは、「include」、「a」、「mx」、「ip4/ip6」などのメカニズムを含む定義済みの構文で記述されます。
これらのメカニズムにより、ドメイン所有者は信頼できるサーバを体系的に指定できます。
たとえば、「include」はサードパーティプロバイダのSPFポリシーを取り込み、「mx」は自社ドメインの受信メールを処理するサーバを認可します。
これらの要素が組み合わさることで、メールサーバに対する明確な認証ルールが定義され、正当な送信者のみが認識されるようになります。
なぜSPFが重要なのですか？
SPF認証は、セキュリティとメール到達率の両方を直接向上させる複数の利点を提供します。
まず、SPFは、サイバー犯罪者が悪意のあるメールで自社ドメインになりすますことを大幅に困難にすることで、メールのなりすましやフィッシング攻撃を防止します。
この保護により、攻撃者はブランドを装った不正メールを送信しにくくなります。
SPFはメール到達率も向上させます。
Gmail、Outlook、Yahooなどのインターネットサービスプロバイダやプラットフォームは、受信メールを信頼するかどうかを判断する際に、SPF検証を重要な要件として利用しています。
適切に設定されたSPFレコードは、メールが正当であることをこれらのサービスに示し、その結果、メールが迷惑メールフォルダではなく受信トレイに届く可能性が高まります。
SPFは、自社ドメインがスパムやフィッシングキャンペーンで不正利用されることを防ぐことで、ブランドの評判を保護します。
顧客がメールの送信元が本当に自社であると確信できれば、組織に対する信頼が高まり、コミュニケーションチャネルに対する管理も強化されます。
SPFの仕組み
SPF認証は、メール送信時に実行される段階的な検証プロセスによって行われます。
このプロセスを十分に理解することで、自社のメール環境に適した正確なSPFレコードを設定しやすくなります。
まず、組織は自社ドメインのDNS設定にSPFレコードを公開します。
このレコードは公開された認証ルールとして機能し、どのIPアドレス、メールサーバ、およびサードパーティサービスが自社を代表してメールを送信できるかを定義します。
自社ドメインから送信されたと主張するメールを受信すると、受信側メールサーバはSPF検索を開始し、自社ドメインのDNSレコードを確認します。
その後、送信元サーバのIPアドレスを、SPFレコードに記載された認可済み送信元と照合します。
送信元サーバが含まれていれば、メールはSPF認証に合格し、受信システムに対してそのメールが信頼できることを示します。
一方、送信元サーバが認可済みとして登録されていなければ、メールはSPF認証に失敗します。
設定したポリシーによっては、受信側サーバはそのメールを完全に拒否する場合もあれば、隔離したり、受信者の迷惑メールフォルダへ送ったりする場合もあります。
この一連の処理はすべて自動的に、かつ数ミリ秒以内に実行されるため、SPFは効率的なセキュリティ対策として機能します。
どのようなSPFレコードが必要ですか？
必要なSPFを判断するには、自社ドメインを代表してメールを送信するすべての正当な送信元を特定するために、メールインフラストラクチャを慎重に確認する必要があります。
必要となるSPFレコードは、組織が独自のメールサーバを使用しているのか、サードパーティプロバイダを利用しているのか、あるいはハイブリッド環境なのかによって異なります。
独自のメールサーバを使用している場合、SPFレコードには「ip4」または「ip6」メカニズムを使用してサーバのIPアドレスを含める必要があります。
例：
v=spf1 ip4:192.0.2.1 -all
このレコードは、単一のIPv4アドレスに対して自社ドメインのメール送信を許可し、「-all」メカニズムによって、それ以外の未認可送信元からのメールを受信側サーバが拒否するよう指示します。
サードパーティプロバイダを利用している場合は、「include」ステートメントを使用して各サービスのSPFレコードを含める必要があります。
一般的な例は次のとおりです。
- Google Workspace: include:_spf.google.com
- Microsoft 365: include:spf.protection.outlook.com
- Mailchimp: include:servers.mcsv.net
混在環境の場合は、複数のメカニズムを1つの包括的なSPFレコードに組み合わせることができます。
例：
v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.1 -all
この例では、Google Workspace、Mailchimp、および特定のIPv4アドレスが、自社ドメインを代表してメールを送信することを許可しています。
SPFレコードの確認方法
SPFレコードが正しく設定され、意図したとおりに機能していることを確認するためには、SPFレコードの検証が重要です。
適切な検証を行うことで、メール到達率に影響を与えたり、ドメインの悪用を招いたりする前に、問題を早期に発見できます。
SPFレコードの確認には、無料で利用できる検証ツールが数多くあります。
代表的なものとして、MXToolbox、PowerDMARCのSPF Checker、およびGoogle Admin Toolboxがあります。
これらのプラットフォームを使用すると、DNSに公開されているSPFレコードを迅速に分析し、詳細なレポートを取得できます。
また、SPFレコードの構文が正しいかを確認し、構文エラーや予期しない認証失敗を引き起こす可能性のあるDNSルックアップの問題を検出できます。
確認を実行すると、通常は以下のいずれかの結果が表示されます。
- pass
- 送信サーバが許可されており、メールがSPF認証に正常に合格したことを示します。
- fail
- 送信サーバがSPFレコードで許可されておらず、そのメールが未承認の送信元として扱われることを示します。
- softfail
- 送信サーバがおそらく許可されていないことを示しますが、メールは引き続き配信される場合があります（通常は警告付き、または迷惑メールフォルダに振り分けられます）。
- neutral
- 送信サーバが許可されているかどうかについてSPFレコードが明確な判定を行っておらず、最終的な判断を受信側メールサーバに委ねている状態です。
これら以外にも、いくつかの結果があります。 - none
- そのドメインにSPFレコードが存在せず、SPFポリシーが公開されていない状態を示します。
- permerror（Temporary Error）
- SPFレコードが無効または誤設定されている場合に発生します。
例えば、DNSルックアップ数が多すぎる場合や構文エラーがある場合などで、受信側サーバがSPFレコードを正しく評価できなくなります。
「temperror（Temporary Error）」 は、一時的なDNS障害などによりSPF検証を正常に実行できなかったことを示しますが、再試行によって解決する場合があります。
避けるべき一般的なSPF設定ミス
SPFは有効ななりすまし対策ですが、設定ミスによって十分な効果を発揮できなくなることがあります。
こうした問題を理解しておくことで、より効果的なSPFレコードを構築できます。
最も重大なミスは、1つのドメインに対して複数のSPFレコードを作成することです。
SPFの仕様上、DNSには1ドメインにつき1つのSPFレコードしか存在できません。
複数存在すると、受信側サーバはSPFレコードを無効と見なす可能性があり、正当なメールであっても認証に失敗することがあります。
そのため、すべての許可済み送信元は1つのSPFレコードに統合する必要があります。
もう1つのよくある問題は、DNSルックアップの上限である10回を超えてしまうことです。
各「include」ステートメントや外部DNSエントリを参照するメカニズムは、この制限回数にカウントされます。
複雑な構成では、適切に設計しないと簡単にこの上限を超えてしまいます。
この場合、SPF検証は失敗し、メール到達率の低下やドメイン評価の悪化につながります。
また、メールインフラの変更時にSPFレコードを更新しないことも、よくある見落としの一つです。
例えば、新しいメール配信サービスを導入した場合や、ホスティング事業者を変更した場合、あるいはMicrosoft 365やGoogle Workspaceへ移行したにもかかわらずSPFレコードを更新しなかった場合、正当なメールが認証に失敗する可能性があります。
その結果、業務上のメールのやり取りに支障が生じ、重要なメールが届かないことで顧客との関係に悪影響を与える可能性があります。
まとめ
必要なSPFレコードの内容は、利用しているメールサービスの構成やメールインフラ全体によって決まります。
組織が独自のメールサーバを運用している場合、SPFレコードには対応するIPアドレスを含める必要があります。
Google Workspace、Microsoft 365、またはメール配信サービスなどのサードパーティサービスを利用している場合は、それらが公開しているSPFメカニズムを組み込む必要があります。
いずれの場合も、ドメインを適切に保護するためには、すべての正当な送信元をSPFレコードに記載する必要があります。
ただし、SPFだけでは十分な保護は実現できないことを理解しておくことが重要です。
SPFは送信元サーバの正当性を検証しますが、攻撃者はメールヘッダーのFromアドレスを偽装することでSPFの仕組みをすり抜ける場合があります。
その結果、認証に失敗していても、受信者にはあたかも自社ドメインから送信されたメールであるかのように見えることがあります。
このため、SPFは単独で運用すべきではありません。
DKIM（メッセージの完全性を検証）およびDMARC（Fromアドレスと認証結果の整合性を検証・適用）と組み合わせることで、より強固な多層防御を実現できます。
この組み合わせにより、フィッシングやなりすまし、ドメインの不正利用に対する防御を大幅に強化できます。また、受信者はメールの信頼性をより適切に判断できるようになります。
ご利用環境に合わせた専門的な支援をご希望の場合は、PowerDMARCのトライアルをご予約いただき、PowerDMARCの機能や導入効果をご確認ください。
よくある質問（FAQ）
- SPFレコードを設定しないとどうなりますか？
- SPFレコードがない場合、送信したメールは受信側メールサーバによって不審なメールと判断されたり、迷惑メールとして扱われたりする可能性が高くなります。
さらに重要なのは、サイバー犯罪者が容易にドメインをなりすまし、組織から送信されたように見えるフィッシングメールや詐欺メールを送信できるようになることです。
これはメール到達率に悪影響を及ぼすだけでなく、ブランドの評判や顧客からの信頼にも重大なリスクをもたらします。 - 1つのドメインに複数のSPFレコードを設定できますか？
- いいえ、ドメインには1つのSPFレコードのみを設定する必要があります。
複数のSPFレコードは仕様違反となり、メールサーバがどのレコードを正規のものとして扱うべきか判断できなくなるため、認証エラーの原因となります。
代わりに、すべての許可済み送信元を1つのSPFレコードに統合してください。