SPFレコードの構文ガイド：構成要素、規則、例、および検証
by
最終更新日: 10 読了時間：10分
主なポイント
- SPFは、送信サーバーがあなたのドメインのメールを送信する権限を持っているかどうかを確認するのに役立ちますが、DKIMやDMARCと併用することで最大の効果を発揮します。
- SPFレコードは、メカニズム、修飾子、およびモディファイアを用いて、許可された送信者を定義し、一致しないメールに対して受信サーバーがどのように処理するかを制御します。
- 受信者のサーバーは、DNSルックアップによってSPFレコードをチェックし、送信者の認可を確認する。
- SPFチェックの結果は、レコードおよび受信サーバーによる評価に応じて、「Pass」、「Fail」、「SoftFail」、「Neutral」、「None」、「TempError」、または「PermError」のいずれかが返されます。
- exp や redirect といった SPF モディファイアを使用すると、メールの検証や処理についてさらに詳細なカスタマイズが可能になります。
正当なメールの一部がスパムフォルダに入ったり、完全にブロックされたりしてしまう理由を疑問に思ったことがあるなら、その原因はドメインのメール認証の設定方法にある可能性があります。ここで重要な要素の一つがSPFレコードの構文であり、これはメールが承認されたサーバーから送信されていることを確認する上で極めて重要な役割を果たします。SPFはメールが不審なものと判断されるのを防ぐのに役立ちますが、その構文を理解するのは難しく、正しく設定するのはさらに困難です。
この記事では、SPFレコードの構文がどのように機能するか、またドメインにSPFレコードを設定する際に留意すべき点について詳しく解説します。
SPFレコードの構文とは？
SPFレコード構文とは、SPF（Sender Policy Framework）レコードがドメインのDNSにどのように記述されるかを定義する一連のルールです。簡単に言えば、ドメインが受信メールサーバーに、どの送信元が自分に代わってメールを送信することを許可されているかを伝えるために使用する「言語」です。
SPFレコードの構文には通常、メカニズム（ip4、ip6、includeなど）、修飾子（+、-、~、?など）、および修飾子が含まれており、これらが連携して、受信メールがSPFチェックに合格するか不合格になるかを決定します。
この構文を理解することは非常に重要です。なぜなら、余分なスペースや不正な修飾子、メカニズムが欠けているなどの小さなミスでも、認証に失敗してスパムメールに届いたり、受信拒否されたりする可能性があるからです。
DMARCの整合性に関する注意事項： SPFは、ユーザーが受信トレイで確認できる「From」アドレスではなく、エンベロープの送信者ドメインの有効性を検証します。DMARCがSPFを通じて有効判定されるためには、「Return-Path」に記載されたドメインが、表示されている「From」ドメインと一致している必要があります。これが、SPFをDKIMおよびDMARCと組み合わせて使用すべき理由です。
SPFレコードの構文構造と構成要素
SPFレコードは、バージョンタグ、メカニズム、修飾子、修飾子の4つの主要な部分で構成されています。各部分はそれぞれ独自の役割を果たしており、これらが組み合わさることで、受信メールサーバーが、あなたのドメインから送信されたと主張するメールをどのように処理するかが決まります。
| SPFコンポーネント | 目的 | 例 |
|---|---|---|
| バージョンタグ | そのレコードをSPFとして識別します | v=spf1 |
| メカニズム | 許可された送信者を定義します | ip4:203.0.113.5 |
| 予選 | メカニズムが一致した場合の結果を定義します | -all、~all |
| 修飾子 | オプションの処理指示を追加します | redirect=, exp= |
バージョンタグ
バージョンタグは、SPFレコードの出発点となります。これは、そのレコードがSPF構文を使用していることを示し、メールサーバーが後続のテキストを正しく解釈できるようにします。バージョンタグがない場合、レコードは機能しません。バージョンタグは1つしか指定できず、レコードの先頭に配置する必要があります。現在有効な形式は「v=spf1」です。
SPFの修飾子：+、-、~、および?
修飾子は、メカニズムの前に置かれる記号です。これらは、メカニズムに一致した場合に、受信メールサーバーがどのように処理すべきかを指示します。修飾子が指定されていない場合、デフォルトのアクションは「Pass」となります。
| 予選 | 結果 | 意味 | 典型的な使用例 | リスクレベル |
|---|---|---|---|---|
| + | パス | 送信者が承認されました。メールを受信しました。 | デフォルト — 明示的に記述されることはめったにない | 低 |
| - | 失敗 | 送信者が認証されていません。メールは拒否されました。 | 全面導入後の厳格な施行 | 完了している場合は「低」 |
| ~ | ソフトフェイル | おそらく許可されていない；フラグが立てられた | テストまたは暫定的な導入 | 中 |
| ? | ニュートラル | ポリシーによる決定ではなく、サーバーが決定する | 本番環境ではほとんど使用されない | 高 — 保護なし |
SPFのメカニズム：all、ip4、ip6、a、mx、exists、およびinclude
メカニズムは、SPFレコードにおける主要なルールです。これらは、どのサーバー、IPアドレス、またはドメインが、そのドメインに代わってメールを送信する権限を持っているかを定義します。各メカニズムは左から右の順にチェックされ、一致するものがあれば、それに関連する修飾子が適用されます。
| メカニズム | 構文例 | その権限の範囲 | DNS 検索 | 推奨用途 |
|---|---|---|---|---|
| 何れも | -すべて | すべての送信者に一致 — 末尾にキャッチオール | 0 | 必ず -all または ~all で終わるようにしてください |
| アイピーフォー | ip4:203.0.113.5 | 特定のIPv4アドレスまたはCIDR範囲 | 0 | 専用アウトバウンドサーバー |
| アイピーシックス | ip6:2001:db8::1 | 特定のIPv6アドレスまたはプレフィックス | 0 | IPv6経由の送信メール |
| a | a または a:example.com | ドメインのA/AAAAレコードに一致するIPアドレス | 1 | Webサーバーがメールも送信する場合 |
| エムオーエス | エムオーエス | ドメインのMXサーバーのIPアドレス | MXごとに1つ | MXサーバーが送信メールを送信する際 |
| 伝令者 | ptr:example.com | リバースDNSチェック（RFC 7208により非推奨） | 複数 | 使用を避ける — 非推奨 |
| ある | exists:example.com | DNSでドメインが解決されれば合格となる | 1 | マクロを使った高度な使い方 |
| インクルード | include:_spf.google.com | 参照されたドメインによって承認された送信者 | 1 + ネスト | 第三者送信者 |
「all」の仕組み：-all 対 ~all 対 ?all
-all（ハードフェイル）： リストにない送信者はすべて明示的に拒否されます。SPFレコードのテストを完了し、すべての正当な送信者がリストに含まれている場合にこの設定を使用してください。これは厳格な適用を行うための推奨設定です。
~すべて (SoftFail)： リストに登録されていない送信者は受け入れられますが、フラグが立てられます。すべての正当な送信者がリストに登録されていると確信できないテスト中や、段階的な導入時にこの設定を使用してください。
?all（中立）： リストに登録されていない送信者には、ポリシーが適用されません。これでは実質的な保護は得られないため、本番環境での使用は推奨されません。
+all（すべて許可）： どのサーバーでも、あなたの代わりに送信できるようにします。これは危険ですので、絶対に使用しないでください。
SPF修飾子：redirect および exp
redirect= (修飾子): SPFポリシーの評価全体を別のドメインに委譲します。「include」とは異なり、「redirect」は現在のレコードを完全に置き換えるため、「all」メカニズムと組み合わせることはできません。 SPFのincludeメカニズム は動作が異なります。これは、自身のレコードを置き換えることなく、参照先のドメインのSPFレコードから承認された送信者を追加します。
exp= (修飾子): SPF検証に失敗した場合のカスタム説明文字列を指定します。メッセージがSPF検証に失敗した場合、受信サーバーはこのTXTレコードを参照して、人間が理解しやすい理由を取得できます。
「include」と「redirect」：主な違い
| インクルード | リダイレクト | |
|---|---|---|
| タイプ | メカニズム | 修飾子 |
| 効果 | 参照されたドメインの送信者を追加します | SPF評価全体を置き換えます |
| すべてと併用できますか？ | はい。 | いいえ――すべてのオーバーライドはリダイレクトされます |
| DNS検索回数 | 10件の検索制限にカウントされます | 10件の検索制限にカウントされます |
SPF評価結果とその意味
受信メールサーバーがSPFレコードを評価すると、7つの結果のうちいずれかが返されます。各結果を理解することで、ドメイン所有者は配信失敗の原因を特定し、SPFの設定を改善することができます。一般的なSPFのエラーを修正するための対策については、当社のガイド「 SPFレコードの最適化方法」をご参照ください。
SPFレコード構文の例
単純なSPFレコード
v=spf1 ip4:203.0.113.5 -all
v=spf1 → バージョンタグ。ip4:203.0.113.5 → 1つのIPv4アドレスを認証します。-all → それ以外のすべてのサーバーは失敗します。これは、単一のサーバーからメールを送信する小規模なドメインでよく見られる設定です。
高度なSPFレコード
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com
このレコードは、/24のIP範囲全体と2つのサードパーティ送信者を許可し、SoftFailフラグ付きの未登録送信者を受け入れ、カスタムのエラー説明を提供します。「include」、「a」、「mx」、「exists」、および「redirect」の各メカニズムは、DNSルックアップをトリガーします。合計数が10を超えると、SPFはPermErrorを返します。
企業のSPFレコードの例
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
このレコードは、Google Workspace、Microsoft 365、およびサードパーティ製の配信プラットフォームを利用している組織では一般的なものです。各追加設定には DNS 検索が含まれるため、チームは PermError が発生しないよう、慎重に検証する必要があります。
MSP SPF 管理の例
多数のクライアントドメインを管理するMSPにとって、目標は1つの有効なSPFレコードを作成するだけでなく、すべてのクライアントにわたる変更を監視することにあります。SPF検証を一元化することで、クライアントが配信上の問題に直面する前に、重複するレコード、ルックアップ制限のリスク、および破損したインクルードを検出することができます。PowerDMARCの MSP/MSSPパートナープログラム を利用すれば、サービスプロバイダーは、ツールを切り替えたり、DNSレコードを手動で解析したりすることなく、単一のダッシュボードからすべてのクライアントドメインにわたる認証を管理できます。
ユースケース別のSPF TXTレコードの構文例
| ユースケース | SPF TXTレコード | 説明 | 注意 |
|---|---|---|---|
| MXサーバーのみ | v=spf1 mx -all | 送信できるのはMXサーバーのみです | MX以外のアドレスから送信された場合、失敗する |
| 単一のIPv4アドレス | v=spf1 ip4:203.0.113.5 -all | 特定のIPアドレス1つが許可されました | IPアドレスが変更された際の更新 |
| 複数の送信者 | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all | Google + Microsoft 365 | モニター検索の合計件数 |
| リダイレクト | v=spf1 redirect=_spf.example.com | 権限の委譲 | すべてと併用しないでください |
| 送信不可 | v=spf1 -全て | ドメインは保留中、メールなし | 送信以外の用途にのみ使用してください |
SPFレコードの構文で複数のインクルード機構を使用する方法
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all
各インクルード処理では少なくとも1回のDNSルックアップが発生し、ネストされたインクルードではさらにルックアップ回数が増加します。チェーン全体での合計は10を超えてはなりません。SPFの処理は最初の一致で停止するため、順序が重要となります。最も頻繁に使用される送信者を先頭に配置してください。ルックアップ回数が10に近づいている場合は、PowerDMARCの SPFフラット化ツール を使用してレコードを自動的に最適化してください。複雑なエンタープライズ環境の場合は、 SPFマクロ は、評価時に動的に展開されるため、従来のフラット化手法よりもスケーラブルな代替手段となります。
SPFレコードにおけるDNSルックアップの回数が多い
RFC 7208 では、SPF 評価中の DNS ルックアップの総数を 10 回に制限しています。この制限は、include、a、mx、exists、および redirect メカニズムによって引き起こされるネストされたルックアップを含め、ルックアップチェーン全体に適用されます。この制限を超えた場合、受信サーバーは PermError を返し、SPF は完全に失敗します。 また、あまり知られていない制約として、「2-void-lookup」制限があります。2つ以上のDNSクエリがNXDOMAINを返した場合も、SPFは失敗します。この問題を解決する方法の詳細については、 「DNS ルックアップが多すぎる場合の修正方法」」を参照してください。
カウント対象となるメカニズム： include（1＋ネスト）、a（1）、mx（MXおよびAのルックアップ1件につき1）、exists（1）、redirect（1＋ネスト）、ptr（複数 — 非推奨）。
カウントされないメカニズム： ip4 および ip6 は DNS 検索をトリガーしません。
DNSルックアップを減らす方法： 使用しなくなった送信元に対するインクルード設定を削除してください。可能な場合は、AレコードおよびMXレコードの設定を明示的なIPv4値に置き換えてください。PTRレコードの使用は避けてください。 PowerSPF（Hosted SPF） を使用してインクルードを統合し、手動でのDNSメンテナンスなしで制限内に収めましょう。フラット化プロセスそのものに関する詳細は、 「SPFのフラット化：DNSの過負荷から効率的なSPFへ」を参照してください。
DNSにSPF TXTレコードを登録する方法
SPFは、ドメインのDNSにおいて、ルートドメインレベル（例：example.com）または該当するサブドメインでTXTレコードとして公開されます。当社の 無料のSPFレコード生成ツール を利用して、公開前に有効なレコードを即座に作成してください。
| DNSフィールド | 入力値 | 備考 |
|---|---|---|
| ホスト/名前 | ルートドメインの場合は「@」または空白 | サブドメインのSPFレコードにはサブドメイン名を使用してください |
| タイプ | TXT | 従来のSPFタイプ（タイプ99）は非推奨です。常にTXTを使用してください。 |
| 価値 | SPFレコードの全文。例：v=spf1 include:_spf.google.com -all | v=spf1 から開始する必要があります |
| TTL | 3600（1時間） | TTLを下げると、変更時の伝播が速くなる |
重要： ドメインには、SPF TXTレコードを1つだけ設定する必要があります。「v=spf1」で始まるTXTレコードを複数公開すると、PermErrorが発生します。
SPF構文検証ワークフロー
ステップ 1: すべての送信元（Microsoft 365、Google Workspace、CRM、マーケティングツール、ヘルプデスクシステム、給与計算システム、および地域ごとの送信元）を洗い出します。
ステップ 2: SPFレコードを作成または更新する — 許可されたメカニズムとインクルードのみを追加してください。
ステップ 3: ルックアップ回数の確認 — レコードが10回のDNSルックアップ制限を超えないことを確認してください。
ステップ 4: 構文の検証 — SPFチェッカーツール を使用して、書式、重複、および非推奨の仕組みに関する問題を検出します。
ステップ 5: 認証結果の監視 —DMARCレポートを確認し、正当な送信者がSPFおよびDKIMの整合性チェックに合格していることを確認します。
SPFレコードの構文規則、検証、およびよくあるエラー
SPFレコードの作成は、仕組みと修飾子を正しい順序で並べ、レコードが実際に意図したとおりに動作することを確認することがすべてです。タグの欠落や余分なスペースなど、小さな構文の間違いでもレコードが失敗し、メールが拒否されたり、スパムとしてマークされたり、あなたのドメインがなりすましに遭いやすくなったりします。
このセクションでは、SPF構文を記述するためのベストプラクティス、避けるべき一般的な間違い、そして公開前にレコードを検証する方法の3つを取り上げます。
SPF構文のベストプラクティスに従う
SPFを正しく運用するには、記録を効果的かつ信頼性の高いものにするためのいくつかの黄金ルールに従うことから始まる：
- 常に正しいバージョンタグで始めます： v=spf1.
- 制限 DNSルックアップが 10ルックアップ制限レコードが壊れてしまいます。
- を使用します。 インクルードループや循環参照を防ぐために、includeメカニズムを注意深く使うこと。
- 記録はできるだけ簡潔にまとめてください。過度に複雑な設定は、メンテナンスが難しくなり、障害が発生しやすくなります。
- SPFレコードは定期的に見直しましょう。特に、メールインフラが変更になったり、プロバイダーの追加や削除を行った場合は要注意です。
MSPおよびMSSP向けのSPF構文管理
多数のクライアントドメインにわたってSPFを管理するMSPやMSSPにとって、ベストプラクティスは単に1つの正しいレコードを作成するだけにとどまりません。運用上の主な考慮事項には、以下のものが挙げられます。
- SPFテンプレートの標準化 一般的なクライアント構成（例：Google Workspace および Microsoft 365）向けに SPF テンプレートを標準化し、導入を迅速化し、構文エラーを減らします。
- ルックアップ回数の監視を自動化 クライアントのSPFレコードが10回のDNSルックアップ制限を超える前にアラートを受け取れるようにする — 特に、クライアントが新しいSaaSツールを追加した際。
- 一元化されたダッシュボードを活用して すべてのクライアントドメインにわたって、重複するSPFレコード、破損したインクルード、または欠落しているメカニズムを同時に検出します。
- 変更内容の記録 コンプライアンスやトラブルシューティングのために正確な監査証跡を維持するため、クライアントの環境に新しい送信者が追加されるたびに、ドキュメントを変更してください。
よくある構文エラーを避ける
SPFの問題の多くは、単純だが有害な間違いから生じている。これらの落とし穴に気をつけよう：
- バージョンタグが欠落しています： すべてのレコードは v=spf1で始まる必要があります。
- 重複する修飾子： 同じメカニズムに対して複数の修飾子を指定することは無効です。
- 過剰な仕組み： 長くて冗長なレコードは、エラーのリスクを高め、DNSの制限を超過する。
- 構文の書式に関する問題： スペースの配置ミス、タイプミス、またはサポートされていない文字があると、レコードの処理に失敗する可能性があります。
- 複数のSPFレコード: ドメインにはSPFレコードを1つだけ設定する必要があります。複数存在する場合、検証に失敗します。
- 非推奨の仕組み： 避ける ptrの使用は避けてください。これはもはや推奨されておらず、すべてのサーバーでサポートされているとは限りません。
たとえレコードの意図が正しくても、構文エラーはSPFを完全に失敗させる。
SPFレコードの構文を検証する
SPFレコードを公開する前に、検証を行うことが重要です。バリデータは、構文が正しいか、レコードがDNSルックアップの制限を超えていないか、サポートされていないメカニズムを含んでいないかをチェックします。
- PowerDMARCなどのSPFレコード確認ツールをご利用ください SPFチェッカーなどのSPFレコードチェックツールを使用して、問題を迅速に特定してください。
- 検証は、異なる受信メールサーバー間でレコードが一貫して機能することを保証するのに役立つ。
- 新しいレコードや更新されたレコードを本番に適用する前に、ステージング環境でテストすることをお勧めします。
- 変更後に定期的に検証を行うことで、SPFポリシーは常に最新で機能的な状態に保たれます。
バリデーションを行うことで、メールがバウンスしたり、スパムに送信されたり、ドメインがなりすましに遭いやすくなったりするリスクを減らすことができます。
SPFレコード構文の動作
SPFレコードの構文を正しく記述することは、メールの安全な配信となりすまし対策にとって極めて重要です。バージョンタグ、メカニズム、修飾子、修飾項といった各要素が連携して、メールサーバーがメッセージをどのように処理するかを指示します。
SPFの導入が拡大を続け、世界的な導入率は現在80.24%に達している中、正確かつ検証済みのSPF構文に投資する組織は、配信率、コンプライアンス、およびセキュリティ体制において、明確な優位性を得ることができます。
初期設定プロセスの詳細な手順については、 SPFレコードの設定方法をご参照ください。また、最新のコンプライアンス要件を確実に満たすためには、 2026年のGoogleおよびYahooのメール認証要件をご確認ください。
よくあるご質問
1. SPFレコードはどのように記述すればよいですか？
v=spf1 から始め、許可された送信者を指定するメカニズム（特定の IP アドレスを指定する「ip4:」や、サードパーティのサービスを指定する「include:」など）を追加し、最後に「-all」のような修飾子を付けて、それ以外のすべてをブロックするようにします。このレコードを、ドメインのルートに単一のDNS TXT レコードとして公開してください。
2. SPFレコードの構文が間違っていた場合はどうなりますか？
メールサーバーがメールを拒否したり、スパムとしてフラグを立てたりする可能性があります。また、ドメインがなりすまし攻撃を受けやすくなります。バージョンタグの欠落、SPFレコードの重複、10回のDNSルックアップ制限の超過などの構文エラーがあると、SPFが完全に機能しなくなる可能性があります。
3. MX を使用した SPF レコードの例を挙げてください。
MX を使用した SPF レコードは「v=spf1 mx -all」という形式になります。これにより、そのドメインのメール交換サーバーのみが、そのドメインを代表してメールを送信できるようになります。
4. SPFレコードでは、DNSルックアップをいくつまで許可されていますか？
RFC 7208 で定義されているとおり、SPF では 1 回の評価につき最大 10 回の DNS 検索が許可されています。カウント対象となるメカニズムには、include、a、mx、exists、redirect、および ptr が含まれます。この上限を超えた場合、SPF は PermError を返します。
5. 1つのドメインに対して複数のSPFレコードを設定することはできますか？
いいえ。ドメインには、SPF TXTレコードを1つだけ設定する必要があります。「v=spf1」で始まるレコードが複数あると、PermErrorが発生します。承認された送信者をすべて1つのレコードに統合してください。
6. SPFの「-all」と「~all」の違いは何ですか？
-all（ハードフェイル）は、受信側にリストにない送信者からのメールを拒否するよう指示します。~all（ソフトフェイル）は、受信側にメールを受け入れるがフラグを立てるよう指示します。テスト中は ~all を使用し、正当な送信者がすべて確認できたら -all に切り替えてください。
7. SPFだけでメールのなりすましを防ぐことはできますか？
いいえ。SPFはエンベロープの送信者（Return-Path）のみを検証するものであり、表示されている「From」アドレスは検証しません。なりすましやフィッシングから完全に保護するためには、DKIMおよびDMARCと組み合わせて使用する必要があります。
8.SPFフラット化とは何ですか？また、どのような場合に必要になりますか？
SPFフラット化では、インクルードの仕組みを解決済みのIPアドレスに置き換えることで、DNSルックアップの回数を削減します。これは、SPFレコードが10回のDNSルックアップという制限を超えたり、それに近づいたりした場合に必要となります。PowerSPFなどの自動化ツールは、これを動的に処理します。
9. SPFレコードの反映にはどれくらい時間がかかりますか？
DNSの反映には、通常、DNSプロバイダーやTTLの設定に応じて1～4時間かかります。場合によっては、最大48時間かかることもあります。公開後は必ずレコードを確認してください。
ドメインおよびメールセキュリティの専門家（所属： PowerDMARC
AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。
最新記事 by Ahona Rudra(全て見る)
- FAXのセキュリティ：2026年に機密文書を保護するための完全ガイド - 2026年7月30日
- メールフィルタリングサービスとは？ - 2026年7月29日
- メールのなりすまし：その仕組みと対策 - 2026年7月29日
