SPF検索カウンター
メール送信元を追加すると、DNS 照会回数が即座に更新されます。RFC 7208 で定められた上限である 10 回を超えていないか確認し、フラット化されたレコードやホスト型マクロレコードをプレビューしてから、実際のドメインでライブチェックを実行してください。SPF検索カウンター
左側の送信者を選択して、レコードを作成してください
1件の検索結果
2件の検索結果
3回以上の検索
検索条件に一致する送信者はいません。以下からカスタムインクルードとして追加してください。
カスタムインクルードを追加する
SPFレコードの送信元
ライブラリから送信者を選択して、SPFレコードの作成を開始してください
DNS検索の利用状況
0 / 10
● 安全（7以下）
⚠ 警告 (8–10)
✗ 基準値超過 (>10)
あくまでシミュレーションです。これは、選択内容に基づいて生成されるレコード構造を、例として示したものです。
v=spf1 ~all
これはあくまで例示であり、そのまま公開できるフラット化レコードではありません。表示されているIP範囲は静的なスナップショットです。実際のフラット化レコードには、各送信者の現在のIPアドレスに対するリアルタイムのDNS解決が必要ですが、ESPはこれらのIPアドレスを頻繁に変更します。本番環境で利用可能なレコードを生成し、継続的に維持するには、PowerSPFをご利用ください。
v=spf1 ~all
お客様のドメイン：
このサンプルは、そのまま公開しても動作しません。 について
_spf.powerspf.com ホストの解決は、PowerDMARC Hosted SPFに登録されているドメインに対してのみ行われます。 お使いのドメインでPowerSPFを有効にする →
v=spf1 include:yourdomain.com._spf.powerspf.com ~all
仕組み
PowerSPFは、単一のインクルードの背後で、すべての送信元のIP範囲をホストし、継続的に解決するため、ESPがインフラを更新しても、お客様のDNS TXTレコードが変更されることはありません。その結果、DNSルックアップは1回のみで済み、PermErrorのリスクはゼロ、更新は自動的に行われます。
以前 —0件の検索
後 — 1回の検索 ✓
実際のSPFレコードを確認してください
ドメインを入力して、SPFのリアルタイムチェックを実行してください。実際のレコード、照会回数、およびエラーがある場合はその内容を確認できます。
SPFルックアップの回数を数える理由
10件というルックアップ制限が、SPFのPermErrorが発生する最大の原因です。メールプロバイダーは独自のインクルードをネストして処理するため、送信者がわずか数件しか含まれていないレコードであっても、知らぬ間にこの制限を超えてしまうことがあります。そして、メールの配信に失敗し始めるまで、そのことに気づくことはないでしょう。
PermErrorを早期に検知する
検索回数が10回を超えると、受信側はPermErrorを返し、SPFが失敗したとみなします。これは、正当なメールであっても同様です。このカウンターは、エラーが発生するまでの残り回数を示しています。
ルックアップの由来を確認する
当社は、すべてのインクルードおよびプロバイダー独自のレコードへのリダイレクトを追跡しているため、どのメカニズムがどの階層で予算を消費しているかを正確に把握することができます。
その直し方を知っておく
無効な（void）ルックアップ、弱い「all」修飾子、または非推奨のメカニズムを特定し、インクルードを固定IPに集約したフラット化されたレコードをプレビューできます。
SPF検索カウンターの使用方法
SPFの照会回数を数えるのはほんの数秒で済みます。以下の3つの手順に従ってください。
1
送信者を選んでください。 左側のライブラリから、メールの送信に使用するESPやサービスを選択してください。あるいは、次のようなカスタムインクルードを追加することもできます。
spf.yourvendor.com.2
右側のメーターに注目してください。選択するたびに記録が蓄積され、DNSルックアップのメーターが即座に更新され、上限の10にどれだけ近づいているか、また各ルックアップがどこから行われているかが表示されます。
3
ライブチェックを実行してください。「実際のSPFレコードを確認」の欄にドメイン名を入力してSPFチェッカーを開き、実際に公開されているレコードの有効性を確認してください。
SPFルックアップ制限の仕組み
RFC 7208 では、SPF の評価における DNS 照会回数が 10 回に制限されています。ここでは、この制限が設けられた理由、制限を超えた場合に何が起こるか、そしてそれを解決する 2 つの方法について説明します。
なぜその制限があるのか
RFC 7208では、メールサーバーがDoSアンプとして悪用されるのを防ぐため、SPFのDNSルックアップ回数を10回に制限しています。この制限を超えるとPermErrorが返され、メールが正当なものであっても認証は失敗します。
検索回数の上限は10回 →
「PermError」の意味
PermError は、恒久的な SPF 失敗です。多くの受信側はこれを完全な SPF 失敗（スパムフォルダへの振り分けや拒否）として扱い、SPF に関する DMARC アラインメントを黙って破綻させてしまいます。
PermErrorについて理解する →
「フラット化」によってどのように解決されるか
フラット化を行うと、インクルードが基になるものに解決されます
「フラット化」の解説 →
ip4/ip6 範囲を指定し、ルックアップを削除します。ただし、ESPがIPアドレスをローテーションするたびに、手動でIPアドレスを更新する必要があります。マクロを使用したホスト型SPF
ホスト型マクロレコードは、変更されることのない単一のインクルードから、フラット化されたIPアドレスを提供します。PowerSPFは、プロバイダーがIPアドレスをローテーションさせた場合でも、これを自動的に最新の状態に保ちます。
マクロについて詳しくはこちら →
メカニズム別のDNS検索コスト
SPFレコードのすべての部分がルックアップとしてカウントされるわけではありません。RFC 7208において、10件という制限にカウントされる仕組みや修飾子、およびカウントされないものについては以下の通りです。
| メカニズム／修飾子 | DNSルックアップ | なぜ |
|---|---|---|
| を含む： | 各1個 | 別のドメインのSPFレコードを再帰的に評価します。この関数自体に含まれるネストされたインクルードにより、さらに処理が追加されます。 |
| a/a: | 各1個 | ドメインのAレコードおよびAAAAレコードを解決し、それらのIPアドレスを承認します。 |
| mx/mx: | 各1個 | MXレコードを解決します。MXホストをIPアドレスに解決する際、別途10件という上限が設けられています。 |
| 伝令者 | 各1個 | リバースDNSチェック。RFC 7208により非推奨となっている。処理が遅く、信頼性が低いため、使用は避けること。 |
| 存在します： | 各1個 | メッセージごとに評価されるマクロ検索。条件付き送信ルールで一般的に使用される。 |
| リダイレクト= | 各1個 | ポリシー全体を別のドメインのSPFレコードに委譲し、そのSPFレコードに基づいて評価が行われます。 |
| ip4:/ip6: | 0 | リテラルなIPアドレス、またはCIDR範囲。これを評価するためにDNSクエリは必要ありません。 |
| 何れも | 0 | 終了時の包括的ポリシー（-all, ~all). DNSクエリは行われません。 |
要点：1つの include: プロバイダーのレコードが、それ自体でさらに複数のインクルードを引き込む可能性があるため、1回の検索よりもはるかに多くのコストがかかる場合があります。そのため、合計数を正確に把握するには、ツリー全体を解決するのが確実な方法であり、まさにこのツールが上記で行っていることです。
よくあるご質問
SPF 10の検索制限とは何ですか？
RFC 7208 では、SPF レコードの評価時に DNS ルックアップを 10 回までに制限しています。それぞれ 1 回のルックアップを消費するメカニズムは以下の通りです。
include, a, mx, ptr、そして exists、さらに redirect 修飾子 - すべてのインクルードを再帰的にカウントします。合計が10を超えた場合、レシーバーはPermErrorを返し、SPFは失敗します。これは通常のSPFチェッカーとどう違うのですか？
このツールは視覚的なシミュレーターです。使用する送信者を選択すると、SPFレコードによるDNSルックアップの負荷を推定し、設定を進めていくにつれてメーターの数値がリアルタイムで更新されます。一方、通常のチェッカーは、実際に公開されているレコードの有効性を検証します。ご自身のドメインに関する正確な数値を確認したい場合は、「SPFをチェック」ボックスを選択して、リアルタイムのSPFチェッカーを実行してください。
DNSルックアップが10回を超えるとどうなりますか？
受信サーバーはPermError（永続的なエラー）を返します。多くの場合、PermErrorはSPFの失敗とみなされるため、正当なメールがスパムフォルダに振り分けられたり、拒否されたりすることがあります。また、これによりSPFに関するDMARCのアラインメントが破綻し、DKIMが個別に合格していない場合、DMARCの失敗へと連鎖する可能性があります。
なぜ、1回のインクルードが1回のルックアップよりもコストがかかるのでしょうか？
プロバイダは独自のインクルードをネストさせるためです。次のように追加すると
include:example.com、そのレコード自体にさらに2つか3つのインクルードが含まれている可能性があります。それぞれが、10回の検索回数にカウントされる追加の検索となります。そのため、送信者がわずか数人しかいないレコードでも、知らず知らずのうちに制限を超えてしまうことがあるのです。「ヴォイド・ルックアップ」とは何ですか？
「ボイドルックアップ」とは、何も返さない（空の回答、あるいはSPFレコードが存在しないドメイン）仕組みのことです。RFC 7208では、これを2つ以下に抑えることが推奨されています。これを超えると、一部の受信サーバーはPermErrorを返すことがあります。また、これらは予算の一部を無駄にするため、無効なインクルードを削除することは有益です。
このツールが表示するフラット化されたレコードを公開してもいいですか？
これは完成したレコードではなく、あくまで参考例として扱ってください。フラット化された出力は、現時点で送信者が解決されるIPアドレスの「ある時点」のスナップショットに過ぎません。ESPはIP範囲を定期的に変更するため、手動でフラット化したレコードは古くなり、正当なメールに対してSPF検証に失敗する可能性があります。PowerSPFでは、自動的に更新されるフラット化されたホスト型レコードを維持しています。
私のドメインは御社のサーバーに転送されていますか？
いいえ。このシミュレーターは完全にブラウザ上で動作します。選択した送信元は一切外部に送信されません。「SPFを確認」チェックボックスを選択した場合にのみ、入力された1つのドメインを当社のSPFチェッカーに送信し、実際の照会を実行します。
10件の検索制限にこだわらないでください
このカウンターが問題点を示しています。PowerSPFはこの問題を恒久的に解決します。SPFレコードをフラット化してホスティングすることで、制限値内に収まるようにし、プロバイダーがIPアドレスを変更した際には自動的に更新されます。
