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でセキュリティを簡素化！

15日間のトライアルデモを予約する

Gmailの「最善の推測」結果の例

Received-SPF: pass (google.com: [email protected] のドメインの最良推測レコードでは、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 に関することなら何でもご相談ください！

について
最新記事

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

電子メールによるソルティング攻撃：隠されたテキストはどのようにセキュリティをバイパスするか- 2025年2月26日
SPFフラット化：SPFフラット化とは何か？- 2025年2月26日
DMARCとDKIM：主な違いと両者の連携方法- 2025年2月16日

GMAIL「ベストゲス」SPFステータス - これは何を意味するのか？