Gmail用のSPFレコードの設定方法

適切なGoogle SPFレコードがない場合、Gmailのメール転送エージェントが正当なメールをフィッシングやスパムと誤認識する可能性があります。Google Workspaceでビジネスを運営している場合、これは重大な問題となります。

SPF（Sender Policy Framework）は、DNSのTXTレコードであり、どのメールサーバーがあなたのドメインに代わってメールを送信する権限を持つかを指定します。これはゲートキーパーとして機能し、指定されたサーバーのみがあなたに代わってメールを送信できるようにします。Googleは現在、すべての送信者に対してメール認証を要求しており、SPFの設定は必須となっています。

このガイドでは、GmailおよびGoogle WorkspaceにおけるSPFの設定方法を詳細に解説します。正しいGoogleメール用SPFレコードの構文、検証手順、避けるべきよくあるミス、そして完全な保護を実現するためのDKIMとDMARCの重ね方について説明します。

GmailのSPFレコードとは何ですか？

SPF（送信者ポリシーフレームワーク）レコードは、どのメールサーバーがあなたのドメインに代わってメールを送信する権限を持つかを指定します。 メールを受信すると、受信サーバーは「差出人」アドレスのドメインのSPFレコードを確認し、メールが許可されたサーバーから送信されているかどうかを検証します。

これは、SPF TXTレコードとしてドメインのDNSに公開されます。 このレコードには、あなたのドメインに代わってメールを送信することが許可されているサーバーのIPアドレスまたはホスト名のリストが含まれます。このレコードには複数のサーバーやサードパーティサービスを含めることができます。

許可されていない送信元からメールが送信された場合、受信サーバーはDNS TXTレコードを使用してドメインのSPFレコードを確認します。 DNS TXTレコードを使用してドメインのSPFレコードを確認します。

GmailのSPFレコードの重要性

Googleはすべてのメール送信者に認証の実装を義務付けており、大量送信者（1日あたり5,000通以上）はSPF、DKIM、DMARCの設定が必須です。これらの要件を無視すると深刻な影響が生じます。Google WorkspaceのSPFレコードがない場合：

• 受信サーバーがドメインの正当性を確認できない場合、メールがスパムとしてフラグ付けされる可能性があります。
• ドメインまたはIPアドレスがブロックリストに登録されると、配信可能性の回復は、最初から認証を設定するよりもはるかに困難になります。
• スパムメールにより、あなたのドメインの評判が低下します スパムメール 苦情が増加すると、ドメインの評判が損なわれます。これは時間の経過とともに悪化し、今後のすべての送信に影響を及ぼします。

SPFレコードは、メールのなりすましやフィッシング攻撃といった悪意のある行為からドメインを守る重要な防御手段となります。

セキュリティ面を超えて、SPFレコードを導入することで、Gmail、Outlook、Yahooなどの主要メールプロバイダーにおけるドメインの信頼性と信用度が大幅に向上します。これにより、メールがスパムフォルダではなく受信トレイに届く可能性が直接的に高まります。

SPFレコードはどのように機能するのですか？

SPFレコードは、ドメインのDNSにTXTレコードとして公開されます。これは、許可された送信元のIPアドレスとドメイン名を指定するタグで構成される、単一のプレーンテキスト行です。

SPFレコードは、DNS文字列ごとに最大255文字まで指定可能です。また、TXTレコードファイルの合計サイズは512バイトを超えてはなりません。

メールが送信されると、受信サーバーは「差出人」アドレスのドメインのSPFレコードを確認し、そのメールが許可されたサーバーから送信されたものかどうかを検証します。これは、送信サーバーのIPアドレスを、SPFレコードに公開されている許可されたIPアドレスのリストと照合することで行われます。Gmailはこのプロセスの一環として、受信メッセージを送信元のドメインのSPFレコードと自動的に照合し、正当性を確認します。

このチェックに基づき、受信メールサーバーは次のいずれかの結果を割り当てます：

• Pass 送信サーバーのIPアドレスがSPFレコードに登録されており、当該ドメインのメール送信が許可されていることを意味します。
• 失敗 は、IPが許可されていないことを意味し、メールのなりすましの可能性を示しており、メッセージは完全に拒否される可能性があります。
• ソフトフェイル とは、IPアドレスが明示的に許可されていないものの、ドメイン所有者が ~all 修飾子を使用して、サーバーが未登録のIPアドレスからのメッセージを受け入れるべきだが、おそらくフラグを立てるべきであることを示していることを意味します。
• 中立 ドメインが、そのIPが許可されているかどうかについて一切の主張を行わないことを意味します。
• なし 意味 ドメインにSPFレコードが存在しない がドメインに対して見つからなかったため、認証チェックを実行できませんでした。

SPFは、送信メールサーバーのIPアドレスがドメインの許可されたIPアドレスと一致するかどうかを検証するメール認証メカニズムを提供することで、メールのなりすましを防止します。

IPが一致せず、レコードがハードフェイル（-all）の場合、メッセージは拒否されます。ソフトフェイル（~all）の場合、メッセージは受け入れられるが疑わしいものとしてマークされる。

SPFレコードの構成要素

GmailまたはGoogle Workspace用のSPFレコードを適切に構築および解釈するには、レコードを構成する主要な仕組みと修飾子を理解する必要があります。

SPFメカニズム

すべてのSPFレコードは、どのサーバーがあなたのドメインに代わってメールを送信する権限を持つかを定義する仕組みから構成されています。

各メカニズムは、以下の例外を除き、10回のDNSルックアップ制限にカウントされます。 ip4 は直接IPアドレスを指すためルックアップが発生せず、この制限の対象外です。SPFレコードを追加する際は、この上限を超えないように注意し、検証失敗を回避してください。

SPF修飾子

すべてのメカニズムには、結果の処理方法を受信サーバーに指示する修飾子を先行させることができる。

ほとんどの Google Workspace 設定では、推奨される SPF レコードは次のとおりです。 v=spf1 include:_spf.google.com ~allです。

ソフトフェイル修飾子 ~all は、サーバーがリストにないIPアドレスからのメッセージを受け入れるべきだが、おそらくフラグを立てるべきであることを示します。これにより、不正な送信者を可視化しつつ、設定ミスによる正当なメールを即座に拒否せずに済みます。

SPFレコード設定前の前提条件

SPFレコードを設定する前に Gmail用のSPFレコードを設定する前に、以下の点を確認してください： する前に、以下の点を確認してください：

• メール送信元の完全な一覧: 貴社に代わってメールを送信するすべてのサービス（Google Workspace、マーケティングプラットフォーム、CRMシステムなど）をリストアップしてください。
• DNS管理アクセス: ドメインのDNS設定に対する管理者アクセス権を提供します
• ドメイン構造の理解: メールを送信するサブドメインに関する完全な知識を確保する
• 現在のSPFレコード確認: SPFレコードが既に存在するかどうかを確認する
• サードパーティ製サービスに関する文書: メールサービスプロバイダーからの声明を含める

💡 プロのコツ: 複数のサードパーティ送信者を抱える組織では、各サービスのSPF要件を追跡するスプレッドシートを作成しましょう。これにより、DNSルックアップの制限（10回）を超えることを防げます。

Gmail用のSPFレコードを作成して追加する方法

GoogleメールのSPFレコード設定は簡単です。設定作業はGoogle外、ドメイン登録業者のDNS設定で行います。GmailでSPFを設定する手順を以下に示します。

ステップ1: ドメイン登録業者にサインインする

Google Workspace用のSPFレコードを作成するには、ドメインを購入・管理しているドメインアカウント（GoDaddy、Namecheap、Cloudflare、またはご利用のドメインプロバイダー）にサインインしてください。

ドメインの登録先がわからない場合は、ITチームに確認するか、ドメインのWHOISレコードを調べてください。

ステップ2: DNS設定に移動する

ログイン後、DNS管理エリアを探してください。

DNS設定で、TXTレコードのセクションを探してください。ここにSPFレコードを追加します。SPFレコードはドメインのDNSにTXTレコードとして公開されるため、ほとんどのレジストラでは「SPF」という個別のレコードタイプは存在しません。

ステップ3: 既存のSPFレコードを確認する

新しいレコードを追加する前に、ドメインに既にSPFレコードが存在しないか確認してください。Gmailでは、1つのドメインにつき1つのSPFレコードしか設定できません。単一のドメインに複数のSPFレコードが存在すると、メール認証の失敗を引き起こす可能性があります。

既存のものがあれば、新しいものを作成するのではなく、次のステップでそれを編集します。

ステップ4: GoogleメールのSPFレコードを作成する

以下の値で新しいTXTレコードを追加してください：

• ホスト名 / 名前: @ （プロバイダーによっては空白の場合あり）
• レコードタイプ: テキスト
• 値: v=spf1 include:_spf.google.com ~all
• TTL: デフォルト（通常3600）

Google Workspace に推奨される SPF レコードは次のとおりです。 v=spf1 include:_spf.google.com ~allです。

他のメールサービスでメールを送信する場合は、それらをSPFレコードに含める必要があります。ドメインごとに1つのレコードしか作成できないため、すべてを1行にまとめて記述してください：

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

注意すべき点： DNSルックアップは最大10回までとし、各ルックアップは インクルード: 少なくとも1つのトリガーが発生し、ネストされたインクルードもカウントされます。 SPFレコードは、DNS文字列あたり最大255文字まで可能です。これを超える場合、ほとんどのプロバイダーは自動的に分割します。

ステップ5: 保存し、伝播に時間を確保する

SPFレコードを作成したら、変更を保存し、レコードが反映されるまで最大48時間お待ちください。

ほとんどのプロバイダーは数時間以内に更新を反映しますが、完全な更新には遅いDNSネットワークを考慮した時間枠が必要です。明らかな誤りを発見しない限り、この期間中の追加変更は避けてください。

ステップ6: SPFレコードの確認

プロパゲーションが完了したら、SPFレコードを検証するためにSPFチェッカーツールを使用し、有効かつ正しく設定されていることを確認してください。これを行う方法は2つあります：

• SPFルックアップツール: MXToolbox、Dmarcian、またはKittermanでは、ドメインを入力するだけで、GoogleメールのSPFレコードが公開されているか、構文的に有効か、10件のルックアップ制限内にあるかを即座に確認できます。
• テストメール: Gmailアドレスにメッセージを送信し、開封後、三点メニューをクリックして「元のメッセージを表示」を選択し、 spf=pass が Authentication-Results ヘッダー内に含まれているか確認してください。

ステップ7: サブドメイン用のSPFを設定する（該当する場合）

サブドメインを使用してメールを送信している場合（例： marketing.yourdomain.com）を使用している場合、プロバイダーが許可しているなら、各サブドメインごとに個別にSPFレコードを設定する必要があります。

SPFポリシーはルートドメインから継承されません。各サブドメインは独自のTXTレコードが必要です。設定手順は同一です。ホスト/名前フィールドを @ をサブドメイン名に変更するだけです。

よくあるSPFレコードの誤りと回避方法

わずかな設定ミスでもメール認証が完全に機能しなくなる可能性があります。SPFを設定する際は、複数のレコード設定や構文エラーといったよくある間違いを避けてください。以下に最も頻繁に見られる問題点を挙げます。

単一ドメイン上の複数のSPFレコード

1つのドメインにつき、SPFレコードは1つしか設定できません。

受信サーバーが2つ以上見つけた場合、永続的なエラーを返し、チェックに失敗します。追加のサービスを認証する必要がある場合は、すべてをマージしてください。 include: メカニズムを1つのレコードに統合してください。2つ目のTXTエントリを作成しないでください。

~all の代わりに +all を使用する

The +all 修飾子は受信サーバーに対し、あらゆるIPアドレスからのメールを受け入れるよう指示します。これはSPFの目的を完全に無効化します。常に以下を使用してください：

• ~すべて (ソフトフェイル): Googleが推奨するデフォルト
• -すべて (ハードフェイル): より厳格な設定で、許可されていない送信者を完全に拒否する

DNSルックアップの制限（10回）を超えました

SPFレコードは最大10回のDNSルックアップに制限されています。この制限を超えると認証が失敗します。各 include, a、 mx, and リダイレクト メカニズムはルックアップとしてカウントされ、ネストされたインクルードも同様です。制限値に近づいている場合は、SPFフラット化ツールを使用してインクルードを直接のIPアドレスに変換してください。

新しい送信元を含めるのを忘れる

新しいCRM、マーケティングツール、またはトランザクションメールサービスを追加しましたか？それらをSPFレコードに追加して更新しないと、それらのサービス経由で送信されるメールは認証に失敗します。SPFレコードを定期的に監視することで、メール配信に影響が出る前に潜在的な問題を特定できます。

GmailにおけるSPF失敗のトラブルシューティング方法

SPFレコードを設定し、プロパゲーションを待ったのに、メールがスパムフォルダに届いたり認証に失敗したりしますか？ よくあるSPFの問題を診断・修正するための簡易チェックリストをご紹介します。

• メールヘッダーを確認する: Gmailアドレスにテストメールを送信し、「元のメールを表示」をクリックして、 spf=pass, spf=softfail、または spf=fail をAuthentication-Resultsヘッダーに含める。
• SPFレコードの検証を実行してください: MXToolboxまたはDmarcianを使用して、レコードが公開されていること、構文が正しいこと、および10回のルックアップ制限内であることを確認してください。
• すべての送信者が含まれていることを確認してください: すべてのサードパーティサービス（CRM、ヘルプデスク、マーケティングプラットフォーム）がレコードに登録されていることを確認してください。未登録の送信元からメールが送信された場合、受信サーバーはSPFレコードを確認し、メッセージを拒否します。
• 重複レコードの確認: v=spf1 で始まる TXT レコードが 1 つだけ存在することを確認してください v=spf1 で始まるTXTレコードが1つだけ存在することを確認してください。単一ドメインに複数のSPFレコードが存在すると、認証失敗の原因となります。
• 定期的に監視する: 新しいツールを追加したりプロバイダーを変更した後は、SPFレコードを確認してください。問題はすぐには表面化しないことがあり、早期に発見することで配信障害を防げます。

SPFレコードの検証と監視

SPFレコードの設定は作業の半分に過ぎません。レコードに構文エラーがある場合、10件のルックアップ制限を超過している場合、または新しい送信サービスを追加した後にレコードが古くなった場合、メールは認証に失敗し始める可能性があります。定期的な検証と監視により、Gmail向けのSPFレコードが機能し続け、配信率が維持されます。

初期検証手順

• 当社の SPF検索ツール でGmailのSPFレコード設定を即座に確認できます。
• 実装したSPFレコードのTXTエントリを確認し、ステータスが有効かどうかを確認してください。
• レコードに、メール送信に使用するすべての許可済みIPアドレスとサードパーティベンダーが含まれているか再確認してください。
• 複数のSPFレコードを公開していないことを確認してください 単一のドメインに対して を発行していないことを確認してください。 メールマーケティングにGoogle Workspace以外のサードパーティベンダーを利用する場合、同じSPFレコード内で「include」メカニズムを使用できます。
• 適切な書式を維持するようにしてください。

SPFレコードに不一致が見つかった場合は、これらのエラーを修正してレコードを更新し、設定を再度確認してください。

継続的モニタリングのベストプラクティス

• SPFの定期的な確認: SPFレコードの正確性と完全性を毎月確認してください。
• メールヘッダー分析: SPF認証の結果を確認するため、定期的にメールヘッダーを検査する。
• DMARCレポートの監視: DMARCレポートを活用して、SPFの失敗や不正な送信者を特定します。
• 変更管理: 新しいメールサービスを追加する場合やプロバイダーを変更する場合は、SPFレコードを更新してください。
• 自動監視: SPF認証の失敗に対するアラートを設定する。

おすすめ記事: DMARCの設定方法：ステップバイステップ設定ガイド

PowerDMARCでDMARCとSPFを実装する

SPFをDKIMおよびDMARCと併用することで包括的な保護層が実現され、ドメインから送信されるすべてのメッセージが検証済みかつ信頼できることが保証されます。これらのプロトコルを組み合わせることで、なりすまし、フィッシング、BEC（ビジネスメール詐欺）などのメールベースのサイバー攻撃からドメインを保護します。

PowerDMARCは、以下の機能でより迅速な実現を支援します：

• 自動エラー検出: SPF設定ミス、構文エラー、ルックアップ制限違反を、メール配信に影響を与える前に検出します。
• リアルタイム監視: SPF、DKIM、またはDMARC認証が失敗した際に即時アラートを受信し、配信率が低下する前に対処できます。
• コンプライアンス報告: 業界のコンプライアンス要件を満たし、監査対応可能なレポートを生成します。これにより、自社に代わってメールを送信している担当者を完全に把握できます。
• 24時間365日専門サポート: 設定、トラブルシューティング、または適用に関するサポートが必要な際は、いつでも認定メールセキュリティスペシャリストにアクセスできます。

ある顧客はこう語っています：「PowerDMARCのおかげで、SPFの設定ミスが配信問題を引き起こす前に発見できました。サポートは最高レベルです！」 – SaaS企業 ITマネージャー

Google WorkspaceのSPFレコードの設定は、ドメイン保護に向けた第一歩に過ぎません。 今すぐPowerDMARCで 今すぐPowerDMARCで！

よくある質問 (FAQ)

1. メールにおけるSPFレコードとは何ですか？

SPF（Sender Policy Framework）レコードは、DNSのTXTレコードの一種であり、ドメインに代わってメールを送信する権限を持つメールサーバーを指定します。受信サーバーがメールが正当な送信元から来ていることを確認できるようにすることで、メールのなりすましを防止し、配信率を向上させます。

2. GmailでSPFエラーが発生した場合の対処方法は？

GmailのSPFエラーを修正するには：

• SPFレコードに「include:_spf.google.com」が含まれているか確認してください。google.com」が含まれているか確認してください。
• ドメインごとにSPFレコードを1つだけ持つようにしてください
• SPF構文が正しいことを確認してください
• DNSルックアップの制限（10回）を超過していないことを確認してください
• 変更後、DNSの伝播を待つ

3. SPFはメールセキュリティにおいて依然として有効か？

はい、SPFはメールセキュリティにおいて依然として非常に重要です。Googleはすべてのメール送信者にSPFまたはDKIMのいずれかの実装を義務付けており、SPFはDKIMやDMARCと組み合わせることでメール認証の基盤となる要素です。

4. 異なるサブドメインに対して複数のSPFレコードを設定できますか？

はい。ドメインごとに1つのSPFレコードしか設定できませんが、各サブドメインには個別のSPFレコードを設定できます。サブドメインを使用してメールを送信する場合、プロバイダーが許可しているなら、各サブドメインごとに個別にSPFレコードを設定する必要があります。SPFポリシーはルートドメインから継承されないためです。

5. SPFレコードにおける「~all」と「-all」の違いは何ですか？

~all（ソフトフェイル）は、許可されていない送信元からのメールを受け入れるが疑わしいものとしてマークすることを意味します。一方、-all（ハードフェイル）は、許可されていない送信元からのメールを拒否することを意味します。結果を監視するために~allから始め、SPFレコードが完全であると確信したら、より厳格な適用のために-allに移行してください。