10,000以上の企業から信頼され、メールセキュリティのエキスパートがサポート
SPFチェッカーの仕組み
ドメイン入力
ツールボックスにドメイン名を入力し(例:company.com)、「Lookup」をクリックします。
結果概要
このツールは、SPFの有効性、DNSおよびvoid lookupの回数、および問題数をチェックします。
SPF結果詳細
検出されたタグと同様に、SPF検証結果の詳細な概要を表示します。
検出された問題
SPFコンフィギュレーションで検出された問題の説明と、詳細を表示するオプション。
SPFチェッカーの問題点
有効 オプションを選択
あなたのSPFレコードは有効で、正しく、機能しています。
v=spf1 include:example.com -all
無効 構文と書式のエラー
SPFレコードの誤った構文やフォーマットによるエラー
- 構文エラー
- スペース不足
- 不正な区切り記号
- タイプミス
- レコードのヌル値
v=spf1include:example.com-all(レコード構文に必要なスペースがありません。)
v=spf1 include:example.com -all
無効 コンフィギュレーション・エラー
SPFレコードのメカニズムやディレクティブの不適切な設定に起因する問題。
- 誤ったメカニズムの使用
- 不正なIPアドレスの指定
- 複雑すぎるSPFレコード
- PTRの問題
a:mail.example.com(誤ったメカニズムの使用)
mx:mail.example.com
無効 リソースの制限
DNSルックアップの制限やSPFレコードの長さに起因する問題。
- DNSルックアップが多すぎる
- SPFレコードの文字数制限の超過
- ボイド・ルックアップ
- 再帰
example.com SPF レコード: v=spf1 include:sub.example.com -all (再帰的 SPF 検索構造)
example.com SPFレコード: (v=spf1 include:spf.anotherdomain.com -all)
無効 認可と範囲の問題
送信サーバーの正しい認可とSPFポリシーの実施レベルに関する問題。
- すべての送信サーバーを含まない
- ハードフェイルとソフトフェイルのコンフィギュレーション
すべての正当な送信サーバーを含んでいない(重要なIPやドメインが欠けているなど)
正しく有効な送信元をすべて含めるようにします(v=spf1 include:_spf.google.com include:_spf.protection.outlook.com -all)。
無効 サードパーティへの依存
サードパーティのサービスやSPFレコードの設定に依存することで発生する問題
- 第三者への委任
- サードパーティのSPFレコードの設定ミス
v=spf1 include:broken.thirdparty.com -all
サードパーティの依存関係(v=spf1 include:_spf.sendgrid.net include:_spf.google.com -all)から有効なコンフィギュレーションを確保する。
よくあるSPFの問題
SPF(Sender Policy Framework)は、メール詐欺を防ぐための強力なメール認証方法です。しかし、ドメイン所有者は設定プロセスでしばしばミスを犯し、その効果を損なうことがあります。ここでは、避けるべき一般的なミスをいくつかご紹介します:
SPFハードリミットを超える:
SPFは、1回のチェックで10回のDNSルックアップと2回のボイドルックアップが上限です。また、SPFレコードは文字列あたり255文字以下、全体で512バイト以下でなければなりません。これらの閾値を超えると、SPFの検証に失敗し、メール配信に問題が生じる可能性があります。
SPFレコードが無効または壊れている:
SPFレコードが無効であったり、壊れていたりするために、許可されていない送信元があなたのドメインからメールを送信するフリーパスを取得します。これは、構文やフォーマットのエラー、あるいはDNSの設定ミスによるものです。
解決策
SPFレコードをチェックし、エラーの詳細を分析して、構文や設定の問題を解決する。
の問題を解決する。
補完的プロトコルの欠如:
SPFだけでは、メールベースのサイバー攻撃を防ぐことはできません。送信者は、DKIM(DomainKeys Identified Mail)、DMARC(Domain-based Message Authentication Reporting and Conformance)のような補完的な電子メール認証プロトコルの設定を忘れることがよくあります。
やDMARC(Domain-based Message Authentication Reporting and Conformance)のような補足的な電子メール認証プロトコルを設定することを忘れがちです。
のような補完的なメール認証プロトコルを設定することを忘れがちです。
SPFベストプラクティス
自動化ツールを使う:
人為的なミスが発生しやすいDIYの方法に頼るのではなく、SPFレコード生成ツールを使って自動的にレコードを作成しましょう。
すべての送信者を承認する:
SPFレコードに認証送信者として追加する送信元をすべてリストアップしてください。
ホスト型SPFサービスを利用する:
これにより、SPFレコードの管理が容易になります。これにより、ネットブロックの監視と削除、含まれるドメインの追跡、SPF制限の遵守が可能になります。
SPFの上限を超えないこと:
SPFレコードが10件のDNSルックアップ制限を超えないようにしてください。これはSPFフラット化サービスまたはSPFマクロを使用して実現できますが、後者をお勧めします。
SPF PTR
メカニズムの使用を避けること:
PTRレコードはIPアドレスをドメイン名に解決するので、DNSの検索処理を遅くする。また、RFC 7208の5.5節にあるように、非常に信頼性が低いと考えられている。
ドメインごとに1つのSPFレコードを公開する:
複数のSPFレコードを公開すると、SPF設定が無効になることがあります。
SPFチェッカーを使う理由
- 承認された送信者を確認し、正当な送信元のみがお客様の代わりにメールを送信できるようにします。
- SPFの失敗を防ぐために、DNSのルックアップとボイドの制限を守りましょう。
- リアルタイム診断でSPF構文エラーを特定し修正する。
- GoogleとYahooのメール送信者要件を満たし、SPF設定を修正してメール配信率を向上させましょう。
- SPFを適切に設定することで、メールがスパムとして判定されるのを防ぎ、受信トレイの配置を改善します。
- サーバ、メールクライアント、サードパーティ・サービスのIP認証を効率的に管理します。
継続的なSPF管理が必要ですか?PowerSPFは自動的にレコードを最適化し、検索エラーを防ぎます。
人々はこうも尋ねる
なぜSPFが必要なのか?
SPFはメールセキュリティを強化し、メールのなりすましを防止するために必要です。これにより受信メールサーバーは、送信元が許可されたソースからのメールかどうかを確認できます。
SPFレコードのチェックは無料ですか?
PowerDMARC では、SPF レコードのチェックは、何回 SPF コンプライアンスをチェックする必要があっても、また何種類のドメインについてチェックする必要があっても、完全に無料です。ただし、検索は一度に1ドメインずつ行われます。
SPFチェッカーツールはどのくらいの頻度で使用すべきですか?
特にメールインフラやドメイン設定に変更があった場合は、定期的にドメインのSPFレコードを監視・管理することをお勧めします。 DNSレコード、メールサーバー、送信者ポリシーを更新するたびにSPFレコードをチェックするのがよい方法です。また、数ヶ月ごとや大幅な変更後など、定期的にチェックすることで、SPF設定の有効性を継続的に維持することができます。
SPF管理を改善するには?
PowerDMARCが提供するのは、それだけではありません。 SPFフラット化サービスを提供するだけではありません。私たちのプラットフォームは、SPF の自動および動的な平坦化方法を完全にサポートしていますが、それに代わる(より良い)ソリューションも提供しています。いくつかのケースでは、従来のSPFフラット化手法や自動フラット化手法では、レコードを効果的に最適化することができません。そこで、弊社ではマクロの使用を推奨しています。私たちのプラットフォームはSPFマクロをサポートしており、ルックアップと文字数の両方においてSPFの制限内に収まるようにレコードを最適化します!また、マクロはフラット化と比較して、より複雑な状況にも有効です。これにより、エラーのない最適なSPFを実現します。
なぜSPFレコードの最適化が必要なのですか?
SPFレコードの最適化が便利な理由はいくつかあります。以下にそのいくつかを紹介する:
- 古いSPFレコード:SPFレコードが古い可能性があります。このような場合、他のメールサービスプロバイダーを利用したり、現在のベンダーから新しいベンダーに乗り換えたりすることで、メール配信の幅が広がっている可能性があります。DNSはこのことを知りません!したがって、DNSにアクセスしてSPFレコードを編集し、新しい送信元を含める必要があります。
- 極端に長いSPFレコード:SPFレコードが長すぎて、文字列の文字数制限を超えている場合は、最適化が重要になる。SPFが正しく機能するように、文字数制限を超えないようにレコードを短くする必要がある。
- 10回以上のルックアップを必要とするSPFレコード: 送信元を照会・検証するために、SPFレコードが10回を超えるDNSクエリを必要とする場合があります。これは許可されておらず、SPFのパーマネントエラーを引き起こす可能性があります。そのため、レコードを最適化して複雑さを軽減し、許可された照会回数制限内に収める必要があるかもしれません。
SPFルックアップの制限とは何ですか?
インターネット技術タスクフォースは、SPF検証セッション中に許可される ルックアップ数の制限を定義している。最大数は10である。SPFレコードが 10 DNS ルックアップを超えると、SPFは壊れてエラー結果を返す。さらにIETFは、void lookups (空の応答を返すDNS lookups)の回数も最大2回に制限している。
SPFルックアップの制限を超えるとどうなりますか?
レコードがSPFルックアップの制限を超えると、レコードは壊れて無効になります。また、検証結果はpermerror(永久エラー)となります。これは受信サーバーからはSPF失敗として扱われることが多く、メール配信の問題につながる可能性があります。
SPFパーマラーとは何ですか?
SPF permerrorは、SPFレコード内のエラー、SPFレコードの欠落、またはSPFに定義された制限の超過が原因でSPFレコードが破損した場合に発生する、SPFレコード内の恒久的なエラーを示します。
