MailData

Gmailの「Best Guess」SPFステータスとは？

Gmailの「Best Guess」SPFステータスとは？

GmailによるSPFの推測対処

2024年1月23日
著者: Ahona Rudra
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 GMAIL “Best Guess” SPF Status – What Does This Mean? の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

SPFを有効にしているドメインの所有者は、SPFレコードが誤っていないこと、正しい設定になっていることを確認するために、Gmailを使用して認証結果を監視することがよくあります。
Gmailは、メール送信ドメインの公開されたSPFレコードが見つからない場合に、しばしばSPFの「Best Guess」ステータスを返します。
このガイドは、Gmailが「Best Guess」結果であると告げる時とその理由について説明します。

GmailがSPF「Best Guess」ステータスを返すのはいつですか？

送信者のドメインに明確なSPFレコードがそのDNS設定に公開されていない場合、GmailはSPF「Best Guess」ステータスを返すことがあります。
そのような場合、Gmailは過去のメールデータと送信者の振る舞いに基づいて、SPFポリシーについて学習に基づく推測を試みます。
この「Best Guess」ステータスは、よく定義されたSPFレコードほど信頼性が高くはありませんが、Gmailにある程度のメール認証を提供することを可能にします。

Gmail「Best Guess」結果の例


Received-SPF: pass (google.com: best guess record for domain of companyname@domain.com designates 12.43.77.991 as permitted sender)

この例は、Gmailがdomain.comのDNSに公開された公式のSPFレコードを見つけることができないことを示しています。

Gmailは偽装します！

Gmailが「Best Guess」と言うときの意味は、そのドメインについてGmailが観察したことに基づいて、非公式のSPFレコードをドメイン用に作成したということです。
実際には、そのようなSPFレコードはDNSに公開されておらず、Gmailは単にそれについて推測しているだけです。
確実性はなく、したがってドメイン所有者のSPF設定が高く評価されるのです。

Googleがドメイン用のSPFレコードを合成するためにどのような要因を考慮するかは確かではありませんが、Gmailのトラブルシューティングガイドによると、それは以下の理由による可能性があります。

これはあなたの側で解決可能か？

SPF「Best Guess」ステータスを解決し、ドメイン所有者としてメールの配信性を向上させるためには、ドメインのDNS設定に有効なSPFレコードを設定する必要があります。
それを行う方法についていくつかの提案をここに示します。

SPFレコードを理解する
SPF（Sender Policy Framework）レコードは、DNS TXTレコードであり、あなたのドメインを代表してメールを送信する権限を持つメールサーバーを指定します。
これは、スパマーがあなたのドメインを使用してメールを偽造するのを防ぎます。
SPFレコードは、メールサーバーのIPアドレスやドメイン名を含む特定のフォーマットで定義されます。
既存のSPFレコードを確認する
変更を加える前に、ドメインに既存のSPFレコードがすでにあるかどうかを確認してください。
これを行うには、オンラインのSPFレコードチェッカーやDNSルックアップツールを使用できます。
既存のSPFレコードが見つかった場合は、評価して、ドメインからメールを送信するために使用されるすべての正当なメールサーバーが含まれているかどうかを確認してください。
新しいSPFレコードを作成する
SPFレコードが存在しない場合、または既存のものが不完全または不正確である場合は、新しいものを作成する必要があります。
関連情報を含むDNS TXTレコードとしてSPFレコードを作成できます。
メールサーバーを特定する
ドメインを代表してメールを送信する権限があるメールサーバーを特定します。
これには通常、独自のメールサーバーとドメインからメールを送信するために使用する第三者のメールサービスプロバイダが含まれます。
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
「Best Guess」を避ける
Gmailや他のメールプロバイダーがあなたのSPFポリシーについて「Best Guess」の推測をするのを防ぐためには、SPFレコードが完全で正確であることを確認してください。
「all」メカニズムをソフトフェイル「~」で使用することや、メカニズムの欠如を避けてください。
これらは許容的なSPFポリシーにつながる可能性があります。
代わりに、SPFレコードの最後にハードフェイル「-all」を使用して、他のすべてのサーバーを許可されていないと指定してください。
SPFレコードを公開する
SPFレコードを作成したら、それをドメインのDNS設定のDNS TXTレコードとして追加します。
これは通常、ドメインレジストラのコントロールパネルやDNS管理インターフェイスを通じて行うことができます。
DNSの変更がインターネット全体に伝播するまでには時間がかかることがあることを覚えておいてください。
SPFレコードをテストする
SPFレコードを公開した後、無料のSPFレコードチェッカーを使用してその正確性を検証してください。
このステップは、SPFレコードが適切に設定され、メールのなりすましを防ぐのに効果的であることを確認するのに役立ちます。
最後に、Googleはまた、SPFの最善の推測ステータスにつながる可能性のあるDNSの問題をトラブルシューティングするために、ドメインホスティングプロバイダーに連絡することを推奨しています。

SPFは自己完結していない

SPFにはいくつかの短所があります。

SPFの実装を、DKIMやDMARCで補完することで、これらの短所を克服することができます。
これらのメールセキュリティプロトコルは、不正な送信者があなたのドメインからメッセージを送信するリスクを減少させ、潜在的なフィッシングやなりすまし攻撃を防ぐのに役立ちます。

PowerDMARCは、異なるビジネスニーズと運用パラメーターに対応するDMARC領域のサービスを提供しています。
DMARCに関することであれば何でも、私たちに連絡してください。
私たちのチームはあなたとお話しするのを楽しみにしています！