Gmail の SPF レコード設定：Google Workspace のための実践ガイド

Google Workspace 用に SPF を設定するには、ルートドメインに v=spf1 include:_spf.google.com ~all を含む DNS の TXT レコードを公開します。include:_spf.google.com メカニズムは、Google のすべてのメールサーバーがあなたに代わって送信することを承認します。ドメインからメールを送信するサードパーティのサービスがほかにもある場合は、RFC 7208 で定義された 10 回の DNS ルックアップ制限の範囲内に収まるように、include または ip4/ip6 メカニズムを追加してください。

2024 年 2 月の Google の大量送信者向け要件によれば、Gmail ユーザーに 1 日あたり 5,000 通以上のメッセージを送信するドメインは、SPF または DKIM 認証と、少なくとも p=none の公開済み DMARC ポリシーを備えている必要があります。これにより、適切な SPF 設定は単なるベストプラクティスではなく、コンプライアンス上の要件となっています。

「Google Workspace の管理者は、すでに 8〜9 個の include が設定された SPF レコードを引き継ぐことがよくあります。そこに _spf.google.com を追加すると 10 回のルックアップ制限を超えてしまい、突然、正当なメールがバウンスし始めるのです」と、AutoSPF のゼネラルマネージャーである Brad Slavin は述べています。「解決策は送信者を削除することではなく、レコードをフラット化して、すべてのサービスが RFC 7208 の制限内で承認された状態を保つことです。」

Google Workspace やその他数十のプラットフォームを網羅した設定手順については、SPF レコード設定ガイドをご覧ください。

Sender Policy Framework（SPF）は、どのサーバーがあなたのドメインに代わってメールを送信できるかを Gmail やその他のプロバイダーが検証するのに役立つ、基盤となるメール認証の仕組みです。Google Workspace を利用する組織にとって、適切に公開された SPF レコードは、受信システムに信頼性を示しなりすましやフィッシングを抑止することで、メールの到達性を高め、セキュリティを強化し、データ保護を支えます。

ビジネスとコンプライアンスへの影響

メール認証はなりすましのリスクを低減し、本人確認やアクセス制御に関する法的およびコンプライアンス上の義務を支えます。多層的なセキュリティ戦略の一環として、DMARC や DKIM を補完します。
SPF レコードが DNS 上で正確であることを確認するといった、堅実なドメイン管理の実践は、ブランドの評判を守り、サポートやトラブルシューティングに伴うヘルプデスクの負荷を軽減します。
管理者は Google Workspace の管理コンソールを使用して、サービスの設定と管理、構成の確認を行い、レポートやモニタリングを活用して認証の整合性を追跡でき、監査への備えを支援します。

管理者にとっての運用上のメリット

明確な承認シグナルによって、Gmail での誤検知が減り、受信トレイへの配置が改善されます。
データ移行の際や、メールを送信するアプリを展開する際に特に、ユーザー管理がより簡単になります。ポリシーがエンドポイントに分散されるのではなく、DNS に一元化されているためです。
デバイス管理や社内アプリのセキュリティ設定と整合し、未検証のアプリや連携によるシャドー IT のリスクを最小限に抑えます。

SPF メカニズムと修飾子

SPF の仕組み：メカニズム、修飾子、DNS TXT の基礎

SPF は、ルートドメイン上の DNS TXT レコードを通じて定義されます。受信側は、MAIL FROM ドメインの SPF レコードを評価して、合格か不合格かの結果を判断します。以下のメカニズムのいずれかになじみがない場合は、当社の SPF 用語集がそれらを定義しています。

SPF メカニズム：構成要素

一般的なメカニズムには次のものがあります。

a および mx：ドメインの A または MX ホストによる送信を承認します。
ip4 および ip6：明示的な IP 範囲を許可します。
include：別のドメインの SPF レコードに委任します（たとえば Google のもの）。
exists および ptr：高度／レガシーなオプション。控えめに使用してください。
all：最後に記述すべき、すべてを受け止める包括的なメカニズムです。

修飾子とポリシーの意味

+（pass）は省略された場合に暗黙的に適用されます。
~（softfail）は「承認されていないが、受け入れてフラグを立てる」ことを示します。
-（fail）は承認されていない送信元をただちに拒否します。
?（neutral）は何の主張も行いません。

ほとんどの組織は、混乱を抑えるためにまず ~all から始め、送信者のマッピングが完了したら -all へと厳格化します。 さまざまな SPF レコードの種類について詳しくは、当社の完全ガイドをご覧ください。

管理者向け DNS TXT の基礎

SPF レコードは、v=spf1 で始まる単一の TXT 文字列として DNS に配置してください。
include、a、mx、ptr、exists の全体で、10 回の DNS ルックアップ制限を守ってください。
レコードは 1 文字列あたり 255 文字未満に保ってください（必要に応じて引用符で分割します）。
メール経路がいつ調整されるのかを管理者が把握できるよう、管理コンソールの変更カレンダーで変更を調整してください。
レポートやモニタリングツールを使用して変更を検証し、エラーを事前に解決してください。

送信者をマッピングする：Google、サードパーティのプラットフォーム、ネットワークの送信元

SPF を設定する前に、あなたのドメインを使用して送信するすべてのシステムを棚卸ししてください。これはドメイン管理の中核であり、アプリや連携が変化していく中でのずれを軽減します。

メール送信者の送信元

ファーストパーティ：Google と自社ネットワーク

Gmail および Google Workspace のサービス：include:_spf.google.com で承認してください。

Apps Script やクラウドアプリケーションのワークフローを介して送信する Google のサービスも、正しくルーティングされていれば、Google の SPF インフラストラクチャを通じて認証されます。

自社ネットワークの送信経路：デバイスやリレーが直接送信する場合は、ip4/ip6 メカニズムを追加してください。ユーザー管理や IT がそれらの IP を誰が保守しているかを把握できるよう、デバイス管理の責任者を文書化してください。

サードパーティのアプリと連携

多くのサードパーティ製アプリは、あなたに代わってシステムメール、アラート、通知を送信します。例としては、15Five、4me、Adaptive Insights、Adobe Acrobat Sign、Aha!、Amazon Business、Amazon Web Services 上のサービス、AppDynamics、Asana、Atlassian Cloud、Automox、BambooHR、Betterworks など、多数があります。それぞれについて、次の点を確認してください。

SPF の include を提供しているか（推奨）、専用 IP が必要かを確認します。
Marketplace の管理では、Marketplace アプリを管理し、管理者がインストールしたアプリ、アプリのアクセスリクエスト、検証済みサードパーティアプリの状態を追跡します。
OAuth 2.0 と SSO の手法（SAML、SAML ベースの SSO、統合された SAML アプリ、またはサードパーティ IdP を介したカスタム SAML アプリ）を用いてアクセスを承認し、アプリのアクセスを制御します。SAML 証明書を維持し、SSO 設定を整え、SSO のサインインフローを監視します。
サードパーティ製アプリにはアプリの許可リストを設定し、アプリのアクセスを定期的に見直し、サポートされている場合はトークンの自動失効を有効にして、データアクセスを責任を持って管理します。

2025 年の Egress のレポートによると、過去 12 か月間に 94% の組織がメールのセキュリティインシデントを経験しており、その多くは、DNS を更新しないまま追加されたサードパーティ送信者向けの、誤設定または欠落した SPF レコードに起因していました。

連携ガバナンスのチェックリスト

通知内で正しい送信者 ID が使われるよう、カスタム属性とユーザースキーマをマッピングします。
明示的に承認されていない限り、プライベートな Web アプリや社内アプリが外部メールを送信しないことを確認します。
一貫した管理と、より迅速なサポートおよびトラブルシューティングのために、ポリシーをトレーニングガイドに文書化します。

Google Workspace の基本 SPF レコード

DNS ホストを特定してアクセスする：前提条件と権限

あなたの SPF レコードは DNS 上にあります。ドメインのゾーンがどこでホストされているか、そして誰にそれを変更する権限があるかを、必ず把握しておいてください。

DNS プロバイダーと権威ゾーンを特定する

レジストラまたはホスティングプロバイダーのダッシュボードを確認するか、NS レコードを照会して、DNS がどこで管理されているかを突き止めます。多くの組織は、Amazon Web Services が提供するようなクラウド DNS サービスを利用しています。
サブドメインのニーズ（marketing.example.com と example.com など）は個別に検証し、事業部門をまたいで一貫したドメイン管理を確保します。
ベンダーがサブドメインや CNAME をプロビジョニングする場合は、SPF の分断を避けるために調整します。

役割、アクセス、変更管理を確認する

特権管理者と指定された管理者が、DNS ポータルと管理コンソールの両方に対するアクセス制御を持っていることを確認します。
更新時に変更が滞らないよう、請求とサブスクリプションの所有権を整合させます。
実装の概要と変更チケットを使用し、メンテナンスウィンドウをスケジュールして、伝播の監視を計画します。

プロセスの衛生と可観測性

すべての DNS 変更を記録します。変更前後の SPF レコードの値を取得します。
変更後、レポートとモニタリングを使用して Gmail での認証結果を確認します。
必要に応じて、連携が MAIL FROM を書き換えたり、異なるゲートウェイ経由でルーティングしたりする場合のデータ同期への影響を検証します。

Google Workspace 向けの基本レコードを構築する

ほとんどの Google Workspace テナントにとって最も安全な出発点は、Google の include と softfail を公開することです。これが初めての方は、SPF レコードの作成方法に関する当社のガイドで基本を解説しています。これにより Gmail と主要な Google の送信者が承認され、同時に取りこぼしを特定できるようになります。

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

すべてのサードパーティ送信者をマッピングし、その SPF の include を確認したら、それらをレコードに追加します。10 回のルックアップ制限を超える場合は、入れ子になった include を IP アドレスへと解決する SPF フラット化を検討してください。あるいは AutoSPF を利用すれば、フラット化を自動化し、手動での DNS 管理なしにレコードを準拠した状態に保てます。