SPF Includeとは？SPFレコードで安全に利用する方法

簡単な答え： SPFの「include」メカニズムにより、ドメイン所有者は、自身のDNS TXTレコード内で第三者の送信者のSPFレコードを参照することで、その送信者を認証することができます。 受信サーバーがSPFレコードを評価する際に「include」ステートメントを検出すると、チェックの一環として、参照先のドメインのSPFレコードを取得して評価します。各「include」ステートメントは少なくとも1回の追加DNSルックアップを引き起こすため、PermErrorを回避するには、DNSクエリの総数を10以下に抑える必要があります。

SPFレコードは、受信メールサーバーに対して、どの送信元が貴社のドメインを代表してメールを送信することを許可されているかを伝えます。組織がマーケティング、トランザクションメッセージ、CRMの更新、またはサポートメールのためにサードパーティのプラットフォームを利用し始めると、SPFの管理を手動で行うことは難しくなります。そこで役立つのが、SPFの「include」メカニズムです。

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

SPF Include を理解する必要があるのは誰か？

SPFは、ITチーム、システム管理者、サイバーセキュリティアドバイザー、および MSP にとって最も重要な要素です。組織でCRM、ヘルプデスク、マーケティングオートメーションツール、トランザクションメールプロバイダー、クラウドメールサービスなどのプラットフォームを利用している場合、SPFレコードは1つ以上の「include」メカニズムに依存している可能性が高いでしょう。

• 複数のSaaSプラットフォーム、地域ごとの送信元、またはドメインポートフォリオを管理する企業のITおよびセキュリティチーム
• DNSレコードおよびメールの配信状況を管理するシステム管理者
• 複数のクライアントドメインにわたってSPFおよびDMARCを管理するMSPおよびMSSP
• 金融、医療、小売、公共部門などの規制対象業界におけるサイバーセキュリティアドバイザー

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

SPFレコード、または Sender Policy Framework レコードは、 DNSのTXTレコード であり、特定のドメインに代わって電子メールを送信する権限を持つすべてのサーバーとIPアドレスを列挙したものです。電子メールが届くと、受信側のメールサーバーは送信元のDNSレコードを確認し、そのメールが許可された送信元から送信されたものであるかを検証します。送信元のIPアドレスがレコード内のエントリと一致すれば、SPFは合格となります。一致しない場合は、SPFは不合格となります。

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

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

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

だからこそ、SPFは、以下も含まれるより広範な認証設定の一部として最も効果を発揮するのです。 DKIMやDMARCを含む、より広範な認証設定の一部としてSPFが最も効果を発揮するのです。これら3つのプロトコルを組み合わせて設定することで、メール保護の最高レベルを実現できます。

SPF Includeとは何ですか？

SPFレコードが、どの送信者がそのドメインからメールを送信できるかを定めた「ルールブック」であるとするなら、SPFの「include」メカニズムは、他者が作成したルールを組み込むための仕組みです。これにより、ドメイン所有者は、自身のSPFレコード内で他のドメインのSPFレコードを参照することで、そのドメインに送信権限を委任することができます。サードパーティのメールサービスが使用するすべてのIPアドレスを手動で列挙する代わりに、そのサービスのドメインを指定するだけで、受信サーバーは、あなたのSPFレコードの一部として、そのサービスのSPFレコードを取得・評価します。

SPF includeが存在する理由

現代のメール送信は、単一のサーバーから行われることはほとんどありません。企業のIT部門やセキュリティチームにとって、新しいSaaSツール、地域別のマーケティングプラットフォーム、CRM、ヘルプデスク、トランザクションメールサービスなどが時間の経過とともに追加されるにつれて、SPFの複雑さは通常増していきます。認証エラーや配信の問題を回避するためには、新しい送信元ごとに適切に認証を行い、継続的に監視し、SPFのDNSルックアップ上限（10回）内に収める必要があります。

SPFのインクルード機能は、サードパーティサービスのSPFレコードを直接参照できるようにすることで、この問題を解決します。 受信サーバーがSPFレコードを評価する際に「include」ステートメントを検出すると、検証プロセスの一環として、その外部ドメインのSPF TXTレコードを取得して解決します。含まれているドメインのSPFポリシーが送信元IPアドレスに対して「合格」を返す場合、includeメカニズムは一致とみなされ、その送信者に対するSPF評価は合格となります。そうでない場合、受信サーバーはSPFレコードの残りの部分の評価を続行します。

SPFに含まれる要素が実際にはどのようなものか

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

v=spf1 include:thirdpartydomain.com ~all

この例では、受信サーバーは thirdpartydomain.com の SPF レコードを検索し、その他のレコードと併せて評価します。送信元の IP アドレスがそのレコード内で承認されている場合、そのメールは当該ドメインの SPF チェックに合格します。「include」メカニズムは、メール送信を外部委託しているドメインや複数のベンダーに依存しているドメインにとって不可欠です。なぜなら、これがない場合、すべてのサービスで使用される IP アドレスを一つひとつ手作業で列挙しなければならず、それは非現実的である上、ミスが生じやすいからです。

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

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

SPF検証プロセス

1. メールが受信メールサーバーに届くと、そのサーバーは「MAIL FROM」アドレスからドメインを抽出し、 DNS検索 を行い、そのドメインのSPF TXTレコードを取得します。その後、レコードを左から右へと読み進め、一致する項目が見つかるか、レコードの末尾に達するまで、各メカニズムを評価していきます。includeステートメントに遭遇すると：
2. 受信サーバーは、対象ドメインのSPF TXTレコードを取得するために、追加のDNS検索を実行します。
3. 送信元のIPアドレスと、対象ドメインのSPFレコードを照合して検証します。
4. 含まれているドメインのSPFポリシーが、送信元IPに対して「合格」の結果を返す場合、インクルードメカニズムが一致し、その送信者に対するSPF評価は合格となります。
5. 一致する項目が見つからない場合、サーバーは元のレコードに含まれる残りのメカニズムの評価を続行します。

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

SPFレコード内の各「include」ステートメントは、少なくとも1回の追加のDNSクエリを発生させます。これは、SPFの検証において、1回のチェックあたりのDNSルックアップが最大10回に制限されているため重要です。「include」のほかに、「mx」や「a」などのメカニズムも、この制限にカウントされます。また、インクルードされたドメインのSPFレコード自体にさらに「include」が含まれている場合、それらもカウントされるため、ルックアップの連鎖が生じ、その数が急速に増えてしまう可能性があります。

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

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

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

SPFレコードの基本構造

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

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

SPF予選の概要

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 アドレスです
• ~all はソフトフェイルであり、許可されていない送信元からのメールはフラグが立てられるものの、完全に拒否されることはありません

チェックリスト：新しいSPFインクルードを安全に追加する方法

1. 新しい送信サービスを特定し、ベンダーから提供されたインクルードドメインを確認してください。
2. 以下のツールを使用して、現在のSPF TXTレコードを取得してください。 SPF検索ツールを使用して、現在のSPF TXTレコードを取得してください。
3. 含まれるレコード内のネストされたルックアップを含め、DNSルックアップの総数をカウントします。
4. 単一のSPF TXTレコードに、新しい「include:」メカニズムを追加してください。
5. 構文の検証には SPFレコード生成ツール または検索ツールを使用して、構文を検証してください。
6. 更新されたレコードを公開し、メールヘッダーを通じて認証結果を確認してください。
7. DMARCレポートを監視し、新しい送信者がSPFアラインメントに合格していることを確認してください。

SPFの「Include」と「Redirect」：その違いとは？

「include」メカニズムと「redirect」修飾子は、どちらも別のドメインのSPFレコードを参照しますが、その動作は大きく異なります。必要な場面で誤ってもう一方を使用してしまうことは、よくある設定ミスであり、これにより認証が気付かれないうちに機能しなくなる可能性があります。

「include」メカニズムは、他のドメインのSPFレコードに記載されている送信者を承認すると同時に、自身のSPFレコードに追加のメカニズムを含めることも可能にします。対照的に、「redirect」修飾子は、受信サーバーに対し、他のドメインのSPFレコードを自身のドメインの完全なポリシーとして使用し、自身のレコード内の他のすべての項目を置き換えるよう指示します。

よくある間違い

同じレコード内で「include」と「redirect」を併用すること。「redirect」修飾子は、レコード内に「all」メカニズムが登場するたびに無視されるため、これら2つは期待どおりに組み合わされません。ほとんどのマルチ送信者構成では、「include」が適切な選択であり、「redirect」は完全に省略されます。

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

• 同じドメインに対して複数のSPF TXTレコードを公開すると、受信サーバーがどのポリシーを適用すべきかを判断できなくなるため、PermErrorが発生します。
• include文のコロン（:）の後にスペースを入れる
• 誤った修飾子を使用したり、互いに矛盾する仕組みを使用したりすること
• すべてのメカニズムで記録を終了するのを忘れる

SPFレコード生成ツールを使えば、正しい形式のレコードを一から作成できます。また、既存のレコードをSPF検索ツールにかけることで、配信に支障をきたす前にエラーを確認することも可能です。

SPFの作用機序の比較：include 対 a、mx、ip4、ip6、および all

DNSのTXTレコードを編集する前に、どのSPFメカニズムをいつ使用すべきかを理解しておくと役立ちます。各メカニズムはそれぞれ異なる目的を果たしており、DNSのルックアップ回数にも異なる影響を与えます。

SPFの複数インクルードルールとDNS検索の制限

複数のSPFインクルードを使用することは一般的であり、多くの場合必要不可欠ですが、それによって複雑さが増すため、慎重に管理する必要があります。ここでは、 SPFレコードの取り扱いについてについて知っておくべき点を以下にまとめます。

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

多くの組織では、複数のプラットフォームを通じてメールを送信しています。一般的な構成としては、社内メールや外部への送信用としてメインのメールサーバー、注文確認や通知用のトランザクションメールサービス、ニュースレターやキャンペーン用のマーケティングプラットフォーム、そして顧客とのコミュニケーション用のCRMやヘルプデスクツールなどが挙げられます。これらそれぞれについてSPFレコードで許可設定を行う必要がありますが、その最も実用的な方法は、各プロバイダーのSPFレコードを参照する「include」ステートメントを使用することです。

MSPがSPFのインクルードを注意深く監視する必要がある理由

MSPやMSSPにとって、SPFに関連する問題はクライアント環境全体に急速に波及します。あるクライアントは新しいメールマーケティングツールを導入し、別のクライアントはCRMを変更し、さらに別のクライアントは知らず知らずのうちに複数のSPFレコードを公開してしまうかもしれません。一元的な可視性がなければ、こうした変更は、メールの配信に不具合が生じてから初めてサポートチケットとして報告されることがよくあります。 一元化されたSPFおよびDMARC管理プラットフォームを利用すれば、MSPは1つのダッシュボードから、すべてのクライアントドメインにわたる破損したレコード、未使用のインクルード、ルックアップ制限のリスク、認証エラーを特定でき、事後対応型のトラブルシューティングを削減できます。

複数のSPFインクルードにより、10回のルックアップ制限を超える可能性がある理由

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

例：可視インクルードの合計ルックアップ数が10を超える場合

目に見えるインクルードが3つあるだけでも、参照先のレコード内のネストされたインクルードを数えると、合計で10回以上のルックアップになりかねません。

1つのSPFレコードには、いくつのSPFインクルードを含めることができますか？

SPFレコードに記述できるincludeステートメントの数に厳格な制限はありません。ただし、include、a、mx、exists、redirectを含むすべてのDNSクエリ機構を合わせた場合、評価中に発生するDNSルックアップの総数は10回を超えてはなりません。この制限には、インクルードされたレコード内のネストされたルックアップも含まれます。

実際には、各参照レコードが引き起こすネストされたルックアップの数にもよりますが、ほとんどのドメインでは、制限に近づく前に3～5個のincludeステートメントを安全に使用できます。自身のSPFレコードに複数のネストされたincludeが含まれているプロバイダーに対して、6つ目や7つ目のincludeを追加すると、一見してレコード数が少ないように見えても、合計が10を超えてしまい、PermErrorが発生する可能性があります。 SPFフラット化ツール は、レコードの変更を公開する前に、ルックアップの総数をカウントし、includeチェーンを解決します。

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

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

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

管理しているインクルードの数にかかわらず適用される重要なルールとして、同じドメインまたはサブドメインに対して、SPF TXTレコードを2つ以上公開してはなりません。複数のSPFレコードが存在すると、受信サーバーがどのポリシーを適用すべきかを判断できなくなるため、SPF PermErrorが発生します。したがって、すべてのレコードを1つのレコードに統合する必要があります。サブドメインから送信する場合は、各サブドメインごとに個別のSPF TXTレコードが必要です。

一般的なメール送信設定におけるSPFインクルードの例

以下の例は、一般的なマルチプラットフォーム環境における正しいSPFインクルード構文を示しています。公開前には必ずプロバイダーのドキュメントで正確なインクルードドメインを確認し、新しいレコードについては SPFレコード検索 ツールを使用して検証してください。

メールプロバイダーは1社のみ

v=spf1 include:_spf.google.com ~all

メールプロバイダーとトランザクションメールサービス

v=spf1 include:_spf.google.com include:sendgrid.net ~all

メール配信サービス、マーケティングプラットフォーム、CRM（検索回数の推移に注目）

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ip4:203.0.113.10 ~all

無効な例

以下の2つのレコードは失敗します。その理由は以下の通りです：

v=spf1 include: sendgrid.net ~all      <- INCORRECT (space after colon) v=spf1 include:sendgrid.net            <- INCORRECT (missing all mechanism)

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

SPFレコードは強力ですが、一度設定を誤ると容赦ありません。たった1つの設定ミスが、メール配信全体にわたる認証エラーを引き起こす可能性があります。さらに厄介なのは、こうしたミスの多くが明らかなエラーメッセージを表示しないことです。SPFを初めて設定する場合でも、既存のレコードを監査する場合でも、以下のエラーには特に注意が必要です。

SPF評価結果：合格、不合格、ソフトフェイル、中立、一時エラー、および恒久エラー

各SPFの結果が何を意味するかを理解しておけば、認証の失敗を迅速に特定することができます。以下の表は、受信サーバーがSPFレコードを評価した後に返す可能性のあるすべての結果を示しています。

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

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

金融、医療、教育、小売、公共部門などの規制対象業界において、SPFへの対応は、単にメールの配信可能性に関する問題にとどまりません。これは、以下に関連する、より広範なメール認証要件を支えるものでもあります。 GoogleやYahooの送信者ルール、Microsoftの認証要件、 PCI DSS、GDPRに準拠したセキュリティ管理措置、および内部のリスク管理プログラムといった、より広範な電子メール認証要件を支援するものです。

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

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

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

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

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

サードパーティの送信者がリターンパスに独自のドメインを使用している場合、その「include」がSPFレコードに含まれており、技術的にはそのドメインに対してSPFチェックに合格するかもしれませんが、送信元ドメイン（Fromドメイン）とは一致しません。このシナリオでは、DMARCのSPFチェックは依然として失敗します。サードパーティのサービスを設定して、貴社のドメイン下のカスタムリターンパスを使用するようにするか、あるいは DKIMの整合性 がフォールバックとして適切に機能していることを確認することが不可欠です。

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

SPF、DKIM、およびDMARC は、中核となる 電子メールセキュリティ 対策として連携して機能するよう設計されています。SPFは送信元を検証しますが、転送時には機能しなくなります。DKIMはメッセージ自体に署名を行い、転送後も有効です。DMARCはこれら2つを結びつけ、いずれかが失敗した際の状況を可視化し、制御できるようにします。これら3つすべてを設定することこそが、堅牢な電子メール認証環境を構築する唯一の方法です。

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

SPFのインクルードが正しく設定されているものの、まだDMARCを導入していない場合は、 DMARCの設定 のが理にかなった次のステップです。まずは p=none のポリシーから始めて、配信率に影響を与えずにメールの送信状況を監視し、認証設定への信頼が高まるにつれて、隔離、そして拒否へと段階的に移行してください。

PowerDMARC を使って SPF のインクルードと DMARC の整合性を管理する

組織内で部門、ドメイン、地域をまたいで複数のサードパーティ送信者を利用している場合、SPFのインクルード管理は困難になります。1つの未使用のインクルード、ネストされたルックアップチェーン、あるいは不整合なリターンパスドメインだけで、手動では検出が困難な認証エラーが発生する可能性があります。

PowerDMARCは、ITチーム、セキュリティ責任者、およびMSPに対し、すべての送信元におけるSPF、DKIM、DMARCの結果を一元的に把握できる機能を提供します。 SPF管理の自動化、 DMARCレポート機能、 SPF分析、ホスト型認証サービス、および専門家によるサポートを活用することで、チームはSPFルックアップ制限によるエラーを防止し、不正な送信者を特定し、DNSの負荷を抑えつつコンプライアンスを維持することができます。

各組織は、PowerDMARC を利用して SPF の管理を一元化し、認証エラーを監視し、配信率に影響が出る前に不正な送信元を特定しています。

デモを予約する

よくあるご質問

SPFインクルードはいくつまで設定できますか？

インクルード文の数に決まった制限はありませんが、参照されたレコード内のネストされたルックアップも含め、すべてのDNSクエリの合計は10回以下でなければなりません。ほとんどのドメインでは、フラット化が必要になる前に、3～5回のインクルードを問題なく処理できます。

「include」と「redirect」の違いは何ですか？

`include` は、自身のメカニズムを有効なままに保ちつつ、別のドメインの送信者を追加します。`redirect` は、ポリシー全体を別のドメインのレコードに置き換えます。`all` メカニズムが存在する場合、`redirect` は無視されるため、この2つは併用できません。

SPFは合格しているのに、なぜDMARCは依然として不合格になるのですか？

SPFは、送信元ドメインと一致しない場合でも、サードパーティの送信者の独自ドメインとして認識されることがあります。DMARCでは一致が必須であるため、ご自身のドメインの下にカスタムリターンパスを設定するか、代替手段としてDKIMによる整合性に依存するようにしてください。

SPF PermError が発生する原因は何ですか？

よくある原因として、10回の照会制限を超過している、1つのドメインに対して複数のSPFレコードを公開している、あるいは「include:」の後にスペースが入るなどの構文エラーが挙げられます。これら3つの問題はいずれも、修正されるまで、すべての送信者に対してSPF検証に失敗します。

1つのSPFレコードで複数のサブドメインを管理することはできますか？

いいえ。送信を行う各サブドメインには、それぞれ独自のSPF TXTレコードが必要です。親ドメインのレコードはサブドメインには適用されないため、設定されていないサブドメインからのメールはSPF検証に失敗します。

SPFの照会回数を減らすにはどうすればよいですか？

未使用のサービスに対するインクルードを削除し、静的IPの送信元を直接のIPv4またはIPv6エントリに置き換え、SPFフラット化を使用してインクルードチェーンを直接のIPアドレスに解決するようにします。送信プラットフォームが追加または削除されるたびに監査を実施してください。

インクルードを追加すると、すぐにメールに影響が出ますか？

DNSの伝播が完了してからとなります。伝播には最大48時間かかる場合があります。公開する前に、ルックアップツールを使用してレコードを検証し、新しい送信者がDMARCレポートにおいてSPFの整合性チェックに合格していることを確認してください。