GmailのSPFレコード：2026年版ステップバイステップガイド

Gmailから顧客へのアップデート、採用メール、またはセールスシーケンスを送信するとします。文章は完璧で、リストもクリーンです。しかし、返信が極端に遅くなったり、最悪の場合、誰かから「メッセージが迷惑メールに入っていた」と指摘されたりすることがあります。

小規模なチームでは、まず件名、テンプレート、送信量に原因を求めがちです。それはもっともなことですが、最も一般的な原因の一つはGmailの外側、つまりDNS設定にあります。SPFレコードは、受信側のメールサーバーがGmailをあなたのドメインの承認済み送信者として扱うかどうかを決定します。

これは、Gmailベースの配信ツールを検討している場合には特に重要です。Mail Merge for Gmailのように、一般的で紛らわしい製品名には注意してください。このフレーズは特定の製品だけでなくカテゴリー全体を指すこともあるため、別のメールマージツール向けの設定アドバイスを読み、間違ったシステムに適用してしまうことが容易に起こり得ます。

GmailのSPFレコードが重要な理由

SPFを考える上で便利なのは、それを「ドメインのゲストリスト」と見なすことです。あなたのメールが他のメールサーバーに到達すると、そのサーバーは送信者がリストに載っているかどうかを確認します。Gmailがリストにあれば、メッセージが正当なものとして扱われる可能性は大幅に高まります。Gmailがリストになければ、受信者は件名を読む前にそのメッセージを疑う理由ができてしまいます。

この信頼性の問題は、日常的なビジネスシーンで現れます。創業者がオンボーディングメールを送る、人事担当者が面接の招待を送る、学校がイベントの更新情報を保護者に送るなどです。Gmail内ではすべて正常に見えても、受信側のサーバーはあなたのドメインに対する明確な承認を確認できず、それらのメッセージをより慎重に扱うようになります。

SPFが保護するもの

SPFは一度に2つの役割を果たします。

• 配信の保護: Googleがあなたのドメインに代わって送信することを許可されていると、受信サーバーに認識させます。
• ブランドの保護: 他の誰かが送信メールであなたのドメインをなりすますことを困難にします。

SPFは、どの送信システムがあなたのドメインを代表して発信し、どれがそうでないかを外部に伝えます。

もしメールマーケティングの成功率を高めたいのであれば、これは最初に行うべき技術的なチェックの一つです。適切に認証されていないドメインを、優れた文章で補うことはできません。

小さなミスが大きな問題を引き起こす理由

厄介なのは、SPFの問題が「SPFの問題」として見えないことが多い点です。メッセージは送信されるかもしれませんし、一部の受信者には届くかもしれません。しかし、他の受信者には迷惑メール扱いされたり、警告が表示されたり、あるいはサイレントフィルタリングされたりします。その一貫性のなさが、人々を混乱させる原因です。

もしメールがすでに迷惑メールフォルダに流れているなら、この設定ガイドと合わせて、メールが迷惑メールに行かないようにする方法に関する実践的な解説を確認することをお勧めします。SPFは到達率のすべてではありませんが、コンテンツを微調整して運を天に任せるのではなく、ドメインレベルで直接信頼性を向上させる数少ない修正方法の一つです。

基本的なGmail SPFレコードの作成

ドメインがGmailまたはGoogle Workspaceのみを通じてメールを送信している場合、設定は簡単です。Googleの公式SPFレコードは、Google Workspace管理者ヘルプに記載されている以下の文字列です。

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

この値は、ドメインのルートにある単一のTXTレコードとして公開する必要があります。ほとんどのDNSダッシュボードでは、ホストは @ です。Googleは3600秒（1時間）のTTLを推奨しており、Google Workspaceのドキュメントによると、DNSの変更が完全に反映されるまで最大48時間かかる場合があります。

DNSに入力する内容

GoDaddy、Cloudflare、NamecheapなどのどのプロバイダーでDNSを管理していても、フィールドは通常以下のように対応します。

1. タイプ: TXT
2. ホストまたは名前: @
3. 値またはコンテンツ: 上記のSPF文字列
4. TTL: プロバイダーが手動設定を許可している場合は 3600

ここで最も多いミスは、レコードタイプを深く考えすぎることです。多くのDNSパネルでは、SPF専用のレコードタイプは提供されていません。それは正常です。TXTレコードを作成してください。

DNSの編集が初めての場合、以下の視覚的なガイドが役立ちます。

うまくいく方法とそうでない方法

実践的なポイントは以下の通りです。

• うまくいく: ドメインのルートに、正確なGmail SPF値を持つTXTレコードを1つ追加する。
• うまくいかない: 余分なスペースを入れる、値を複数のSPFレコードに分割する、あるいはメインドメインからメールを送信しているのにサブドメインなどの誤ったホストの下で公開する。

実践的なルール: SPF値を正確にコピーし、1回だけ公開してください。別の送信者を追加する際に、2つ目のSPFレコードを作成したくなる衝動を抑えてください。

単純なGmailのみの環境であれば、これで基本的なGmail SPFレコードの設定は完了です。レコードを保存し、反映を待ち、他の変更を行う前に検証してください。

複数のメール送信者とメールマージの取り扱い

中小企業の一般的な設定はこのようなものです。スタッフはGoogle Workspaceから通常のメールを送信し、マーケティング部門はメールマージツールからキャンペーンを実行し、CRMやヘルプデスクは同じドメインから自動メッセージを送信します。SPFはこれらすべてをカバーしなければなりません。さもなければ、いずれかのシステムで認証が失敗し始めます。

ここで多くのGmail SPF設定が破綻します。Googleの基本レコードは簡単ですが、各ツールが「別の include: エントリを追加してください」と要求し、それらの追加がレコード全体にどのような影響を与えるかを誰も確認しないことで複雑化します。

最も重要な2つのルール

ルール1：ドメインに対してSPF TXTレコードを1つだけ公開する。

ルール2：SPF評価を10回のDNSルックアップ以内に収める。この制限には、各 include: 内のネストされたルックアップも含まれます。DNSパネル上では短く見えても、1つのベンダーのSPFレコードが複数のチェックに展開されるため、失敗することがあります。DMARC Reportによるこの解説は、Gmail SPF設定においてルックアップ回数が重要である理由を説明しています。

複数の送信者がいる環境では、予想以上に早くこの制限に達します。Google Workspaceに加え、メールマージ送信者、CRM、サポートプラットフォームを合わせると、各ベンダーの指示が個別に正しくても問題が発生する可能性があります。間違いは、各送信者を個別のDNSプロジェクトとして扱うのではなく、1つの統合された承認ポリシーとして扱うことです。

適切なマージの例

Gmailと他の承認済みサービスの両方があなたのドメインでメールを送信する場合、両方の送信者を同じSPFレコードに追加します。

シナリオ	正しいマージ済みSPFレコード
Gmailのみ	v=spf1 include:_spf.google.com ~all
Gmail + サードパーティ送信者1社	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail + 複数の送信者	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

これらの例は構造を示しています。実際のサードパーティの値は、各プロバイダーのドキュメントから取得する必要があります。実践的なポイントは変わりません。1つのドメインにつき1つのSPFレコードです。

実際によくある失敗パターン

私がよく目にする失敗パターンは3つです。

• 2つ目のSPFレコードが公開される: 既存のレコードを編集する代わりに、v=spf1 で始まる新しいTXTエントリを追加してしまう。
• 古いサービスが承認されたままになる: ツールを使用しなくなったにもかかわらず、その include: がDNSに残ったままルックアップを消費し続ける。
• メールマージが「ただのGmail」として扱われる: 一部のツールはGoogleのインフラストラクチャを通じて送信しますが、他のツールは独自のサーバーや接続されたプロバイダーを通じて送信します。その違いによって、SPFに別のincludeが必要かどうかが変わります。

3つ目のポイントは見落とされがちです。チームがGoogleスプレッドシートベースのワークフローを使用している場合は、DNSを触る前にそのツールがどのようにメールを送信するかを確認してください。Googleスプレッドシートからのメールマージに関するガイドはワークフローの構築に役立ちますが、SPFは依然としてそのワークフローの背後にある送信インフラストラクチャに依存します。

10回のルックアップ制限内に収める方法

まずは送信者の棚卸しから始めましょう。あなたのドメインとしてメール送信を許可されているすべてのシステムをリストアップします。マーケティングプラットフォーム、CRM、サポートツール、請求アプリ、ウェブサイトのフォーム、そしてあらゆるメールマージ製品を含めてください。

次に、厳しく整理します。

使用しなくなった送信者は削除します。2つのツールが同じプロバイダーを通じて送信していないか確認してください。もしそうなら、一方のincludeは不要かもしれません。ベンダーが複数のSPFオプションを提供している場合は、見つけたすべてのレコードを貼り付けるのではなく、ユースケースに合わせて文書化されているものを選択してください。

それでもレコードが大きすぎる場合、答えは「2つ目のSPFレコード」ではありません。答えは、承認された送信パスの数を減らすこと、あるいは場合によってはサブドメインを使用してメールストリームを分離し、メインドメインのSPFレコードを管理しやすくすることです。

新しい送信者を追加する場合は、DNS変更のレビューとして扱ってください。その送信者がまだ必要かを確認し、単一のSPFレコードを更新し、保存する前にルックアップ回数を確認してください。

SPFレコードが機能しているか確認する方法

レコードを保存したら、それで終わりだと思わないでください。検証は、特にDNSパネルがエントリを受け入れたものの、構文やルックアップ回数が間違っているような静かなミスを見つけるために重要です。

まずバリデーターを使用する

MxToolboxやdmarcian SPF Surveyorなどの公開されているSPFチェッカーから始めてください。これらは、TXTレコードが存在することを確認するだけでなく、構造を検査し、高度なルックアップの場合には、includeが多すぎるDNSルックアップを作成していないかを確認するのに役立つため便利です。

ドメイン名を入力し、結果を慎重に確認してください。確認すべきは以下の3点です。

• レコードが見つかる: ツールがパブリックDNSでSPF TXTレコードを確認できること。
• 構文が有効: 不正なメカニズム、余分なスペース、重複したSPFエントリがないこと。
• チェーンが管理可能: includeが壊れた結果に展開されていないこと。

良好な結果とは

健全なチェック結果は通常「退屈」なものです。それこそが望ましい状態です。ツールが1つのSPFレコードを見つけ、きれいに解析し、重大なエラーをフラグ立てしない状態です。

失敗した結果は通常、以下のいずれかに分類されます。

• SPFレコードが見つからない: レコードがまだ反映されていない、間違ったホストで保存された、あるいは公開されていない。
• 複数のSPFレコードが見つかった: 既存のレコードを編集する代わりに、2つ目の v=spf1 TXTレコードを追加してしまった。
• ルックアップが多すぎる: 統合された送信者リストが大きすぎる、またはネストされすぎている。

実際のメールも確認する

バリデーターは構造を確認するのに適しています。実際のメッセージは動作を確認します。

アクセス可能なGmailの受信トレイにテストメールを送信してください。メッセージを開き、Gmailの「元のメッセージを表示」オプションを使用して、認証結果を検査します。SPFが「PASS」となれば、パブリックDNSと実際の送信パスが一致しているという強力な証拠です。

検証ツールはDNSレコードが公開可能かどうかを教えてくれます。ライブテストは、実際のメールフローがDNSポリシーと一致しているかどうかを教えてくれます。

バリデーターは通過するのにライブメッセージが依然として正しく動作しない場合は、SPF単体ではなく、認証スタックの他の部分に問題がある可能性があります。

よくあるSPFレコードエラーのトラブルシューティング

SPFの問題は、変更直後に明らかになることがほとんどです。中小企業がGoogle Workspaceから提案書の送信を開始し、メールマージツールを追加した途端、返信が遅くなったりメッセージが迷惑メールに入ったりするようになります。実際には、これは複雑なメールの問題ではなく、DNSの小さなミスであることが多いです。

複数のSPFレコードが見つかった

症状: バリデーターが複数のSPFレコードを報告する、または受信サーバーが永続的なSPFエラーを返す。

原因: ドメインに v=spf1 で始まるTXTレコードが複数存在します。これは、企業がCRMや配信プラットフォームなどの2つ目の送信者を追加し、新しいベンダーの設定ガイドを文字通りに実行した後に発生します。SPFはそれらのレコードをマージしません。受信者は競合を検出し、無効として扱います。

解決策: ドメインに対してSPFレコードを1つに維持し、すべての承認済み送信者をその単一のTXTエントリにまとめます。すでに個別のレコードがある場合は、1つをマスターとして選択し、必要なメカニズムを統合してから、余分なものを削除してください。

DNSルックアップが多すぎる

症状: レコードは完全に見えるが、SPFがルックアップ制限またはpermerror結果で失敗する。

原因: SPFチェックは限られた数のDNSルックアップしか追跡できません。これは、基本的なGmail SPFガイドが見落としがちなエラーです。Google Workspaceが複数の送信者の中の一つに過ぎない環境、特にメールマージソフトウェア、ヘルプデスク、請求システム、マーケティングプラットフォームを同じドメインから使用している場合に発生します。各 include: はその下にさらにincludeを呼び出す可能性があるため、短く見えるレコードでも制限を超えることがあります。

解決策: 何か巧妙なことを試す前に、送信者リストを整理してください。ドメインからメールを送信しなくなったサービスを削除します。各ベンダーに、公開されているすべてのincludeがユースケースに必要かどうかを問い合わせてください。それでもスタックが大きすぎる場合は、サブドメインごとにメールストリームを分割します。例えば、通常のスタッフメールはメインドメインに維持し、配信や大量メールは独自のSPFポリシーを持つサブドメインに移動します。このアプローチは、ルックアップの負荷を軽減し、肥大化した1つのレコードがすべてを壊すのを防ぐため、マルチ送信者環境では最もクリーンな修正方法となることが多いです。

構文の問題とレコードの欠落

症状: DNSにはレコードが存在するが、バリデーターがフォーマットエラーをフラグ立てする、またはSPFレコードが全く見つからない。

原因: これは通常、貼り付けミス、間違ったホスト値、または誤ったフィールドへのSPF文字列の公開が原因です。cPanel、GoDaddy、Cloudflare、Google Domainsの代替サービスでは、ラベルが微妙に異なるため、初めて管理する人を混乱させます。ルートドメイン向けのレコードが www の下に入力されたり、TXT値が誤って分割されたりすることがあります。

解決策: 公開されたTXT値を、意図したレコードと1文字ずつ比較してください。認証しようとしているドメインに対してホストが正しいことを確認し、他のレコードタイプではなくTXTレコードを作成したことを確認してください。構文は正しいのにメールが失敗する場合は、カスタムドメインのメール認証設定全体を見直してください。SPFレコードは有効でも、別の認証制御が問題を引き起こしている可能性があるためです。

実践的なトラブルシューティングの順序

SPFが壊れたときは、以下の順序で確認してください。

1. 重複するSPFレコードを確認する: これは最も早く確認・修正できる問題です。
2. レコードのテキストを詳しく見直す: 誤字、スペースの欠落、余分な引用符、間違ったホストを探します。
3. すべての送信サービスをマッピングする: Google Workspace、メールマージツール、CRM、サポートプラットフォームなど、ドメインとして送信するすべてのものをリストアップします。
4. ルックアップ負荷の高いincludeをカウントする: リストが混雑している場合は、簡素化するか、一部の送信者をサブドメインに移動します。

この順序は、SPFが現場でどのように失敗するかと一致しているため、時間を節約できます。小規模なチームは最新のツールが原因だと考えがちですが、古いDNSのゴミも同様によくある原因です。これを整理する間、より広範な運用チェックリストが必要な場合は、Simply Tech Todayのメールセキュリティガイドが役立つリファレンスになります。

SPFを超えて：メール認証の次のステップ

中小企業は正しいSPFレコードを公開していても、請求書、配信、フォローアップが異なるシステムから送信され始めると、メッセージが迷惑メールに分類されるのを目にすることがあります。これは通常、Google Workspaceが日常的なメールを処理し、別のツールが同じドメインからキャンペーンやメールマージを送信するような混合環境で発生します。

SPFは、受信メールサーバーが行う判断の一部しかカバーしません。送信サーバーがあなたのドメインの使用を許可されているかどうかをチェックするだけです。それは重要ですが、メッセージが正しく署名されていることを証明するものでも、認証が失敗したときに受信サーバーに何をすべきかを伝えるものでもありません。

そこでDKIMとDMARCの出番であり、これらはマルチ送信者環境ではさらに重要になります。

DKIMはメッセージに暗号化署名を追加するため、受信サーバーはメッセージが正当であり、システムを離れた後に改ざんされていないことを確認できます。DMARCはSPFとDKIMの上に位置し、メールボックスプロバイダーに対して、あなたのドメインの認証チェックをどのように評価するかを指示します。また、レポート機能も提供しており、これはドメインを使用していることを忘れていた送信者を特定する最初の明確な手段となることがよくあります。

これは、多くの基本的なSPFガイドが見落としている点です。Google Workspace、メールマージツール、CRM、サポートプラットフォームを使用している場合、10回のルックアップ制限があるため、SPFの維持は困難になる可能性があります。DKIMはSPFだけに頼る必要性を減らすのに役立ち、DMARCはポリシーレイヤーを提供するため、ドメインが混雑した1つのTXTレコードだけで判断されることはなくなります。

SPFの後の次の技術的なステップとして、カスタムドメインのメール認証に関するこのガイドを確認してください。SPFレコードが配置された後のDKIMとDMARCの実践的な設定パスが示されています。

より広範な運用チェックリストが必要な場合は、Simply Tech Todayのメールセキュリティガイドが役立つ副読本になります。

実践的な結論は単純です。SPFは許可を設定し、DKIMはメッセージの整合性を証明し、DMARCは制御、可視性、そして複数のシステムからメールを送信するドメインを管理するためのより安全な方法を提供します。