SPFレコードとは？仕組み・書き方・診断基準・設定方法

SPFレコードとは

SPFレコードとは、「このドメイン名を名乗ってメールを送ってよいサーバーはこれです」という一覧を、DNS の TXT レコードで公開する仕組み（Sender Policy Framework）です。受信側のメールサーバーは、送ってきたサーバーのIPアドレスがその一覧に含まれるかを確認し、なりすましメールを見分ける材料にします。

city.example.lg.jp.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.example-mail.jp -all"

自治体のドメインは、税・給付金・選挙・防災などをかたるフィッシングメールの「名乗り先」として悪用されやすく、SPF は DKIM・DMARC と並ぶ基本的ななりすまし対策です。この診断項目は、サイトのドメインがメールを受け取る設定（MXレコード）を持っている場合に、SPF レコードが公開されているかを確認します。

SPF の仕組み

SPF は、SMTP の MAIL FROM（エンベロープ送信者。バウンスの返送先）と HELO のドメインについて評価されます。受信サーバーは example.lg.jp の TXT レコードから v=spf1 で始まるものを探し、ip4:、ip6:、a、mx、include: などの機構を左から順に評価し、最後の all で既定の結果を決めます。

RFC 7208 の要点

• 4.5節：取得したレコードのうち、バージョン部が正確に v=spf1 で始まらないものは捨てる。バージョン部は空白（SP）かレコード末尾で終わる。残ったレコードが2件以上なら結果は permerror（恒久エラー）。
• 4.6.4節：DNS 参照を伴う語（include、a、mx、ptr、exists、redirect）は評価全体で10回までに制限しなければならず（MUST）、超えると permerror。結果が空になる参照（void lookup）は2回までを推奨。
• 10.1.2節：メールを送らないドメインにも SPF を公開することが確立したベストプラクティスであり、そのレコードは v=spf1 -all である。

SPFレコードの書き方（主な構文要素）

修飾子は +（pass、省略時の既定）、-（fail）、~（softfail）、?（neutral）の4種類です（4.6.2節）。末尾の all に付ける修飾子の意味と選び方は「SPFの終端ポリシー」で詳しく解説しています。

実際の自治体ドメインでも、庁内メールの中継サーバーを ip4: で、クラウドサービスや配信事業者を include: で列挙し、末尾を -all または ~all とする構成が一般的です。

SPFレコードはなぜ必要か（DMARCとの関係・受信側の要件）

SPF の限界と DMARC

SPF が確認するのはエンベロープ送信者であり、利用者がメールソフトで見る「差出人（From ヘッダー）」ではありません。攻撃者は自分のドメインで SPF を通しつつ From だけ自治体名にすることができます。

この隙間を埋めるのが DMARC で、From のドメインと SPF/DKIM で認証されたドメインの一致（アラインメント）を求めます。したがって SPF は単独ではなく、DKIM・DMARC とセットで意味を持ちます。DMARC の公開状況は「DMARCレコード」の項目で確認します。現行の DMARC 仕様は RFC 9989（2026年5月、RFC 7489 を廃止）です。

受信側の要件の動向

Google の「メール送信者のガイドライン」は、2024年2月1日以降、すべての送信者に SPF または DKIM の設定を、1日5,000件以上を送る送信者には SPF・DKIM・DMARC すべての設定を求めています。SPF が未設定の自治体ドメインからのメールは、住民の Gmail 等で迷惑メール扱いや受信拒否になる可能性が高まります。

国内では、迷惑メール対策推進協議会が2024年7月に「送信ドメイン認証技術 DMARC導入ガイドライン」を公表しています（関連標準の一つ）。

SPFレコードについてよくある誤解

• 「SPF を入れればなりすましは防げる」：上記のとおり From ヘッダーの偽装は SPF 単独では防げません。DMARC が必要です。
• 「SPF は複数の TXT に分けて書ける」：v=spf1 レコードが2件あると permerror になり、SPF が無効になります。1件に統合します（255文字を超える場合は1レコード内で文字列を分割します）。
• 「メールを送らないドメインには不要」：送らないドメインほど v=spf1 -all で「送信者なし」を宣言することが推奨されます。

SPFレコードの診断基準（セキュリティAIチェッカー）

取得対象と方法

• 診断対象の最終URLのホスト名から先頭の www. を除いたものを「メールドメイン」とします（例：www.city.example.lg.jp → city.example.lg.jp）。
• Google Public DNS の DNS over HTTPS（https://dns.google/resolve、JSON形式）で、メールドメインの TXT と MX を問い合わせます。通信エラー・非2xx応答時は短い待機を挟み、合計3回まで試行します。
• MX が1件以上あり、かつ Null MX（0 .、RFC 7505）ではない場合に「メール受信設定あり」とします。
• TXT のうち、先頭が v=spf1 で、その後に空白または末尾が続くもの（RFC 7208 4.5節）を SPF レコードとみなします。

判定条件

SPF の中身は別項目で評価します。終端の all は「SPFの終端ポリシー」、レコード数・構文・DNS 参照数は「SPFの一意性・構文・DNS参照数」を参照してください。この項目に「× 要改善（fail）」はありません。

自治体ドメインでの判定例

診断の限界

• サイトのホスト名とメールアドレスのドメインが異なる場合（例：サイトは www.city.example.jp、メールは city.example.lg.jp）、メール側のドメインは評価しません。
• MX がなくてもメールを送信しているドメインは対象外になります。そのようなドメインも SPF を設定してください。
• URL のホストが IP アドレスの場合、DNS・メール保護の各項目は判定されず、結果にも出力されません。
• DNS 応答の取得に失敗した場合は「レコードなし」と同じ扱いになることがあります。結果に疑問がある場合は手元で再確認してください。

SPFレコードがないとどんなリスクがあるか

• 自治体をかたるフィッシング：住民税の還付、給付金、マイナンバーカード、ふるさと納税などを装ったメールが自治体ドメインを名乗って送られ、偽サイトでの個人情報・カード情報入力に誘導されます。SPF・DMARC がないと受信側が偽物と判定する材料が乏しくなります。
• 正規メールの不達：主要メールサービスの送信者要件により、SPF がない自治体ドメインからの通知（申請受付、防災情報の登録確認など）が迷惑メールフォルダに入ったり拒否されたりします。
• バックスキャッタ：なりすましメールの宛先不明エラーが自治体に大量に返送され、メールサーバーや職員の負担になります。

国内では2023年2月1日に経済産業省・警察庁・総務省が、クレジットカード会社等に対し DMARC 導入をはじめとするフィッシング対策の強化を要請しており、SPF・DKIM を前提とする送信ドメイン認証は官民共通の基本対策と位置付けられています。

SPFレコードの設定方法と確認方法

1. 送信元を棚卸しする

そのドメインを差出人に使う送信元をすべて洗い出します。

• 庁内メールサーバー
• クラウドメール（Microsoft 365、Google Workspace 等）
• メール配信サービス（メールマガジン・防災メール）
• 電子申請や施設予約システムの通知
• 問い合わせフォームの自動返信
• 複合機のスキャン送信

2. SPF レコードを1件作る

city.example.lg.jp.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:spf.protection.outlook.com include:_spf.example-mail.jp ~all"

• まず ~all（ソフトフェイル）で始め、DMARC レポートで正規の送信元に漏れがないことを確認してから -all を検討します。
• include: は各サービスの公式案内に記載された値を使います。
• 長い場合は1レコード内で "v=spf1 ... " "include:... ~all" のように文字列を分割します（別レコードにしない）。

3. メールを送らないドメイン・サブドメイン

www.city.example.lg.jp.  IN  TXT  "v=spf1 -all"

4. DKIM・DMARC とセットで導入する

SPF だけでは From の偽装を防げないため、DKIM 署名を有効にし、_dmarc に DMARC レコードを p=none から公開します（「DMARCレコード」を参照）。

5. 変更作業の進め方

1. 変更前に現在の TXT レコードを記録し、ロールバック手順を用意します。
2. 切替前に TTL を短く（例：300秒）しておくと、誤りがあっても早く戻せます。
3. 変更後はテスト送信と DMARC 集計レポートで、正規の送信元が pass しているかを数日〜数週間確認します。
4. DNS をレジストラや委託事業者が管理している場合は、申請様式や作業依頼の流れを事前に確認しておきます。

6. 確認方法

dig +short TXT city.example.lg.jp | grep -i 'v=spf1'
nslookup -type=TXT city.example.lg.jp
curl -s 'https://dns.google/resolve?name=city.example.lg.jp&type=TXT'

実際に Gmail 宛てにテスト送信し、「メッセージのソースを表示」で SPF: PASS を確認します。設定後はセキュリティAIチェッカーで再診断し、根拠欄に「SPFレコードを確認しました」と表示されることを確かめてください。

メールを止めないための注意点

• SPF を2件にしない：既存の SPF に追記せず新しい TXT を足すと permerror になり、むしろ全メールの認証が失敗します。
• DNS 参照10回の上限：include: を重ねると上限を超えて permerror になります。不要な include を削り、可能なら ip4: へ置き換えます。
• いきなり -all にしない：漏れた送信元からのメールが受信拒否されます。
• 外部委託の配信システムを追加・変更するときは、SPF 更新を契約・運用手順に組み込みます。

よくある質問（FAQ）

参考資料

• RFC 7208 Sender Policy Framework (SPF)
• RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Google「メール送信者のガイドライン」
• 経済産業省「クレジットカード会社等に対するフィッシング対策の強化を要請しました」（2023年2月1日）
• ScanNetSecurity「迷惑メール対策推進協議会『送信ドメイン認証技術 DMARC導入ガイドライン』公表」

「SPFレコード」と関連する診断項目

• SPFの終端ポリシーmedium
• DMARCレコードhigh
• SPFの一意性・構文・DNS参照数high
• DMARC強制ポリシーmedium
• DMARC集計レポート送信先low
• CAAレコードlow
• DNSSECmedium
• MTA-STSmedium