SPF対応ドメインの所有者は、しばしばGmailを使用して認証結果を監視し、以下のことを確認しています。 SPFレコードが誤りでなく、正しい設定になっていることを確認するために、Gmailを使用して認証結果を監視することがよくあります。Gmailは、メール送信ドメインの公開SPFレコードが見つからない場合、しばしばSPF Best Guessステータスを返します。
このガイドでは、Gmailが「Best Guess」の結果を表示するタイミングと理由について説明します。
主なポイント
- Gmailの「Best Guess」ステータスは、メール送信ドメインに対して明確なSPFレコードが公開されていないことを示しています。
- 適切なSPFレコードを設定することは、メール認証と配信性の向上に不可欠です。
- 既存のSPFレコードを定期的にチェックし、すべての正当なメールサーバーが含まれていることを確認することが重要である。
- SPFレコードは、メールサーバーを効果的に認証するために、特定の構文を使って正しくフォーマットされなければならない。
- SPFをDKIMとDMARCで補完することは、電子メールのセキュリティを強化し、なりすまし攻撃を防ぐために必要である。
GmailがSPFの "Best Guess "ステータスを返すのはいつですか？
送信者のドメインがDNS設定で明確なSPFレコードを公開していない場合、GmailはSPFの「Best Guess」ステータスを返すことがあります。このような場合、Gmailは過去のメールデータと送信者の行動に基づいて、SPFポリシーについて経験則に基づいた推測を試みます。この「最善の推測」ステータスは、明確に定義されたSPFレコードほど信頼できるものではありませんが、Gmailがある程度のメール認証を提供することを可能にします。
PowerDMARCでセキュリティを簡素化！
Gmailの「最善の推測」結果の例
Received-SPF: pass (google.com: companyname@domain.com のドメインの最良推測レコードでは、12.43.77.991 が許可された送信者として指定されている)
この例は、Gmailがdomain.comのDNSで公開されている公式SPFレコードを見つけられないことを示しています。
Gmailのフェイク！
Gmailが'Best Guess'と言っている意味は、そのドメインについてGmailが行った観察に基づいて、そのドメインの非公式なSPFレコードを作成したということです。実際には、そのようなSPFレコードはDNSに公開されておらず、Gmailは単に 推測である。確実性はないので、ドメイン所有者の裁量が尊重される。
Googleがどのような要素を考慮してドメインのSPFレコードを合成しているのかは定かではないが、Gmailのトラブルシューティングガイドによると、以下のような原因が考えられるという：
- SPFレコードの欠落または設定
- 無効または不正なSPF設定
- DNS関連の問題または停止
これはあなたの側で解決可能ですか？
SPFの "Best Guess "ステータスを解決し、ドメイン所有者としてメール配信性を向上させるには、ドメインのDNS設定で有効なSPFレコードを設定する必要があります。以下はその方法についての提案です：
SPFレコードを理解する
SPF (Sender Policy Framework)レコードはDNSのTXTレコードで、どのメールサーバーがあなたのドメインに代わってメールを送信することを許可されているかを指定します。これにより、スパマーがあなたのドメインを使ってメールを偽造するのを防ぐことができます。SPFレコードは、メールサーバーのIPアドレスまたはドメイン名を含む特定の形式で定義されています。
既存のSPFレコードをチェックする
変更を加える前に、ドメインに既存のSPFレコードがあるかどうかを確認してください。これには、オンラインのSPFレコード・チェッカーやDNSルックアップ・ツールを使用できます。既存のSPFレコードが見つかった場合は、ドメインからのメール送信に使用される正当なメールサーバーがすべて含まれているかどうかを評価します。
新しいSPFレコードを作成する
SPFレコードがない場合、または既存のSPFレコードが不完全または不正確な場合は、新しいSPFレコードを作成する必要があります。SPFレコードは、関連情報を含むDNS TXTレコードとして作成できます。
メールサーバーの決定
ドメインに代わってメールを送信する権限を持つメールサーバーを特定します。これには通常、お客様のメールサーバーと、ドメインからのメール送信に使用するサードパーティのメールサービスプロバイダが含まれます。
SPFレコードのフォーマット
SPFレコードは特定の構文で記述されます。v=spf1」タグの後に、どのサーバーがあなたのドメインのメール送信を許可されるかを定義するメカニズムが続きます。一般的なメカニズムには、"a"（ドメインのAレコード）、"mx"（ドメインのMXレコード）、"include"（他のドメインのSPFレコードを含める）、"ip4 "または "ip6"（特定のIPアドレス）などがあります。
たとえば、ドメインのMXサーバーとある特定のIPアドレスにメールの送信を許可する単純なSPFレコードは次のようになります：
v=spf1 mx ip4:192.0.2.10 -all
最良の推測」の使用は避ける
Gmailや他のメールプロバイダーが、あなたのSPFポリシーについて "Best Guess "な推測をするのを防ぐために、あなたのSPFレコードが完全で正確であることを確認してください。ソフトフェール"~"または寛容なSPFポリシーにつながる可能性のあるメカニズムの不在で "all "メカニズムを使用することは避けてください。その代わりに、SPFレコードの最後にハードフェール"-all "を使い、他のすべてのサーバーを許可されていないとみなすように指定する。
SPFレコードの公開
SPFレコードを作成したら、ドメインのDNS設定にDNS TXTレコードとして追加します。これは通常、ドメインレジストラのコントロールパネルまたはDNS管理インターフェイスから行うことができます。DNSの変更がインターネット全体に伝搬するまでに時間がかかる場合があることを覚えておいてください。
SPFレコードのテスト
SPFレコードを公開したら、無料の SPFレコードチェッカーをご利用ください。この手順により、SPFレコードが適切に設定されていることを確認でき、なりすましメール防止に効果的です。
最後に、Googleはまた、SPF最良推測ステータスにつながる可能性のあるDNSの問題をトラブルシューティングするために、ドメインホスティングプロバイダーと連絡を取ることをお勧めします。
SPFは自己満足ではない
SPFにはいくつかの欠点がある（たとえば ルックアップ制限やメール転送時のSPFの破損、SPFレコード情報の維持・更新の難しさなど）がありますが、SPFの実装を補完することで、それを上回ることができます。 DKIMと DMARC.これらのメールセキュリティプロトコルは、あなたのドメインから不正な送信者がメッセージを送信するリスクを減らし、潜在的なフィッシングやなりすまし攻撃を防ぎます。
PowerDMARC は、様々なビジネスニーズや運用パラメータに対応する様々な DMARC サービスを提供しています。DMARC に関することなら何でもご相談ください！
- 電子メールによるソルティング攻撃：隠されたテキストはどのようにセキュリティをバイパスするか- 2025年2月26日
- SPFフラット化：SPFフラット化とは何か？- 2025年2月26日
- DMARCとDKIM：主な違いと両者の連携方法- 2025年2月16日