SPF Includeとは何ですか？また、SPFレコードでどのように使用しますか？

SPFレコードは、どのサーバーがあなたのドメインを代表してメールを送信することを許可されているかを外部に通知するものです。しかし、サードパーティのプラットフォームを使ってメールを送信し始めると、状況はすぐに複雑になります。そのような場合、SPFのインクルード機能を活用すると良いでしょう。

このガイドでは、SPFのインクルードとは何か、その仕組み、そしてレコードを破損させることなく複数のインクルードを扱う方法について解説します。さらに、DMARCとの整合性を保ち、メールが確実に受信トレイに届くようにする方法についても説明します。

SPFレコードとは何ですか？

SPFレコード、または Sender Policy Framework レコードは、特定のドメインに代わって電子メールを送信する権限を持つすべてのサーバーとIPアドレスを列挙するDNS TXTレコードです。

メールが届くと、受信側のメールサーバーは送信元のDNSレコードを確認し、そのメールが正当な送信元から送信されたものであるかを確認します。送信元のIPアドレスがレコードのエントリと一致すれば、SPFは合格となります。一致しなければ、SPFは不合格となります。

SPFレコードだけではできないこと

SPFの仕組みは基礎的なものですが、理解しておくべき限界もあります：

• これは、受信者が実際に目にする「差出人」アドレスではなく、エンベロープの差出人を検証するものです
• 次の操作中にエラーが発生します メール転送、つまり、元の送信者が正当な場合でも、転送されたメールはSPF検証に失敗することがよくあります
• それだけでは防ぐことはできない ドメインのなりすましを を単独では防ぐことはできません。フィッシング攻撃の多くは、この「From」ヘッダーを標的としています

そのため、SPFは、以下も含まれるより広範な認証設定の一部として最も効果を発揮します DKIMおよびDMARC。メール保護を最大限に高めるためには、これら3つのプロトコルをすべて組み合わせて設定することを強く推奨します。

SPF Includeとは何ですか？

SPFレコードが、どの送信者があなたのドメインからメールを送信できるかを定めたルールブックだとすれば、SPFの「Include」機能は、他者が作成したルールを組み込むための仕組みです。

SPFの「Include」機能により、ドメイン所有者は、自身のSPFレコード内で他のドメインのSPFレコードを参照することで、そのドメインへの送信権限を委任することができます。サードパーティのメールサービスが使用するすべてのIPアドレスを手動で列挙する代わりに、そのドメインを単に含めるだけで、受信サーバーは、あたかも自身のSPFレコードの一部であるかのように、そのドメインのSPFレコードを取得して評価します。

SPF Includeが存在する理由

現代のメール送信は、単一のサーバーから行われることはほとんどありません。

多くの組織では、トランザクションメール、マーケティングキャンペーン、ヘルプデスクツール、CRMなどの用途において、自社のメールサーバーとサードパーティ製プラットフォームを併用しています。これらの各サービスは、自社のインフラからユーザーに代わってメールを送信しますが、その際に使用されるIPアドレスは、ユーザーが直接登録できるものではありません。

SPFのインクルード機能により、サードパーティサービスのSPFレコードを直接参照できるようになり、この問題が解決されます。

受信サーバーがSPFレコードを検証する際に「include」ステートメントを検出すると、検証プロセスの一環として、その外部ドメインのSPF TXTレコードを取得して解決します。送信元のIPアドレスが、インクルードされたレコード内のエントリと一致する場合、SPF検証は成功します。

SPF Includeの実際の動作

基本的なSPFのinclude文は、次のような形になります：

v=spf1 include:thirdpartydomain.com ~all

この例では、受信サーバーは thirdpartydomain.com の SPF レコードを検索し、他のレコードとともに評価します。

送信元のIPアドレスがそのレコードで承認されている場合、そのメールはドメインのSPF検証を通過します。

メール送信を外部委託しているドメインや、メール送信のニーズに応じて複数のベンダーを利用しているドメインにとって、インクルード機能は不可欠です。この機能がない場合、各サービスで使用されているすべてのIPアドレスを手作業で列挙する必要があり、非現実的であるだけでなく、ミスが生じやすくなります。

SPFのインクルード機能はどのように動作するのでしょうか？

SPFの「include」メカニズムを技術的な観点から理解することで、SPFが黙って失敗してしまうような設定ミスを防ぐことができます。受信サーバーが「include」ステートメントを含むSPFレコードを評価する際、次のような処理が行われます。

SPF検証プロセス

メールが受信メールサーバーに届くと、サーバーはMAIL FROMアドレスからドメインを抽出し、 DNS 検索 を行い、そのドメインのSPF TXTレコードを取得します。その後、レコードを左から右へと読み進め、一致する項目が見つかるか、レコードの末尾に達するまで、各メカニズムを評価していきます。

インクルード文に遭遇すると、次のような処理が行われます：

1. 受信サーバーは、対象ドメインのSPF TXTレコードを取得するために、追加のDNS検索を実行します
2. 送信元のIPアドレスと、対象ドメインのSPFレコードを照合します
3. そのIPアドレスが、インクルードされたレコード内の許可されたエントリと一致する場合、インクルード機構は「許可」の結果を返す
4. 一致する項目が見つからない場合、サーバーは元のレコードに含まれる残りのメカニズムの評価を続行します

「How」はDNS検索制限にどのようにカウントされるか

SPFレコード内の各includeステートメントは、少なくとも1回の追加のDNSクエリを発生させます。SPFの検証では、1回のチェックにつき最大10回のDNSルックアップに制限されているため、これは重要な点です。

すべてのインクルードは、mxやaなどのメカニズムと同様に、この制限の対象となります。インクルードされたドメインのSPFレコード自体にさらにインクルードが含まれている場合、それらもカウントされ、ルックアップの連鎖が生じ、その数が急速に膨れ上がる可能性があります。

検索回数の上限である10回を超えると、SPFはPermErrorを返すことになり、受信サーバーではこれがSPFの失敗として扱われます。これにより、送信元が完全に正当な場合でも、メールが拒否されたり、スパムフォルダに振り分けられたりする可能性があります。

SPFレコードの構文：SPFインクルードを正しく記述する方法

構文を正しく記述することは必須です。 SPFレコードの構文 にたった1つの誤りがあるだけで、他の設定がどれほど適切であっても、レコード全体が失敗する原因となります。

SPFレコードの基本構造

すべてのSPFレコードは、同じ基本的な構造に従っています：

v=spf1 [メカニズム] [修飾子:all]

• v=spf1 SPFのバージョンを宣言するもので、すべてのSPF TXTレコードの先頭に記述する必要があります
• 仕組み 許可された送信元を定義します。これには、IPアドレス、`include` によるドメイン、MXレコードなどが含まれます
• すべて は、リストされた送信元と一致しないメールの処理方法を決定する包括的なメカニズムです

SPFのインクルード文の作成

include文の正しい構文は次のとおりです：

include:domain.com

「include」とコロン（:）の間にはスペースを入れないでください。スペースを入れると構文エラーになります。以下に、複数の「include」を含むSPFレコードの完全な例を示します：

v=spf1 include:sendgrid.net include:mailchimp.com ip4:192.168.1.1 ~all

このレコードには：

• sendgrid.net および mailchimp.com は、include を通じてサードパーティ送信者として承認されています
• 192.168.1.1 は個別に割り当てられた IP アドレスです
• ~すべてがソフトフェイルとなります。つまり、許可されていない送信元からのメールはフラグが立てられますが、完全に拒否されることはありません

避けるべきよくある構文上の間違い

• 同じドメインに対して複数のSPF TXTレコードを公開しないこと。複数のSPFレコードが存在すると、DNSルックアップのループが発生し、SPFが完全に機能しなくなります。ドメインまたはサブドメインごとに、すべてのレコードを1つに統合する必要があります。
• include文のコロン（:）の後にスペースを入れる
• 誤った修飾子を使用したり、互いに矛盾する仕組みを使用したりすること
• すべてのメカニズムで記録を終了するのを忘れる

PowerDMARCの SPFレコードジェネレーター を使用して、正しい形式のレコードを一から作成できます。あるいは、既存のレコードを SPFレコード検索 ツールでチェックし、配信に支障をきたす前にエラーを確認することもできます。

複数のインクルードを含むSPFレコード：知っておくべきこと

複数のSPFインクルードを使用することは一般的であり、しばしば必要不可欠ですが、それにより複雑さが生じるため、慎重に管理する必要があります。ここでは、 SPFレコードの取り扱いに関するすべて。

なぜ複数のインクルードが必要なのか

多くの組織では、複数のプラットフォームを通じてメールを送信しています。一般的な構成としては、次のようなものがあります：

• 社内および外部へのメール送受信用のメインメールサーバー
• 注文確認や通知のためのトランザクションメールサービス
• ニュースレターやキャンペーン向けのマーケティングプラットフォーム
• 顧客とのコミュニケーションのためのCRMまたはヘルプデスクツール

これらの各サービスは、SPFレコードで承認される必要があります。そのための最も実用的な方法は、各プロバイダのSPFレコードを参照するincludeステートメントを使用することです。

DNS検索の制限に関する問題

ここで、複数のインクルードがリスクをもたらすのです。

各「include」ステートメントは少なくとも1回のDNSルックアップを発生させ、一部のサードパーティ製SPFレコード自体にもさらに「include」が含まれているため、その上にさらにルックアップが追加されます。4つや5つのプラットフォームを認証する頃には、すでに10回のルックアップ制限に近づいているか、あるいはそれを超えている可能性があります。

以下は、ルックアップがどのように積み重なるかを示した簡単な例です：

• include:sendgrid.net = 1 回のルックアップ、および SendGrid 自身のレコード内でのルックアップ
• include:mailchimp.com = 1 件の検索、および Mailchimp のレコード内のすべての項目
• include:salesforce.com = 1 つのルックアップ、および Salesforce のレコード内のものすべて
• mx = 1 回の検索
• 合計は簡単に10に達するか、それを超えることもある

制限を超えた場合、受信サーバーはPermErrorを返し、そのメールを SPF認証失敗として扱います。

DNS検索の制限内に収める方法

• 現在のSPFレコードを検証し、インクルードされたレコード内のネストされたルックアップを含め、それが引き起こすDNSルックアップの総数を数えてください
• 使用しなくなったサービスの#include文をすべて削除してください
• 可能な場合は、IPアドレス範囲が固定で、かつ明確に文書化されているサービスについては、インクルード機構をIPv4またはIPv6の直接エントリに置き換えてください
• PowerDMARCの SPFフラットニングツール を使用すると、インクルードチェーンを自動的に解決し、直接のIPアドレスに置き換えることで、総ルックアップ回数を削減できます
• 送信プラットフォームを追加または削除する際は、必ず定期的に記録を確認してください

ドメインごとにSPFレコードは1つだけ、常に

管理しているインクルードの数にかかわらず、必ず守らなければならない重要なルールがあります。それは、同じドメインまたはサブドメインに対して、SPF TXTレコードを2つ以上公開しないことです。

複数のSPFレコードが存在すると、即座にエラーが発生し、どの受信サーバーでも解決できません。すべてを1つのレコードに統合する必要があります。

サブドメインから送信する場合は、各サブドメインごとに個別のSPF TXTレコードが必要です。

SPFに関するよくある間違いとその回避方法

SPFレコードは強力ですが、一度の誤設定がメール配信全体に認証エラーを引き起こす恐れがあり、容赦がありません。さらに厄介なのは、こうしたミスの多くが明確なエラーメッセージを表示しない点です。初めてSPFを設定する場合でも、既存のレコードを監査する場合でも、注意すべきエラーとその回避方法を以下に解説します。

SPFのインクルードとDMARCへの準拠

SPFとIncludeは単独で機能するものではありません。それらの設定方法はDMARCへの準拠に直接影響を及ぼすため、一貫したメール配信率を維持するには、両者の関係性を理解することが不可欠です。

SPFがDMARCにどのように組み込まれるか

DMARC は、SPFおよびDKIMを基盤としており、認証に失敗した場合のメールの処理方法をドメイン所有者が制御できるようにします。メールがDMARCを通過するためには、以下のいずれかが満たされている必要があります：

• SPF検証に合格し、エンベロープドメインが「From」ドメインと一致しています
• DKIM検証に合格し、DKIM署名ドメインが「From」ドメインと一致しています

つまり、適切なインクルードをすべて含んだ正しく設定されたSPFレコードだけでは不十分です。SPFのアライメントも通過する必要があります。つまり、リターンパスにあるドメインが、DMARCのアライメント設定に従って「From」ドメインと一致していなければなりません。

SPFインクルードが配置に与える影響

サードパーティの送信者が返信先アドレスに自身のドメインを使用している場合、そのドメインがSPFレコードに含まれており、技術的にはそのドメインに対してSPF検証に合格するかもしれませんが、送信元ドメインとは一致しません。

このシナリオでは、DMARCは依然としてSPFチェックに失敗します。サードパーティのサービス設定を変更して、自社ドメイン下のカスタムリターンパスを使用するようにするか、あるいは代替策としてDKIMのアライメントが適切に設定されていることを確認することが不可欠です。

なぜSPFだけでは不十分なのか

SPF、DKIM、およびDMARC は連携して機能するように設計されています。SPFは送信元を検証しますが、転送時には機能しなくなります。

DKIMはメッセージ自体に署名を行い、転送後もその署名は維持されます。DMARCはこれら2つを連携させ、いずれかが失敗した際の状況を可視化し、制御できるようにします。これら3つすべてを設定することこそが、堅牢で耐障害性の高いメール認証環境を構築する唯一の方法です。

SPFと並行してDMARCを設定する

SPFのインクルードが正しく設定されているものの、まだDMARCを導入していない場合は、 DMARCの設定 のが、理にかなった次のステップとなります。

まずは「p=none」の設定から始めて、配信率に影響を与えずにメールの送信状況を監視し、その後、認証設定への信頼度が高まるにつれて、順次「隔離」や「拒否」へと移行してください。

PowerDMARCでSPFレコードを正しく設定しましょう

送信プラットフォームが1つか2つであれば、SPF Includeの管理は簡単です。しかし、メールインフラが拡大するにつれて、その複雑さも増していきます。

プラットフォームが増えれば、インクルードされるファイルも増え、DNS 照会も増え、バックグラウンドで何らかの問題が静かに発生し、配信率が低下し始めるまで気づかないというリスクも高まります。

PowerDMARCは、こうした課題に先手を打つためのツールと可視性を提供します。SPFレコードの作成と検証を支援し、すべての送信元における整合性と認証の結果を監視します。

お客様の声：

「PowerDMARCのおかげで、15種類の異なるメールサービスを1つの最適化されたSPFレコードに統合することができました。導入から1ヶ月以内に、メールの配信率が23%向上しました。」 – フォーチュン500にランクインするSaaS企業のITディレクター

メール認証を自分で管理する準備ができているなら メール認証 を管理し、SPFレコードが想定通りに機能していることを確認する準備が整いましたら、 無料トライアルを開始。

よくあるご質問

1. SPFレコードでのDNSルックアップが10回を超えた場合、どうなりますか？

SPFレコードのDNSルックアップ回数が10回を超えると、PermErrorが発生し、SPF認証が完全に失敗します。これにより、正当なメールが拒否されたり、スパムとしてマークされたりする可能性があります。制限内に収めるには、SPFのフラット化またはマクロを使用してください。

2. SPFレコードに同じドメインを複数回指定することはできますか？

技術的には可能ですが、同じドメインを複数回含めることは冗長であり、DNS検索のリソースを無駄にします。各include文は一意であるべきであり、メール認証戦略において特定の目的を果たす必要があります。

3. SPFのインクルードはどのくらいの頻度で確認すべきですか？

SPFレコードは四半期ごとに、またはメールサービスを追加・削除するたびに確認してください。認証に影響を及ぼす可能性のある不正な変更やサービスプロバイダーによる更新を検知できるよう、自動監視を設定してください。

4. SPFレコードにおける「~all」と「-all」の違いは何ですか？

~all（ソフトフェイル）は、許可されていない送信元からのメールを不審なメールとしてマークしつつも、配信を継続することを示します。-all（ハードフェイル）は、許可されていない送信元からのメールを完全に拒否するよう受信サーバーに指示します。多くの組織では、まず~allから始め、テストを経て-allに移行します。

5. SPF設定はメールの配信率に影響を与えますか？

はい、SPFの「includes」設定が不適切だと、メールの配信率に重大な影響を及ぼす可能性があります。正当なサービスに対する「includes」が不足していると、メールの認証に失敗する原因となります。一方、「includes」が多すぎると、DNS検索の制限を超過し、PermErrorが発生する原因となります。

• について
• 最新記事

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

• DKIMレコードの分割方法 - 2026年6月5日
• compauth=fail：Microsoft 複合認証の解説 - 2026年6月1日
• Windows Defenderだけで中小企業のセキュリティは十分か？ - 2026年5月14日