SPF includeとは？仕組み・正しい書き方・10回制限の対処法まで徹底解説

「外部の配信サービスを導入したら、SPFレコードにincludeを追加してくださいと言われたけれど、何をどう書けばいいのか分からない」「すでにincludeが複数あって、これ以上追加してもいいのか不安」そんな悩みを抱えるメール配信担当者やシステム管理者は少なくありません。

SPFレコードの「include」は、外部のメール配信サービスやクラウドサービスを利用する際に欠かせないメカニズムです。しかし、正しい記述方法を知らずに設定してしまうと、メールが迷惑メールフォルダに振り分けられたり、最悪の場合は受信拒否されたりする原因になります。特に2024年2月のGmail送信者ガイドライン改定以降、SPFをはじめとするメール認証技術の設定は「推奨」ではなく「必須」の段階に入りました。include周りの設定ミスが、ビジネスメールの不達に直結する時代です。

この記事では、SPF includeの基本的な仕組みから正しい記述方法、DNSルックアップ10回制限への具体的な対処法、さらによくある設定ミスとその回避策まで、メール配信の現場で必要な知識を網羅的に解説します。

SPF includeとは？基本の仕組みを理解する

SPF（Sender Policy Framework）は、送信ドメイン認証技術の一つです。ドメインの所有者がDNSサーバーにSPFレコードを登録することで、「このドメインからメールを送信してよいサーバーはどれか」を宣言し、受信側がその正当性を検証できるようにします。

SPFレコードの中でも「include」は最も利用頻度が高いメカニズムの一つです。includeを使うと、別のドメインが公開しているSPFレコードを参照し、その中に記載されたIPアドレスやサーバー情報を自社のSPFレコードに取り込むことができます。

includeが必要になる場面

たとえば、自社のメールサーバーだけでメールを送信している場合は、IPアドレスを直接指定する「ip4」メカニズムだけで事足ります。しかし、Google Workspace、Microsoft 365、メール配信システム、CRM、MAツールなど外部のクラウドサービスを経由してメールを送る場合には状況が異なります。

外部サービスのメールサーバーは、自社が管理するIPアドレスとは異なるIPから送信を行います。そのため、受信側がSPFを検証したときに「このIPアドレスは許可リストにない」と判定され、認証に失敗してしまうのです。

ここでincludeメカニズムが役立ちます。外部サービス側が公開しているSPFレコードのドメインをincludeで指定すれば、受信側は参照先のSPFレコードまで確認し、送信元IPが許可されているかどうかを判定してくれます。

includeの認証フロー

includeによるSPF認証は、以下の流れで処理されます。

たとえば v=spf1 include:_spf.google.com ~all と記述されている場合、受信サーバーは _spf.google.com のSPFレコードを参照し、GoogleのメールサーバーIPが送信元と一致すれば認証を通過させます。

SPF includeの正しい書き方と記述例

SPFレコードは、DNSのTXTレコードとして1つのドメインにつき必ず1行だけ登録します。これはRFC 7208で定められた仕様であり、2行以上のSPFレコードが存在するとPermError（永続エラー）として認証自体が無効になります。

基本構文

SPFレコードの基本構文は次の通りです。

v=spf1 [メカニズム1] [メカニズム2] ... [限定子]all

各要素の役割をまとめると、以下のようになります。

主要サービス別のinclude記述例

実務でよく使われるサービスごとのinclude値を以下に整理します。

Google Workspace（Gmail）のみを利用する場合

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

Google Workspaceと自社メールサーバーを併用する場合

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

Google WorkspaceとMicrosoft 365を併用する場合

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

さらにメール配信システム（例：ブラストメール）を追加する場合

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:spf.bmv.jp ~all

既存のSPFレコードにincludeを追加する方法

すでにSPFレコードが設定されている状態で、新たに外部サービスのincludeを追加する場合は、絶対に2行目として追加してはいけません。既存のレコードの ~all または -all の手前にスペース区切りで追記し、1行に統合します。

変更前（Google Workspaceのみ）

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

変更後（メール配信システムを追加）

v=spf1 include:_spf.google.com include:spf.bmv.jp ~all

このように、v=spf1 と ~all の間にincludeをスペース区切りで並べるのが鉄則です。

※すでにSPFレコードが存在する場合は、追記が必要です。安易な上書きは既存メールの不達を招きます

~allと-allの使い分け

SPFレコード末尾の限定子は、許可リストに含まれないサーバーからのメールをどう扱うかの指示です。

~all（SoftFail） は、許可リストにないIPからのメールを「疑わしいが一応受信する」とする設定です。設定ミスによるメール不達のリスクが低いため、多くの企業で採用されています。導入初期やテスト段階ではまずこの設定が推奨されます。

-all（HardFail） は、許可リスト外からのメールを「なりすましとして拒否する」厳格な設定です。セキュリティ面では最強ですが、includeの記述漏れがあると正規のメールまで拒否されてしまいます。すべての送信元を正確に把握した段階で切り替えるのがベストプラクティスです。

DNSルックアップ10回制限とは？超過時の影響と対処法

SPFレコードの運用で最も見落とされやすく、かつ最も深刻な問題がDNSルックアップの回数制限です。RFC 7208により、SPFの認証処理で実行できるDNSルックアップは最大10回までと定められています。

ルックアップ回数のカウント方法

DNSルックアップが発生するメカニズムは以下の通りです。

重要なのは、includeは再帰的にカウントされるという点です。たとえば include:_spf.google.com を1つ追加した場合、参照先の _spf.google.com の中にさらに3つのincludeが含まれていれば、合計4回のルックアップが消費されます。

ある調査によると、SPFレコードのルックアップ回数が10回以上に達しているドメインが約16%、9回のドメインが約9%と、全体の約25%が制限超過のリスクを抱えているとされています。外部サービスを複数利用する企業ほど、この制限に抵触しやすくなります。

10回を超えるとどうなるか

ルックアップ回数が10回を超えると、受信側のメールサーバーはPermError（永続エラー）を返します。この状態では、SPFレコードが「無効」と判断され、認証処理自体が実行されません。PermErrorの影響は以下の通りです。

特に厄介なのは、ルックアップ回数を超過していても送信者側では気づきにくい点です。DNSの設定自体はエラーなく保存でき、一部の受信先では問題なく届くケースもあるため、問題が表面化しにくいのです。

対処法①：不要なincludeの整理

まず着手すべきは、SPFレコードに登録されている不要なincludeの削除です。以前利用していたが現在は使っていないサービスのincludeが残っているケースは非常に多く見られます。定期的にSPFレコードを見直し、現在使用している送信元だけに絞り込みましょう。

対処法②：includeの重複排除

include先のSPFレコードをたどっていくと、異なるincludeが内部で同じIPアドレスやドメインを参照しているケースがあります。たとえば、サービスAのinclude内にSendGridのIPが含まれていて、別途SendGridのincludeも追加している場合は、片方を削除できる可能性があります。

対処法③：サブドメインの活用

メルマガ配信用の送信元をサブドメインに分ける方法も有効です。たとえば、通常業務のメールは example.com で送信し、メルマガは mag.example.com から送信するようにすれば、それぞれのSPFレコードを別々に管理でき、ルックアップ回数を分散できます。

対処法④：SPFフラット化

SPFフラット化（Flattening）とは、include先のSPFレコードを展開し、最終的なIPアドレスだけを直接記述する手法です。includeを使わずにip4/ip6で列記することで、ルックアップ回数を大幅に削減できます。

ただし、参照先のIPアドレスは変更される可能性があるため、手動で管理すると陳腐化のリスクがあります。自動フラット化ツールやサービスを活用し、定期的にIPリストを更新する運用が不可欠です。

※フラット化ツールを利用する際は、参照先のIP変更が即時反映される仕組みかどうかを確認しましょう

ルックアップ回数の確認方法

自社ドメインのSPFレコードがルックアップ制限に抵触していないかを確認するには、オンラインのSPFチェックツールが便利です。DMARCly（dmarcly.com）のSPF Record Checkerや、Dmarcianの「SPF Surveyor」にドメインを入力すると、ルックアップ回数が可視化されます。Google Admin ToolboxのCheck MXでも確認が可能です。

新しいサービスを導入する際や、SPFレコードを変更した際には、必ずこれらのツールで確認する習慣をつけましょう。

SPF includeでよくある5つの設定ミスと回避策

SPFレコードの設定は一見シンプルに見えますが、実際には記述ミスが多発しています。インターネット協会の記事によると、メッセージ数ベースで約10%のメールが文法的に不正なSPFレコードにより認証処理が実行されなかったと報告されています。ここでは、特にinclude周りで頻発する設定ミスを解説します。

出典: https://salt.iajapan.org/wpmu/anti_spam/admin/operation/information/spf_i01/

SPFレコードを2行に分けてしまう

最も多い失敗パターンです。メール配信システムの導入時に「includeを追加してください」と案内されたとき、既存のSPFレコードとは別に新しい行として追加してしまうケースが後を絶ちません。

【誤】

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. IN TXT "v=spf1 include:spf.example.net ~all"

【正】

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.example.net ~all"

1ドメインにつきSPFレコードは1行のみ。これは絶対に守るべきルールです。

includeの参照先が存在しない

include先のドメインが存在しない、あるいは参照先のSPFレコードが削除されている場合、PermErrorが発生します。導入当初は正常に動作していても、外部サービスの仕様変更やDNSレコードの整理で参照先が消失するケースは実際に起こり得ます。定期的にinclude先の有効性を確認しましょう。

相互参照によるループ

AドメインのSPFレコードがBドメインをincludeし、BドメインのSPFレコードがAドメインをincludeしている場合、認証処理が無限ループに陥りエラーとなります。include先ではさらにincludeやredirectを使わないようにするのが安全です。

バージョン宣言の誤記

v=spf1.0 や v=spf2 など、バージョン宣言を誤って記述するケースがあります。正しくは v=spf1 のみです。些細なタイプミスですが、SPFレコード全体が無効になる致命的なエラーです。

区切り文字の誤り

各メカニズムの区切りは半角スペース1つです。複数の空白を入れたり、カンマで区切ったりするとエラーの原因になります。また、文字列の連結時に空白文字を入れ忘れるミスも頻発しています。

SPFとDKIM・DMARCの関係｜includeだけでは不十分な理由

SPFのincludeを正しく設定することは、メール到達率の改善に大きく貢献します。しかし、SPF単体では万全のセキュリティとは言えません。

SPFが検証するのは「送信元のIPアドレス」です。メールの内容が途中で改ざんされていないか、また、メールが転送された場合にIPアドレスが変わってしまい認証に失敗するケースにはSPFだけでは対応できません。ここで重要になるのが、DKIM（電子署名によるメール本文の改ざん検知）とDMARC（SPFとDKIMの認証結果に基づくポリシー定義）です。

2024年2月のGmail送信者ガイドライン改定では、1日5,000件以上の大量送信者に対してSPF・DKIM・DMARCの3つすべての設定が必須とされました。5,000件未満の送信者であっても、SPFまたはDKIMのいずれかが求められています。

 

【2025年11月更新】2024年2月よりGmailガイドラインが変更！1日5,000件以上の配信は対応必須！

2023年10月、Gmailのメール送信者ガイドラインがアップデートされました。 Google公式：メール送信者のガイドライン このガイドライン…

SPFのincludeを適切に設定した上で、DKIMの電子署名とDMARCのポリシー設定を組み合わせることで、はじめて強固なメール認証基盤が完成します。

SPF・DKIM・DMARCとは？

メールの正当性を証明するためには、それぞれ役割の異なる3つの認証技術を理解する必要があります。

SPFの弱点（転送時の認証失敗）を補うDKIMとDMARC

「SPFが設定されていればDKIMは不要ではないか？」という疑問を持つ方もいますが、SPFには「メールの転送に弱い」という致命的な弱点があります。

メールがメーリングリストや別のアドレスへ自動転送されると、受信サーバーから見た「送信元IPアドレス」は転送サーバーのものに書き換わってしまいます。すると、本来のSPFレコード（許可リスト）と一致しなくなり、SPF認証が失敗（Fail）してしまうのです。

この弱点を補完するのがDKIMです。DKIMの電子署名はメールのデータそのものに紐付いているため、転送されて経路（IPアドレス）が変わっても認証が維持されます。

そして、DMARCは「SPFかDKIMのどちらか一方がドメインと一致して合格していれば、正規のメールとして扱う」という総合的な判断（アライメント）を行います。つまり、SPFとDKIMの両方を設定し、DMARCでポリシーを管理してはじめて、転送やなりすましに耐えうる強固なメール認証基盤が完成するのです。

さらに強固なセキュリティ対策「BIMI」

DMARCを導入し、セキュリティレベルを高めた企業が次に取り組むべきなのが「BIMI（Brand Indicators for Message Identification）」です。

BIMIは、厳しいDMARC認証に合格した正規のメールに対して、受信トレイ上で送信元企業のブランドロゴを表示させる仕組みです。GmailやApple Mail、Yahoo!メール（米国）などが対応しています。BIMIのメリットは以下の通り。

SPFのinclude設定を正しく整備することは、こうした高度なブランド保護対策（DKIM → DMARC → BIMI）へ向けた、非常に重要な第一歩となります。

BIMIについての詳細は、BIMのメリットから導入までのステップ、失敗しないためのDMARC移行ロードマップ、BIMI設定チェックリストまでをまとめたBIMI完全ガイドを無料でご用意しましたのでご活用ください。また、BIMIについてのお問い合わせやご相談も可能ですのでお気軽にお問い合わせください。

>>BIMI完全ガイドを無料でダウンロードする

>>BIMI導入について無料で相談・問い合わせする

メールの到達率を改善するならメール配信システムを活用する

SPFのinclude設定をはじめとするメール認証技術の運用は、メール配信の基盤を支える重要な要素です。しかし、DNS設定の管理やルックアップ回数の監視、DKIM・DMARCとの連携など、担当者の負荷は決して小さくありません。

こうした課題を解決するために、メール認証技術に標準対応したメール配信システムを導入する企業が増えています。SPF・DKIM・DMARCの設定をサポートし、高い到達率と配信速度を両立するシステムを選ぶことで、設定ミスによるメール不達のリスクを大幅に軽減できます。

メール配信システムを使うメリット

おすすめのメール配信システム「ブラストメール」

ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1を獲得している国内最大級のメール配信システムです。27,000社以上の導入実績に支えられた高い配信基盤と、専門知識がなくても直感的に操作できるシンプルな管理画面が特徴です。

SPFのinclude設定に不安がある方でも、ブラストメールなら導入時にSPFレコードへ追記すべき値が明確に提示されるため、スムーズに設定を完了できます。まずは無料トライアルで、メール配信環境を確認してみてください。

公式サイト：シェア1位のメール配信システム「ブラストメール」

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、SMTPリレーやAPIで既存システムと連携し、一斉配信やトランザクションメールを高速かつ確実に届けるメール配信サービスです。運用・メンテナンスはblastengine側で行われるため、常に高いIPレピュテーションが維持され、エンジニアを面倒なメールサーバー管理から解放します。

SPFのinclude設定で「ルックアップ回数が足りない」「既存のSPFレコードが複雑すぎる」といった課題を抱えるエンジニアにとって、配信基盤ごとblastengineに移行するという選択肢は、運用負荷を大幅に軽減する有効な手段です。

公式サイト：https://blastengine.jp/

まとめ

SPFのincludeは、外部のメール配信サービスやクラウドサービスを利用する上で不可欠なメカニズムです。正しく設定すれば、送信元の正当性を証明し、メールの到達率を大きく改善できます。

この記事のポイントを整理すると、次の通りです。

まず取り組むべきは、自社のSPFレコードの現状確認です。オンラインのSPFチェックツールでルックアップ回数を確認し、不要なincludeがないか、記述ミスがないかを点検しましょう。その上で、DKIM・DMARCの設定状況もあわせて確認し、メール認証環境を一括で見直すことをおすすめします。