SPFの一意性・構文・DNS参照数とは？レコード重複・+all・10回制限の確認方法と診断基準

SPFの一意性・構文・DNS参照数とは

SPFの一意性・構文・DNS参照数とは、ドメインのSPFレコードが受信側で正しく評価されるための3つの条件です。

1. 一意性：v=spf1 で始まるTXTレコードは1件だけにする。
2. 構文：+all や修飾子なしの all（全許可）を使わず、終端を -all・~all などで明示し、非推奨の ptr を使わない。
3. DNS参照数：include・a・mx・ptr・exists・redirect によるDNS照会を合計10回以内に収める。

city.example.lg.jp.  3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:spf.protection.outlook.com -all"

SPF（Sender Policy Framework）は、あるドメイン名を名乗ってメールを送ってよいサーバーを、DNSのTXTレコードで宣言する仕組みです。受信側はエンベロープFrom（MAIL FROM）のドメインのSPFレコードを参照し、送信元IPアドレスが許可されているかを判定します。DMARCはSPFまたはDKIMの認証結果をヘッダーFromのドメインと照合するため、SPFが壊れているとDMARCも期待どおりに機能しません。

SPFは「レコードがあれば有効」ではありません。レコードが2つある、all の扱いを誤っている、DNS参照が10回を超えている、といった状態では、受信側は permerror（恒久的エラー）や「すべて許可」と評価し、なりすまし防止効果が失われたり、正規メールまで迷惑メール扱いされたりします。セキュリティAIチェッカーのこの項目は、自治体のメールドメインに公開されたSPFレコードについて、一意性・危険な all・DNS参照数・非推奨機構を確認します。

SPFレコードの有無は「SPFレコード」、終端の -all／~all の強さは「SPFの終端ポリシー」、DMARCは「DMARCレコード」の各項目で評価します。このページは、SPFが「壊れていないか」に集中して解説します。

SPFがpermerrorや全許可になる仕組み（RFC 7208）

レコードの選択と一意性（RFC 7208 §4.5・§3.2）

受信側は対象ドメインのTXTレコードのうち v=spf1 で始まり、その後が空白か終端であるものだけを選びます。

§3.2は「選択されるレコードが複数になるような公開をしてはならない（MUST NOT）」と定めています。よくある原因は、メール配信サービスを追加導入したときに、既存レコードへ追記せず新しいTXTレコードを作ってしまうことです。

修飾子と all の意味（§4.6.2・§5.1）

各機構の前には修飾子を付けられ、省略時は + です。

したがって v=spf1 include:_spf.example.jp all の all は +all と同じ意味になり、世界中のどのサーバーからの送信も「許可」と評価されます。+all は構文上は有効ですが、SPFを置いていないより悪い状態です。

末尾の all が無い場合、どの機構にも一致しない送信元は neutral になります。ただし redirect= 修飾子がある場合は、リダイレクト先のレコードの結果が使われるため、all が無くても問題ありません（§6.1。all がある場合 redirect は無視されます）。

DNS参照数の上限は10回（§4.6.4）

include、a、mx、ptr、exists の各機構と redirect 修飾子はDNS照会を発生させます。RFC 7208は、これらの合計を10回に制限しなければならない（MUST）とし、超えた場合は permerror を返すとしています。数え方は include 先のレコードに含まれる参照も含めた再帰的な合計です。このほか、空応答・NXDOMAINとなる「void lookup」は2回まで（SHOULD）、mx 機構1つあたりのアドレス照会は10件までと定められています。

Microsoft 365、Google Workspace、各種配信サービスの include をいくつも並べると、再帰分を含めて10回を超えやすくなります。

ptr 機構は使わない（§5.5）

ptr は逆引きを使う機構で、RFC 7208は「この機構は公開すべきでない（SHOULD NOT）」と明記しています。RFCは、処理が遅く、DNSエラー時の信頼性が低く、.arpa のネームサーバーに大きな負荷をかけるとし、長年の運用経験から「不要であり、より信頼性の高い代替手段を使うべき」と結論づけています（受信側の実装は互換性のためサポート必須です）。

レコード長（§3.4）

SPFレコードは、問い合わせ結果がUDPの512オクテットに収まる程度に小さく保つべき（SHOULD）とされています。目安として、DNS名の長さと、その種別の全レコード（TXTなら同じ名前の他のTXTレコードも含む）のテキストの長さの合計が450オクテット未満であれば収まるとされています。

メールを送らないドメイン

メール送信に使わないドメインは v=spf1 -all を公開することで、「このドメインからの正規メールは存在しない」と宣言できます。

SPFの一意性・構文・DNS参照数の診断基準（セキュリティAIチェッカー）

取得対象

• 対象ドメイン：最終URLのホスト名から先頭の www. を除いたもの（例 www.city.example.lg.jp → city.example.lg.jp）。
• DNS-over-HTTPS（https://dns.google/resolve）で、対象ドメインのTXTレコードとMXレコードを照会します（タイムアウト5秒）。
• TXTは種別16の回答だけを使い、複数文字列に分割されたレコードは連結して評価します。
• MXは種別15の回答のうち、Null MX（0 .）以外が1件以上あれば「メール利用あり」とみなします。

DNS参照数の算出方法

v=spf1 レコードを空白で区切り、修飾子（+ - ~ ?）を除いた項目が include:、a（a:・a/を含む）、mx（同）、ptr、exists:、または redirect= で始まるものを数えます。include 先は展開しないため、算出値は「トップレベルの参照数」です。トップレベルだけで10を超えれば再帰分を数えるまでもなく permerror が確定します。

判定条件

• 根拠欄には、SPFレコード件数とトップレベルのDNS参照数を表示します。
• 重大度はhigh、重みは3です。

自治体サイトでの判定例

判定の限界

include 先を再帰展開しないため、トップレベルが10以下でも実際は10を超えている場合があります。void lookupの回数、include 先の構文誤り、レコード長、実際の送信サーバーが網羅されているかは評価していません。専用の検証ツールでの確認を併用してください。

SPFが壊れているとどんなリスクがあるか

• なりすましメール：SPFが permerror や全許可になると、自治体ドメインを詐称したフィッシングメール（給付金・税金還付・マイナンバー関連を装うもの）が受信側の認証をすり抜けやすくなります。DMARCの効果も失われます。
• 正規メールの不達：レコード重複や参照数超過で permerror になると、DMARCを強制している受信側では、自治体からの通知メール・メールマガジン・電子申請の受付通知が迷惑メール扱いや拒否になることがあります。
• 大手メール事業者の要件不適合：Googleの送信者ガイドラインは、すべての送信者にSPFまたはDKIMの設定とTLS接続を求め、1日5,000通以上の大量送信者にはSPF・DKIM・DMARCすべてを求めています。SPFが壊れていると、DKIM未設定の環境では配信に影響します。

SPFを1レコードに統合し参照数を減らす方法（DNS設定例）

修正の手順

1. 自治体ドメインからメールを送るシステムを棚卸しします（メールサーバー、Microsoft 365等、メール配信サービス、電子申請、防災メール、委託先の送信サーバー）。
2. すべてを1つの v=spf1 レコードに統合します。
3. 末尾は、送信元を網羅できていれば -all、確認期間中は ~all にします。+all・修飾子なし all は使いません。
4. 参照数が10を超える場合は、不要な include を削除する、固定IPを ip4:/ip6: で直接書く、送信システムをサブドメインに分ける、のいずれかで減らします。
5. ptr は削除し、ip4:/ip6: や a: へ置き換えます。

DNSゾーンファイルの例

; 統合したSPF（1レコードのみ）
city.example.lg.jp.  3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:spf.protection.outlook.com include:mail.example-delivery.jp -all"

; 長い場合は255文字ごとに分割（1つのTXTレコード内の複数文字列）
city.example.lg.jp.  3600 IN TXT ( "v=spf1 ip4:203.0.113.0/24 include:spf.protection.outlook.com "
                                   "include:mail.example-delivery.jp -all" )

; メールを送らないサブドメイン
www.city.example.lg.jp. 3600 IN TXT "v=spf1 -all"

分割する場合、文字列の連結時に空白は補われないため、区切りの空白を文字列内に含めます。

クラウドDNS・委託管理の場合

DNSを委託事業者や庁内ネットワーク運用者が管理している場合は、「SPFは1件に統合」「末尾は -all または ~all」「参照は10回以内」を作業指示に明記します。メール配信サービスを追加導入する際の手順書に「既存SPFへの追記」を加えておくと、重複の再発を防げます。

SPFの確認方法

# SPFレコードの件数と内容
dig +short TXT city.example.lg.jp | grep -i 'v=spf1'

# include先を1段ずつ確認
dig +short TXT spf.protection.outlook.com

Resolve-DnsName -Type TXT city.example.lg.jp | Where-Object { $_.Strings -match 'v=spf1' }

送信テストでは、Gmail等で受信したメールの「メッセージのソースを表示」を開き、Authentication-Results ヘッダーの spf=pass を確認します。修正後はセキュリティAIチェッカーで再診断し、根拠欄のSPF件数が1件、参照数が10以下になっていることを確認します。

配信を止めないための注意点（ガードレール）

• いきなり -all にすると、棚卸し漏れの送信システム（複合機のスキャン送信、委託先のサーバー等）のメールが拒否されます。DMARCの集計レポート（rua）で送信元を把握してから厳格化します。レポートの受け取りは「DMARC集計レポート送信先」で確認します。
• DNSのTTLを事前に短くしておくと、誤りがあったときの切り戻しが速くなります。
• SPFだけでは転送メールで失敗しやすいため、DKIM署名とDMARCを併用します。

よくある質問（FAQ）

参考資料

• RFC 7208「Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1」
• RFC 9989「Domain-Based Message Authentication, Reporting, and Conformance (DMARC)」
• Google ヘルプ「Email sender guidelines（メール送信者のガイドライン）」
• Google Public DNS「JSON API for DNS over HTTPS (DoH)」

「SPFの一意性・構文・DNS参照数」と関連する診断項目

• SPFレコードmedium
• SPFの終端ポリシーmedium
• DMARCレコードhigh
• DMARC集計レポート送信先low
• MTA-STSmedium
• DMARC強制ポリシーmedium
• CAAレコードlow
• DNSSECmedium