SPFメールとは？

SPFのおさらい

2025年8月27日
著者: Maitham Al Lawati
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 SPF (Sender Policy Framework): What It Is and How It Works の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

主なポイント

1. SPF（Sender Policy Framework）は、ドメイン所有者が認可したメールサーバの情報をDNS上で公開するためのメール認証プロトコルです。
2. SPFレコードは、認可されたIPアドレスやメール送信サービスを定義したDNS TXTレコードです。
   SPFレコードは「v=spf1」で始まり、SPFの構文に従って単一のレコードとして公開する必要があります。
3. ただし、SPFにはいくつかの制限があります。
   SPFはメール転送時には正しく機能せず、受信者に表示されるFromアドレスのなりすましを防ぐこともできません。
   また、DNSルックアップ回数には10回という厳格な上限があります。
   この上限を超えるとPermErrorが発生し、正当なメールが認証エラーとなって配信に失敗する可能性があります。
4. SPFだけでは十分ではありません。
   メールのなりすましやフィッシング攻撃、ドメインの不正利用を防ぐためには、DKIMおよびDMARCと組み合わせて運用する必要があります。

メールのなりすましは、攻撃者が用いる最も古典的な手法の1つであり、多くのドメインが十分な対策を講じていないため、現在でも効果的な攻撃手法となっています。
Sender Policy Framework（SPF）は、こうした脅威に対する第一の防御策です。

SPFは、どのIPアドレスからのメール送信を正規のものとして許可しているかを受信側メールサーバに示す、メール認証の基盤となるプロトコルです。
このガイドでは、SPFとは何か、SPFの仕組み、正しい設定方法、そしてSPFの制限事項について解説します。

SPF（Sender Policy Framework）とは？

Sender Policy Framework（SPF）は、フィッシング攻撃やスパムメールで広く悪用されているメールのなりすましを防ぐために設計されたメール認証プロトコルです。
SPFは、メール送信を許可したサーバの情報をDNSに公開することで機能します。
受信側メールサーバは、その情報を参照して、受信したメールが正規の送信元から送信されたものかどうかを検証できます。

SPFは、メール認証の基盤となる重要な仕組みです。
なぜなら、受信システムに対して「このサーバは、このドメインからメールを送信することを許可されているか」という基本的な問いに対し、明確で信頼できる判断材料を提供するからです。

SPFがメールセキュリティ全体の中で果たす役割

SPFは単独で機能するものではありません。
SPFは、DomainKeys Identified Mail（DKIM）およびDomain-based Message Authentication, Reporting, and Conformance（DMARC）と並ぶ、主要なメール認証プロトコルの1つです。
これらのプロトコルを組み合わせることで、メールのなりすましやフィッシング攻撃に対して、より包括的な防御を実現できます。

また、SPFはDMARCを構成する重要な要素の1つです。
ただし、DMARCはSPFだけでなくDKIMとも連携して動作するため、DMARCを最大限活用するには、SPFまたはDKIM、できればその両方を適切に設定することが推奨されます。

関連記事：SPF、DKIM、DMARCが連携してメールを保護する仕組み

SPFの仕組み

SPFはDNSを利用して動作するメール認証の仕組みです。
メールが送信されると、受信側メールサーバは、そのメールの送信元が正当であるかどうかを確認するために一連の検証を実行します。
以下は、SPF認証が行われる流れです。

SPF認証の流れ

1. メールが送信され、Return-Pathアドレスに送信元ドメインの情報が含まれます。
2. 受信側サーバは、Return-Pathアドレスから送信元ドメインを特定します。
3. 受信側サーバは、そのドメインのDNSを参照し、公開されているSPFレコードを取得します。
4. 送信元サーバのIPアドレスと、SPFレコードで許可されたIPアドレスを照合します。
5. 一致した場合はSPF認証に合格します。
   一致しない場合は、ドメインのポリシーに応じて不審なメールとして扱われたり、受信を拒否されたりする可能性があります。

SPF認証の結果

ただし、SPFが検証するのは送信元サーバのIPアドレスのみです。
送信者本人の正当性やメール本文の完全性を検証するものではありません。
こうした制限を補完するのがDKIMとDMARCです。

SPFレコードの例

SPFレコードは、ドメインのDNSに公開されるTXTレコードです。
SPFレコードは、どのサーバからのメール送信を許可するかを定義するために、SPFで定義されたメカニズムおよび修飾子を使用して記述します。

基本的なSPFレコード

v=spf1 ip4:192.0.2.0/24 include:mailprovider.com -all

メールを送信しないドメイン向けのSPFレコード

メールを一切送信しないドメインであっても、なりすまし対策として制限的なSPFレコードを公開することが推奨されます。

このレコードは、そのドメインを送信元として名乗るすべてのメールを拒否するよう受信側メールサーバに通知するものです。

DNSルックアップの10回制限

SPFでは、1回の認証処理で実行できるDNSルックアップ数が10回までに制限されています。
include、a、mx、redirect などのメカニズムはDNSルックアップを発生させます。

この上限を超えるとPermErrorが発生し、正当なメールが意図せずSPF認証に失敗する可能性があります。
これは、特に複数のメール送信サービスを利用している組織において、SPF設定で頻繁に発生する問題の1つです。

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

PowerDMARCを利用することで、SPFの運用や管理を効率化できます。

• DNSルックアップ超過を防ぐための自動SPFフラットニング
• リアルタイムの脅威インテリジェンスとレポート機能
• 24時間365日の専門サポート
• 主要なメールサービスとのシームレスな統合
• SOC 2およびISO 27001認証に準拠したセキュアな運用環境

SPFレコードの作成と公開方法

SPFレコードの作成と公開は、ドメインのメールを保護するうえで重要な設定作業です。
適切に設定することで、どの送信元サーバがドメインを使用してメールを送信できるのかを受信側メールサーバへ明確に伝えられます。

一方で、設定に誤りがあると、正当なメールが認証エラーとなり配信に影響が生じる可能性があります。
以下では、SPFレコードを正しく設定するための手順を説明します。

ステップ1：すべてのメール送信元を洗い出す

SPFレコードを作成する前に、ドメインからメールを送信しているすべてのサービスやシステムを特定します。
この作業を十分に行わないことが、SPF認証が正しく機能しなくなる最も一般的な原因の1つです。
確認対象には次のようなものがあります。

• メインのメールサーバ
• メールマーケティングプラットフォーム
• CRMや営業支援ツール
• ヘルプデスクおよびサポートシステム
• 請求メールやトランザクションメール配信サービス
• ドメインを利用してメールを送信する外部ベンダー

各送信元について、利用するIPアドレスまたは提供されているSPFのinclude値を確認してください。

ステップ2：SPFレコードを作成する

洗い出した送信元情報をもとに、SPF構文に従って1つのTXTレコードとして記述します。

作成時の主なポイントは次のとおりです。

ステップ3：DNSに公開する

作成したレコードをDNS管理画面でTXTレコードとして登録します。
通常はルートドメイン（@ または example.com）に設定します。

送信用途ごとにサブドメインを利用している場合は、それぞれのサブドメインに個別のSPFレコードを設定できます。
この方法は、DNSルックアップ数の増加を抑えるための対策として利用されることがあります。

ステップ4：公開後に検証する

レコードを公開した後は、必ず動作確認を行います。
確認項目は以下のとおりです。

• SPF構文が正しいこと
• 必要なIPアドレスやinclude設定がすべて含まれていること
• DNSルックアップ数が上限を超えていないこと
• 重複したSPFレコードが存在しないこと

SPF検証ツールを使用し、公開直後だけでなく設定変更時にも確認することをおすすめします。

ステップ5：定期的にメンテナンスする

SPFレコードは一度設定して終わりではありません。
新しいメール配信サービスの導入や既存サービスの変更・廃止に合わせて更新する必要があります。

古いIPアドレスや利用していないサービスが残ったままのSPFレコードは、正当なメールが認証エラーとなる原因になります。
特にメール環境を変更した際には、SPFレコードを定期的に見直す運用を行うことが重要です。

SPFとメール配信率

SPFを導入する大きなメリットの1つが、メール配信率の向上です。
メールサービスプロバイダや受信側メールサーバは、受信したメールを受信トレイに配信するか、迷惑メールとして扱うか、あるいは拒否するかを判断する際に、SPF認証結果を重要な判断材料として利用しています。

SPFがメール配信率の向上に役立つ理由

• 有効なSPFレコードを設定することで、正当なメールが迷惑メールとして判定されるリスクを低減できます。
• SPF認証が継続的に成功することで、送信ドメインの信頼性向上につながります。
• ドメインの信頼性が高まることで、メールがブロックされたり迷惑メールフォルダへ振り分けられたりする可能性を低減できます。
• SPFを適切に運用することで、メールセキュリティに配慮していることをメールサービスプロバイダへ示すことができ、送信者レピュテーションの向上につながります。

SPFの設定ミスがメール配信率に与える影響

正確かつ最新のSPFレコードを維持することは、送信ドメインの信頼性を保ち、安定したメール配信率を確保するうえで非常に重要です。

SPFの制限事項

SPFはメール認証の基盤となる重要な仕組みですが、いくつかの制限があります。
そのため、SPFだけに依存した運用では十分なメールセキュリティを実現できません。

SPFで対応できないこと

SPFはメール認証の第一歩にすぎない

SPFだけでは、受信者に表示されるFromアドレスのなりすましを防ぐことはできません。
また、メール転送への対応やメッセージ内容の検証も行えません。

そのため、ドメインのなりすましやフィッシング攻撃への対策を強化するには、SPFだけでなくDKIMおよびDMARCも併せて導入することが重要です。
特にDMARCは、SPFやDKIMの認証結果とFromアドレスとの整合性を確認することで、SPFだけでは防げない攻撃への対策を補完します。

運用上の推奨事項

複数のメールサービスや送信プラットフォームを利用している環境では、SPFレコードの変更履歴を管理することを推奨します。
変更内容を記録しておくことで設定ミスを防ぎやすくなり、問題発生時の原因調査や復旧作業も容易になります。

SPFとPowerDMARCによるドメイン保護

SPFはメール認証の出発点ですが、それだけで十分ではありません。
SPFレコードを適切に設定し、送信環境の変更に応じて継続的に更新するとともに、DKIMおよびDMARCと組み合わせて運用することで、ドメインのなりすましリスクを低減し、フィッシング対策やメール配信品質の向上につなげることができます。

PowerDMARCは、こうしたメール認証の運用を効率化するためのプラットフォームです。
SPFレコードの生成や検証、認証結果の監視、DMARCポリシーの運用までを一元的に管理できるため、メール認証環境の可視化と継続的な改善を支援します。

よくある質問（FAQ）

1. SPF（Sender Policy Framework）とは何ですか？

SPF（Sender Policy Framework）は、ドメイン所有者が自社ドメインからのメール送信を許可するサーバを指定するためのメール認証プロトコルです。
許可された送信元を定義したDNS TXTレコードを公開することで、受信側メールサーバはメールの送信元が正当であるかどうかを検証できます。

2. SPFとDKIM、DMARCの違いは何ですか？

SPFは送信元サーバのIPアドレスを検証します。
DKIMは電子署名を使用して、メール本文やヘッダが改ざんされていないことを検証します。
DMARCは、SPFやDKIMの認証結果とFromアドレスとの整合性を確認し、認証に失敗したメールをどのように処理するかを定義します。
これら3つを組み合わせることで、より強固なメール認証を実現できます。

3. SPFはどのように設定しますか？

まず、ドメインからメールを送信しているすべてのサービスやシステムを洗い出します。
その後、それらの送信元情報を基に、v=spf1 で始まる単一のDNS TXTレコードを作成して公開します。
公開後は必ず検証を行い、メール環境の変更に応じて継続的に更新することが重要です。

4. SPFレコードにはどのような制限がありますか？

SPFは送信元サーバのIPアドレスのみを検証する仕組みであり、送信者本人の正当性やメール本文の完全性を保証するものではありません。
また、メール転送時に認証が失敗する場合があり、DNSルックアップ数には10回という上限があります。
この上限を超えるとPermErrorが発生し、正当なメールの配信に影響を与える可能性があります。

5. SPFとDKIMは同じものですか？

いいえ、SPFは送信元サーバのIPアドレスを検証する仕組みです。
一方、DKIMは電子署名を利用して、メール内容が配送途中で改ざんされていないことを検証します。
両者は異なる役割を持ち、相互に補完し合う関係にあります。

6. メールがSPF認証に失敗する主な原因は何ですか？

代表的な原因は次のとおりです。

• SPFレコードで許可されていないサーバから送信された
• 正当な送信元がSPFレコードに含まれていない
• SPFレコードに構文エラーがある
• DNSルックアップ数が10回の上限を超えている
• 複数のSPFレコードが公開されている

これらはいずれもSPF認証失敗の代表的な原因です。