マネージドサービスプロバイダー(MSP)は、規模と複雑性の交差点で事業を展開しています。

1つのドメインに影響を与えるSPF設定ミスは、配信性の問題を引き起こす可能性があります。同じミスが共有MSP設定に組み込まれると、数十または数百のクライアントドメインに一度に影響を与える可能性があります。

新しい送信サービスは、ドメインをSPFのDNSルックアップ制限を超えさせる可能性があります。移行により、正規の送信IPが未承認のままになることがあります。忘れられたサードパーティの依存関係が、SPFのpermerrorに変わる可能性があります。そして、手動でフラット化されたSPFレコードは、ベンダーがインフラストラクチャを変更するにつれて、静かに古くなる可能性があります。

したがって、MSPやMSSPにとって、SPFは単にオンボーディング時に設定するDNSレコードではありません。クライアント環境が変化しても正確性を維持する必要がある依存関係なのです。

このガイドでは、MSPがクライアント全体の配信性インシデントになる前に検出すべき5つのSPF設定の失敗を検証します。

SPFの合格は、自動的にDMARCが合格することを意味しません。

SPFはRFC5321.MailFromドメイン(一般的にReturn-Pathで表されます)を認証します。SPFがDMARCを満たすには、認証されたSPFドメインが、表示されるRFC5322.Fromヘッダーのドメインとも一致する必要があります。または、SPFが合格しない場合でも、有効で一致したDKIM署名がDMARCを満たすことができます。

I. 1. SPFの10ルックアップ制限の超過

何が起こるか

SPFは、SPFチェック中に評価されるDNSクエリを引き起こす項目に厳格な制限を設けています。

RFC 7208の下では、以下のメカニズムとモディファイアが制限にカウントされます:

• include
• a
• mx
• ptr
• exists
• redirect

ネストされた評価もカウントされます。

SPF評価が10個のDNSクエリを引き起こす項目を超えると、SPF実装はpermerrorを返さなければなりません。

これは、単純に見えるSPFレコードが複数のネストされたレコードに依存する可能性があるため、MSP環境では特に危険になります。

クライアントは以下を承認するかもしれません:

v=spf1 include:spf.msp-example.com include:marketing.example.net include:crm.example.net ~all

これらの3つの可視的なincludeは、必ずしも3つのSPFルックアップだけを表すわけではありません。含まれる各レコードには、追加のDNSクエリを引き起こすメカニズムが含まれている可能性があります。

MSPがこれに遭遇する理由

クライアントが以下を追加すると、ルックアップ予算は徐々に増加することがよくあります:

• Microsoft 365またはGoogle Workspace
• マーケティングプラットフォーム
• CRMシステム
• ヘルプデスクプラットフォーム
• トランザクションメールプロバイダー
• セキュリティゲートウェイ
• ERPまたは請求システム
• 削除されなかったレガシーサービス

ドメインは何年も安全に動作し、追加の送信者が承認された直後にSPF制限を超える可能性があります。

配信性への影響

SPFのpermerrorは、SPFがそのメッセージに対して成功した認証結果を提供できないことを意味します。

代わりにDMARCを満たす有効な一致したDKIM署名がない場合、メッセージはDMARCに失敗する可能性があります。

実際的な影響には以下が含まれる可能性があります:

• 認証結果にSPF permerrorが表示される
• DKIMが一致したpassを提供しない場合のDMARC失敗
• スパムフォルダへの配置
• 受信者のポリシーとその他のシグナルに応じた拒否
• メールボックスプロバイダー間での配信の不一致

MSPが検出すべき方法

トップレベルのSPFレコードに表示されるinclude:ステートメントだけをカウントしないでください。

以下を含む完全なSPF依存関係ツリーを評価してください:

include
a
mx
exists
redirect

ptrメカニズムも制限にカウントされますが、RFC 7208はその使用を明示的に推奨していません。

大規模なポートフォリオを管理するMSPの場合、ルックアップ検証は配信問題が現れた後ではなく、すべてのSPF変更の前に行う必要があります。

失敗シナリオの例

MSPが共有SPF設定に新しいメールセキュリティゲートウェイを追加します。

ゲートウェイは、独自のSPF依存関係を通じて、いくつかの追加のDNSクエリを引き起こす項目を導入します。

すでに10項目制限に近いドメインは、すぐにしきい値を超えます。

クライアントのアプリケーションについては何も変わっていません。彼らのメールは通常通り送信され続けます。しかし、SPFを評価する受信システムは現在permerrorを返します。

1つの共有設定変更が、複数クライアントの認証問題になっています。

II. 2. 送信インフラストラクチャがSPFと一致しなくなる

何が起こるか

MSPは、以下を通じてアウトバウンドメールを集中化することがよくあります:

• SMTPリレー
• クラウドメールゲートウェイ
• セキュリティプラットフォーム
• トランザクションメールインフラストラクチャ
• 共有送信サービス

クライアントのSPFレコードは、includeを通じてそのインフラストラクチャを承認する可能性があります:

v=spf1 include:spf.msp-example.com ~all

インフラストラクチャが変更されてもSPF承認が変更されない場合に問題が始まります。

典型的な原因には以下が含まれます:

1. 新しい送信IPアドレスへの移行
2. データセンターまたはクラウドリージョン間の移動
3. SMTPリレーまたはセキュリティゲートウェイの交換
4. 新しいアウトバウンドプロバイダーの導入
5. クライアントのトラフィックの一部のみを新しいインフラストラクチャ経由でルーティングする
6. 移行後に古いインフラストラクチャが承認されたままになる

失敗モード

SPFは、接続IPがRFC5321.MailFromドメインに対して承認されているかどうかを評価します。

現在の送信IPがそのドメインのSPFポリシーによって承認されていない場合、SPFは合格しません。

一致したDKIM passもない場合、DMARCは失敗します。

この区別は重要です:

SPF失敗は自動的にDMARC失敗を意味しません。

DMARCは、一致したSPF passまたは一致したDKIM passのいずれかで合格できます。

配信性への影響

インフラストラクチャのドリフトは以下を引き起こす可能性があります:

• そうでなければ正規の送信者からのSPF失敗
• DKIMが利用不可能、破損、または不一致の場合のDMARC失敗
• 異なる送信システム間での配信の不一致
• フィルタリングの増加
• 一部の受信システムによる拒否
• 特定のアプリケーションまたはメッセージタイプのみが失敗しているというクライアントレポート

MSPが検出すべき方法

以下を比較してください:

観察された送信IP

対

現在SPFによって承認されているIPアドレス

DMARC集計レポートは、実際にクライアントのドメインを使用してメールを送信しているインフラストラクチャを明らかにするため、ここで特に有用です。

MSPにとって、質問は単に以下であってはなりません:

「SPFレコードは構文的に有効ですか?」

以下でもあるべきです:

「SPFレコードは、今日実際にメールを送信しているインフラストラクチャを承認していますか?」

III. 3. サブドメイン認証のギャップ

何が起こるか

最も根強いSPFの誤解の1つは、親ドメインのSPFポリシーがそのサブドメインに自動的に適用されるというものです。

適用されません。

以下で公開されたSPFレコード:

example.com

は、以下のSPFポリシーではありません:

bounce.example.com
support.example.com
billing.example.com

SPFポリシーは、SPF識別子として使用されるドメイン(通常はRFC5321.MailFromドメイン)に対して評価されます。

たとえば、サービスが以下を使用して送信する場合:

Return-Path: [email protected]

SPF評価はbilling.example.comに関係します。

example.comのSPFポリシーは自動的に継承されません。

失敗モード

RFC5321.MailFromドメインに適用可能なSPFレコードがない場合、SPFは通常noneを返します。

これはfail、softfail、またはpermerrorとは異なります。

SPFが認証された識別子を生成していないため、DMARCに必要な一致したSPF passを提供できません。

メッセージが表示されるFromドメインと一致する署名ドメインを持つ有効なDKIM署名を持っている場合、DMARCは依然として合格する可能性があります。

MSPがこれに遭遇する理由

サブドメインは、サードパーティシステムによって頻繁に導入されます:

bounce.client.com
mail.client.com
billing.client.com
support.client.com
notifications.client.com

これらは以下で使用される可能性があります:

• カスタマーサポートプラットフォーム
• CRM
• マーケティングプラットフォーム
• 請求システム
• AWS SES
• トランザクションメールプロバイダー
• アプリケーション通知サービス

したがって、ルートドメインは完全に有効なSPF、DKIM、およびDMARCを持つことができますが、サブドメインを使用する別の送信パスは誤って認証されている可能性があります。

MSPが検出すべき方法

まず、RFC5321.MailFrom / Return-Pathドメインとして実際に使用されているドメインを特定します。

次に、それらのドメインのSPFを検証します。

たとえば:

dig TXT bounce.client.com
dig TXT billing.client.com
dig TXT notifications.client.com

重要な質問は、単にサブドメインが存在するかどうかではありません。

そのサブドメインがアウトバウンドメールのSPF識別子として使用されているかどうか、そしてもしそうなら、対応するSPFポリシーが送信者を正しく承認しているかどうかです。

失敗シナリオの例

クライアントが以下を使用する新しいトランザクションプラットフォームを導入します:

bounce.client.com

をそのReturn-Pathドメインとして。

MSPは以下でSPFを検証します:

client.com

そして設定が完了していると想定します。

しかし、bounce.client.comにはSPFポリシーがありません。

したがって、SPFはその送信識別子を認証できません。プラットフォームのDKIM設定も欠落しているか不一致の場合、DMARCは失敗します。

ルートドメインの設定は正しかったです。

送信識別子が正しくありませんでした。

IV. 4. 破損するサードパーティのSPF依存関係

何が起こるか

最近のSPFレコードは、一般的にサードパーティサービスに依存しています:

v=spf1 include:spf.provider-a.example include:spf.provider-b.example ~all

すべてのinclude:は外部依存関係を作成します。

ドメイン所有者は、事実上、別の組織が有効なSPFインフラストラクチャを維持することに依存しています。

以下の場合に問題が発生します:

1. ベンダーが古いSPF includeを廃止する
2. 組織が製品間で移行する
3. 参照されたドメインが消える
4. ベンダーが無効なSPFレコードを公開する
5. クライアントのSPFレコードが更新されずにレガシーサービスがシャットダウンされる

失敗モード

RFC 7208はinclude:の特定の動作を定義しています。

含まれるドメインの評価がnoneを生成する場合(たとえば、そこにSPFレコードが存在しないため)、include評価はpermerrorを生成します。

これは、誰もクライアントのDNSレコードを変更していないにもかかわらず、破損したサードパーティの依存関係がクライアントのドメインのSPF評価に影響を与える可能性があることを意味します。

配信性への影響

破損した依存関係は以下を引き起こす可能性があります:

• SPF permerror
• DMARCの一致したSPF passの喪失
• 一致したDKIMが合格しない場合のDMARC失敗
• クライアントポートフォリオ全体での認証の不一致
• 明らかなローカルDNS変更なしでの突然の配信問題

これは、同じサードパーティのincludeが多くの顧客ドメイン全体に現れる可能性があるため、MSPにとって特に重要です。

したがって、1つの外部依存関係がポートフォリオ全体での相関した失敗を引き起こす可能性があります。

MSPが検出すべき方法

SPF依存関係は継続的に監視する必要があります。

MSPは以下を知っているべきです:

• どのベンダーがクライアントのSPFレコードに表示されるか
• それらのベンダーがどのドメインを必要とするか
• どのクライアントが各ベンダーに依存しているか
• それらの依存関係が依然として正しく解決されるかどうか
• それらのSPFコンテンツが変更されたかどうか

DNSレコードが変更されていないことは、有効なSPFポリシーが変更されていないことを意味しません。

その依存関係がその下で変更されている可能性があります。

V. 5. 静的SPFフラット化が古くなる

何が起こるか

SPFフラット化は、DNSルックアップを減らすために時々使用されます。

サードパーティのincludeを保持する代わりに:

v=spf1 include:spf.vendor.example ~all

そのincludeの背後にある現在のIPアドレスが解決され、SPFレコードに直接配置されます:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ~all

ip4およびip6メカニズムはSPFの10項目DNSルックアップ制限にカウントされないため、フラット化はルックアップ圧力を減らすことができます。

しかし、静的フラット化は、それらのアドレスを最新に保つ責任をベンダーからドメイン管理者に移します。

問題

サードパーティのメールプロバイダーは、送信インフラストラクチャを変更できます。

彼らは以下を行う可能性があります:

• IP範囲を追加する
• IP範囲を削除する
• 新しいリージョンに拡大する
• インフラストラクチャを移動する
• 基盤となるプロバイダーを変更する

MSPが6か月前にベンダーのIPアドレスをコピーし、それらを更新しない場合、フラット化されたSPFレコードは古いスナップショットになります。

失敗モード

新しく導入されたベンダーIPから発信されたメールは、フラット化されたSPFレコードと一致しなくなる可能性があります。

その後、SPFはその送信パスの認証に失敗します。

繰り返しになりますが、DMARCは必ずしも失敗しません:有効な一致したDKIM署名が依然としてDMARC passを生成できます。

しかし、ドメインはその認証パスの1つを失っています。

これがMSPにとって重要な理由

静的フラット化は、1つの運用上の問題(過剰なDNSルックアップ)を別の問題に変換できます:

サードパーティ送信インフラストラクチャの継続的な同期。

大規模なクライアントポートフォリオ全体で、フラット化されたレコードを手動で維持することはすぐに非実用的になります。

より良い運用アプローチ

フラット化を使用する場合、継続的な監視と自動同期を伴う必要があります。

MSPは、上流プロバイダーの権威あるSPFポリシーがいつ変更されるかを検出し、それに応じて有効な承認を更新できる必要があります。

フラット化は、1回限りのDNS変更ではなく、積極的に管理されるプロセスとして扱う必要があります。

SPF問題がMSP規模でより危険になる理由

基礎となるSPFプロトコルは、組織が1つのドメインを管理するか1000のドメインを管理するかにかかわらず同じです。

運用上のリスクは異なります。

MSPは共有依存関係を導入します:

共有SPFテンプレート
        ↓
共有送信インフラストラクチャ
        ↓
共有サードパーティサービス
        ↓
共有DNS自動化
        ↓
数百の管理されたドメイン

そのチェーンのトップでのミスは、ポートフォリオ全体に伝播する可能性があります。

これにより、SPFガバナンスがSPF設定と同じくらい重要になります。

VI. MSPが文書化すべきこと

1. SPF依存関係インベントリ

以下の記録を維持してください:

• すべてのアウトバウンドメールプロバイダー
• その必要なSPF承認
• そのプロバイダーを使用しているクライアント
• 関連するReturn-Pathドメイン
• ネストされたSPF依存関係
• 現在のDNSルックアップ消費

これにより、プロバイダー変更の影響範囲を理解することが可能になります。

2. 実際の送信ソース

DNS設定だけでは、クライアントのドメインを使用しているすべてのものは表示されません。

認証テレメトリとDMARC集計レポートから観察された送信インフラストラクチャとSPF承認を比較してください。

不明なソースは調査する必要があります。

正規のソースには承認が必要な場合があります。

未承認のソースは、スプーフィングまたは未承認のサービスを示している可能性があります。

3. Return-Pathとサブドメインのマッピング

各送信サービスで使用される実際のSPF識別子を文書化してください。

たとえば:

Microsoft 365
From: client.com
Return-Path: client.com

トランザクションプラットフォーム
From: client.com
Return-Path: bounce.client.com

マーケティングプラットフォーム
From: client.com
Return-Path: marketing.client.com

これにより、認証とDMARC一致の問題を診断することがはるかに簡単になります。

4. SPF変更管理

SPF変更を展開する前に、以下を検証してください:

• 合計DNSクエリを引き起こす項目
• ネストされたインクルード
• 送信IP承認
• Return-Pathドメイン
• サードパーティの依存関係
• SPF構文
• 期待されるDMARC一致

共有設定の場合、展開前にどのクライアントドメインが影響を受けるかを計算してください。

5. レガシー送信者の削除

SPFレコードは古いサービスを蓄積する傾向があります。

すべての不要な承認は:

• 複雑さを増す
• DNSルックアップを消費する可能性がある
• 送信が承認されているインフラストラクチャのセットを拡大する
• 将来のトラブルシューティングを難しくする

サービスの廃止には、そのSPF承認の削除を含める必要があります。

SPFはDMARCの一部にすぎない

SPFは単独で評価すべきではありません。

DMARCの下では、表示されるFromドメインは、少なくとも1つの正常に認証された識別子と一致する必要があります。

実際的には:

一致したSPF PASS
        または
一致したDKIM PASS
        ↓
     DMARC PASS

どちらも一致したpassを生成しない場合:

一致したSPF PASSなし
        +
一致したDKIM PASSなし
        ↓
     DMARC FAIL

この区別は、配信性のトラブルシューティング時に重要です。

SPFエラーは、自動的にDMARCが失敗したことを意味しません。

同様に、認証されたSPFドメインが表示されるFromドメインと一致しない場合、SPF passは自動的にDMARCが合格したことを意味しません。

現在のDMARC要件は、RFC 7489の元のDMARC仕様に取って代わる、2026年5月に公開されたRFC 9989によって定義されています。

SkynagがMSPが規模でSPFを管理するのを支援する方法

クライアント、送信サービス、およびDNS依存関係の数が増えるにつれて、SPFを手動で管理することはますます困難になります。

SkynagのMSPプラットフォームは、クライアント環境全体でのメール認証管理を一元化および自動化するように設計されています。

VII. マルチテナント管理

各ドメインを個別にトラブルシューティングするのではなく、一元化されたMSP環境を通じてクライアントドメインを管理します。

これにより、MSPチームに認証設定と送信アクティビティに関するポートフォリオレベルの可視性が提供されます。

VIII. 自動送信者検出

Skynagはアウトバウンド送信ソースを識別するため、MSPはクライアントのドメインを実際に使用しているインフラストラクチャを理解できます。

これにより、正規だが文書化されていない送信者と未承認のソースを区別するのに役立ちます。

IX. SPFホスティングと最適化

Skynagは、DNS障害を防ぎ、複雑なSPF設定を手動で維持することに関連する運用上のリスクを削減するように設計された自動SPF管理と最適化を提供します。

X. SPFフラット化とドリフト防止

SPF最適化にフラット化が必要な場合、継続的な管理が重要です。

SkynagのSPFホスティングと最適化機能には、自動フラット化とドリフト防止が含まれており、送信インフラストラクチャが変更されるにつれて静的承認が古くなるリスクを削減します。

XI. 一元化されたDMARC分析

DMARC集計データは、送信ソース全体での認証結果への可視性を提供します。

一元化された管理と組み合わせることで、MSPは個々のメールシステムを手動で調査することなく認証問題を特定できます。

XII. 完全なメール認証管理

SPFは、最新のメール認証の1つのコンポーネントにすぎません。

Skynagにより、MSPは以下を管理できます:

• DMARC
• SPF
• DKIM
• MTA-STS
• TLS-RPT
• BIMI

統一された環境から。

重要なポイント

SPFには厳格な10項目DNSルックアップ制限があります。
これを超えるとpermerrorになります。ネストされたSPF依存関係はその制限にカウントされます。

SPFポリシーは親ドメインから自動的に継承されません。
MSPは、クライアントの送信サービスで使用される実際のRFC5321.MailFromドメインを理解する必要があります。

有効なSPFレコードでも間違ったインフラストラクチャを承認する可能性があります。
設定は実際の送信ソースと比較する必要があります。

サードパーティのSPF includeは外部依存関係です。
ベンダー側のDNS変更は、クライアント自身のSPFレコードに変更がなくても、クライアント認証に影響を与える可能性があります。

静的SPFフラット化には継続的なメンテナンスが必要です。
ベンダーインフラストラクチャの変更により、以前は正しかったIP承認が古くなる可能性があります。

SPF失敗は自動的にDMARC失敗ではありません。
一致したDKIMは独立してDMARCを満たすことができます。

MSP規模では、可視性が設定と同じくらい重要です。
共有テンプレートとインフラストラクチャは、個々のDNSミスをポートフォリオ全体の運用上のリスクに変えます。

XIII. クライアントポートフォリオ全体でSPFを管理

SPF問題は、管理されたドメインの数が増えるにつれて検出が困難になり、修正するのにコストがかかるようになります。

Skynagは、MSPとMSSPに、規模のために設計された一元化されたメール認証管理、自動送信者検出、SPF最適化、DMARC可視性、およびマルチテナント管理を提供します。

クライアントの配信性インシデントになる前に認証ドリフトを防ぎます。

MSP向けSkynagを探索する