SPF レコードチェッカー

SPFレコードによるメール認証の仕組みと役割

SPF（Sender Policy Framework）は、送信ドメイン認証技術の一つであり、特定のドメインから電子メールを送信することを許可されたメールサーバーのIPアドレスをDNSのTXTレコードとして公開する仕組みです。受信側のメールサーバーは、受信したメールの送信元IPアドレスと、DNSから取得したSPFレコードを照合することで、送信元が詐称されていないか（なりすましメールではないか）を検証します。

適切なSPFレコードを構築・維持することは、ドメインの信頼性を保ち、メールの到達性を向上させるために不可欠です。しかし、SPFレコードの記述には厳格な構文規則や制限が存在するため、管理者が意図した通りのポリシーが正しく反映されているかを事前に検証することが重要になります。

---

SPFレコードの構文と主要な構成要素

SPFレコードは、必ず v=spf1 というバージョン宣言から開始する必要があります。この宣言に続いて、送信を許可するサーバーを指定する「メカニズム」や、追加の処理を定義する「修飾子」が記述されます。

主要なメカニズムと修飾子

• v=spf1: SPFレコードのバージョンを示します。レコードの最初の項目でなければならず、1つのレコード内に複数存在してはなりません。
• ip4 / ip6: 送信を許可するIPv4アドレスまたはIPv6アドレス（およびCIDR範囲）を直接指定します。
• include: 指定した外部ドメインのSPFレコードを再帰的に取り込んで評価します。
• a / mx: ドメインのAレコードやMXレコードに紐づくIPアドレスからの送信を許可します。
• all: レコードの最後に配置され、これまでに指定した条件に一致しなかったすべての送信元に対する処理（限定子）を定義します。
• redirect: 評価を別のドメインのSPFレコードに完全に委ねる修飾子です。

限定子（Qualifiers）

各メカニズムの前に付与され、一致した場合の評価結果を決定します。

• + (Pass): 送信を許可します（デフォルト）。
• - (Fail): 送信を拒否します（ハードフェイル）。
• ~ (SoftFail): 疑わしいメールとして扱います（ソフトフェイル）。
• ? (Neutral): 判定を保留します（ニュートラル）。

---

SPFにおける「10回制限」とDNSルックアップ

SPF仕様において最も注意すべき制約が、評価時に発生するDNSルックアップの回数制限です。メール受信サーバーがSPFレコードを評価する際、DNSへの問い合わせ（ルックアップ）を発生させる項目の合計数は最大10回までに制限されています。

DNSルックアップを発生させる項目

レコード内に記述された include、a、mx、ptr、exists、および redirect は、それぞれDNSルックアップをトリガーします。一方で、ip4 や ip6、all はDNS問い合わせを発生させないため、この制限カウントには含まれません。

制限超過の影響（恒久エラー）

評価プロセスにおいてDNSルックアップの合計回数が10回を超えた場合、受信側メールサーバーはこれを「恒久エラー（PermError）」として処理しなければなりません。恒久エラーが発生すると、SPF認証は失敗扱いとなり、メールの不達や迷惑メールフォルダへの振り分けといった配信トラブルに直結します。

特に注意が必要なのは、include や redirect の参照先ドメインが、その内部でさらに別の include を使用しているケースです。最初のレコードに記述されている項目数が10未満であっても、ネストされた参照先をすべて展開した結果、累積で10回を超えてしまうと制限違反となります。

---

構文エラーとポリシー上のリスク

SPFレコードの記述ミスや不適切なポリシー設定は、認証の失敗やセキュリティ強度の低下を招きます。以下は、代表的な構文エラーおよびポリシー上のリスクです。

構文エラー

• バージョン宣言の不備: レコードが v=spf1 で始まっていない場合や、v=spf1 が最初の項目ではない場合、または複数記述されている場合は正しく解析されません。
• 無効なIPアドレス形式: ip4 や ip6 に指定された値が、有効なIPアドレスまたはCIDR範囲の形式を満たしていない場合。
• 修飾子への限定子付与: redirect などの修飾子に対して +、-、~、? といった限定子を付与することは禁止されています。
• 重複する修飾子: 同一の修飾子が複数回指定されている場合。

ポリシー上のリスク

• +all の使用: すべての送信元からのメールを許可することになるため、SPFによるなりすまし防止効果が事実上失われます。
• ?all の使用: 受信側に対して明確なポリシー指針を与えないため、推奨されません。
• all や redirect の欠如: レコード内に all も redirect も存在しない場合、どの条件にも一致しない送信元からのメールはすべて neutral（中立）として判定されます。
• all の後に記述された項目: all メカニズムより後ろに記述された項目は、SPF評価時に到達不能となり無視されます。また、all と redirect が両方存在する場合、redirect は無視されます。
• ptr メカニズムの使用: ptr はDNS逆引きを伴うため処理が低速であり、信頼性も低いため、現在は公開すべきではないとされています。

---

ローカル検証とDNSクエリの違い

SPFレコードの検証には、テキスト情報を直接解析する「ローカルチェック」と、実際にDNSサーバーへ問い合わせを行う「アクティブクエリ」の2つのアプローチがあります。

本ツール「SPF レコードチェッカー」は、入力されたテキスト（最大20,000文字、引用符で囲まれた分割テキストの結合に対応）を対象に、ローカル環境で構文解析と最初のレコードにおけるDNSルックアップ数の見積もりを行います。

ローカルチェックは、レコードをDNSに公開する前、あるいは修正案を作成する段階で、構文ミスや明らかなルックアップ数超過を素早く検知する用途に適しています。

---

よくある質問（FAQ）

SPF の DNS ルックアップ見積もりはどのように計算されますか？

貼り付けたレコード内の include、a、mx、ptr、exists、redirect を数えます。include や redirect の参照先でさらにルックアップが増えるため、ローカルチェックでは最終的な再帰合計は分かりません。

SPF が 10 回を超える DNS ルックアップを必要とするとどうなりますか？

SPF の受信側は、DNS ルックアップの 10 項目制限を超えた評価を恒久エラーとして扱う必要があります。この制限は最初のレコードだけでなく、include と redirect のチェーン全体に適用されます。

問題なしという結果なら、SPF 設定が機能していると証明できますか？

いいえ。このページは貼り付けたテキストだけを確認します。DNS の照会、プロバイダーのレコード展開、送信元 IP のテスト、受信メールサーバーの応答確認は行いません。