Include（SPFメカニズム）

Include（SPF）とは何ですか？

SPF（Sender Policy Framework）の include メカニズムを使うと、認可された送信サーバーを定義する際に、別のドメインのSPFレコードを参照できます。マーケティングプラットフォーム、CRMツール、クラウドメールサービスなど、第三者ベンダーが組織を代理してメールを送信する場合によく利用されます。include ディレクティブを使えば、各IPアドレスを手作業でコピーするのではなく、別のドメインの認可ルールをそのまま継承できるため、SPF管理が簡単になります。

たとえば、正当なメールの送信にSendGridやMicrosoft 365といった外部サービスを利用している場合、そのSPFレコードを自社のレコードにincludeできます。これにより、ベンダーのインフラが自社を代理して送信することを受信サーバーに伝えられます。

Include メカニズムの仕組み

SPFの評価中に include 文が現れると、参照先ドメインのSPFレコードを取得して処理するために、再帰的なDNSルックアップが実行されます。そのレコードに列挙されたIPのいずれかが送信サーバーと一致すれば、SPFチェックは合格します。一致しない場合は、元のポリシーの次のメカニズムへと評価が続きます。

includeを含むSPFレコードの例：

この例では、Google WorkspaceとMicrosoft 365のSPF設定を取り込むことで、これらを経由して送信されるメールを認可しています。included レコードに列挙されたIPから送信されたメールは、そのドメインのSPF検証に合格します。

includeは複数指定できますが、それぞれがSPFの DNSルックアップ上限である10回にカウントされます。includeが多すぎると、評価中に発行されるDNSクエリが増えすぎて、SPFのpermerrorを引き起こすおそれがあります。

SPFでIncludeを使う際のベストプラクティス

include メカニズムは便利ですが、有効で効率的なSPF設定を保つには慎重に使う必要があります。

推奨されるベストプラクティスは次のとおりです。

• 維持管理されたSPFレコードを公開している、信頼できる第三者プロバイダーに対してのみincludeを使う
• 10ルックアップの上限を下回るよう、includeの数を制限する
• 複数ベンダーからのinclude連鎖（include内include）を避ける
• included SPFレコードが予期せず変更されていないか、定期的に確認する
• パフォーマンス上必要であれば、SPFレコードをフラット化する（includeをIPアドレスに変換する）
• -all や ~all といったメカニズムを使い、列挙されていない送信者に対するデフォルトのポリシーを明確に定義する

構造をシンプルに保ち、不要な入れ子を避けることで、解決を速くし、誤ったSPF失敗を減らせます。

Include メカニズムとDMARCeye

DMARCeyeは、複数のドメインにわたってSPFレコードを分析し、過剰または古い include 文によって生じる潜在的なリスクを検出します。各参照を展開してマッピングし、SPFポリシーの下でどのIPやサービスが認可されているかを示します。

この可視化により、外部プロバイダーへの依存関係を把握し、壊れた、または非推奨となったincludeを見つけ、SPFのルックアップ上限内に収めることができます。DMARCeyeの詳細なDNS分析とレポートによって、クリーンで準拠したSPF設定を保ちながら、第三者の送信者を安心して管理できます。

ご自身のSPFレコードを確認しましょう：

DMARCeyeの無料トライアルに登録して、メールドメインを保護しましょう。

DMARCおよび関連用語について詳しくは、DMARCeye用語集をご覧ください。