セキュリティAIチェッカーを利用日本DX地域創生応援団
  • 診断項目 No.62／127
  • DNS・メールのなりすまし対策
  • 重大度 中（medium）

SPFの終端ポリシーとは？-all・~all・?all・+allの意味と選び方・診断基準

文責・開発：村井宗明（元文部科学大臣政務官・AIエンジニア）　最終更新日：

SPFの終端ポリシーは、SPFレコード末尾のallで「一覧外の送信元をどう扱うか」を示す部分です。-allと~allの違い、?allや+allが危険な理由、redirectとの関係、診断基準、段階的な設定方法を解説します。

セキュリティAIチェッカーを利用する 127項目ガイドのトップへ戻る

結論（SPFの終端ポリシー）

SPFの終端ポリシーとは、SPFレコードの最後に置く all 機構とその修飾子のことで、「一覧に載っていないサーバーから届いたメールをどう扱ってほしいか」を受信側に伝えます。-all（fail：認めない）か ~all（softfail：疑わしい）にすれば、一覧外から自治体ドメインを名乗るメールを受信側が不正の可能性が高いと判断できます。?all（判断しない）や +all（誰でも可）、all を書かない状態では、SPFを公開していてもなりすまし判別の材料になりません。

この記事のポイント

  • 修飾子は + pass、- fail、~ softfail、? neutral の4種類で、省略すると + になります（RFC 7208 4.6.2節）。
  • all も redirect= もなければ、結果は ?all と同じ neutral です（4.7節）。
  • -all と ~all はどちらも「終端ポリシーあり」で、セキュリティAIチェッカーの得点に差はありません。
  • RFC 9989 7.1節は、-all による早い段階での拒否が、DKIMでDMARCを通るはずのメールまで拒否しうると注意しています。
  • まず ~all で始め、DMARCレポートで送信元の漏れがないと確認してから -all を検討するのが安全です。
診断項目名SPFの終端ポリシー
項目IDdns.spf-policy
分類DNS・メールのなりすまし対策
重大度・配点の重み中（medium）　重み 2
関連する標準・ガイドラインRFC 7208 4.6.2節（修飾子）、4.7節（既定の結果）、5.1節（all 機構）、6.1節（redirect 修飾子）、10.1.2節（メールを送らないドメインの SPF）、RFC 9989 7.1節（DMARC と SPF の -all）、迷惑メール対策推進協議会「送信ドメイン認証技術 DMARC導入ガイドライン」

SPFの終端ポリシーとは

SPFの終端ポリシーとは、SPF レコードの最後に置く all 機構とその修飾子のことで、「一覧に載っていないサーバーから送られてきたメールをどう扱ってほしいか」を受信側に伝える部分です。

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

-all（fail：認めない）または ~all（softfail：疑わしい）と書けば、一覧外のサーバーから自治体ドメインを名乗るメールが届いたとき、受信側はそれを不正の可能性が高いと判断できます。?all（neutral：何とも言えない）や +all（誰でも可）、あるいは all を書かない状態では、SPF を公開していても、なりすましを判別する材料として機能しません。

この診断項目は、メール受信設定と SPF レコードがあるドメインについて、終端が -all または ~all になっているかを確認します。SPF レコードそのものの有無は「SPFレコード」で確認します。

修飾子と結果（-all・~all・?all・+all の違い）

RFC 7208 4.6.2節は、機構の前に付ける修飾子を次のように定めています。省略した場合は + です。

修飾子結果受信側での一般的な扱い
+pass許可された送信元
-fail許可されていない送信元。拒否や隔離の根拠になる
~softfailおそらく許可されていない。受け入れつつ疑わしいものとして扱う
?neutral判断しない（SPF がないのと実質同じ）

5.1節は all を「常に一致する」機構で、右端に置いて明示的な既定値を与えるものと説明しています。レコードの評価は左から順に行われ、どの機構にも一致しなかった場合、all の修飾子が結果になります。all も redirect= もなければ、?all が書かれている場合と同じく結果は neutral です（4.7節）。

SPFの終端ポリシーは -all と ~all のどちらがよいか

  • -all は意図が最も明確で、メールを送らないドメインでは v=spf1 -all が定番です（10.1.2節の考え方）。
  • 送信を行うドメインでは、DMARC を併用する場合、受信側は SPF 単独の fail よりも DMARC の判定（From ドメインとのアラインメント）を重視するのが一般的です。転送メールでは SPF が失敗しやすいため、DMARC 運用下では ~all を選ぶ組織も多くあります。
  • RFC 9989 7.1節は、受信側の構成によっては -all による SPF fail が SMTP の早い段階での拒否につながり、DKIM で DMARC を pass できたはずのメールまで拒否され、その拒否は DMARC 集計レポートにも現れないと注意しています。
  • 本診断では -all と ~all を同等に「終端ポリシーあり」と扱います。重要なのは、一覧外の送信元を「許可」や「判断なし」にしないことです。

redirect 修飾子との関係

redirect= は、レコード内のどの機構にも一致しなかったとき、評価を別ドメインの SPF に委ねる修飾子です（6.1節）。5.1節は「レコード内に all 機構がある場合、redirect 修飾子は（記述順にかかわらず）無視されなければならない」と定めています。redirect を使う構成では、終端ポリシーはリダイレクト先のレコードで決まります。

DMARC との関係

DMARC（RFC 9989）では、メールが「SPF または DKIM のいずれかで認証され、かつその認証済みドメインが From ヘッダーのドメインと一致（アライン）している」場合に pass となります。SPF の終端が -all か ~all かは、DMARC の判定そのもの（SPF が pass したかどうか）には影響しません。

一方で、DMARC を導入していない受信側や、DMARC 判定に加えて SPF 結果も迷惑メール判定に使う受信側では、softfail と fail の違いが処理に反映されることがあります。終端ポリシーは「SPF 単独での最低限の意思表示」、DMARC は「From 偽装への最終的な対処方針」と役割を分けて考えると整理しやすくなります。DMARC の方針の強さは「DMARC強制ポリシー」で確認します。

SPFの終端ポリシーについてよくある誤解

  • 「?all は安全側の書き方」：neutral は「判断しない」の意味で、なりすまし判定には役立ちません。
  • 「+all を付けておけば自分のメールが確実に届く」：世界中のどのサーバーにも送信を許可する宣言で、なりすましを公認することになります。
  • 「-all にすれば DMARC は不要」：SPF はエンベロープ送信者しか検証しないため、From ヘッダーの偽装には DMARC が必要です。

SPFの終端ポリシーの診断基準（セキュリティAIチェッカー）

取得対象と方法

  • 最終URLのホスト名から先頭の www. を除いた「メールドメイン」について、Google Public DNS（DNS over HTTPS、https://dns.google/resolve）で TXT と MX を問い合わせます。
  • MX が1件以上あり、Null MX（0 .）でない場合に「メール受信設定あり」とします。
  • TXT のうち先頭が v=spf1（その後が空白または末尾）のものを SPF レコードとします。
  • SPF レコード内に、空白で区切られた独立した語として -all または ~all があるかを調べます。include:spf-all.example.jp のようにドメイン名の一部に含まれる文字列は数えません。

判定条件

判定条件得点への影響
○ 問題なし（pass）SPF レコードに -all または ~all がある重み2 × 1.00
△ 要確認（warn）SPF はあるが終端が ?all・+all・all（+と同じ）、または all がない（redirect のみの場合を含む）重み2 × 0.45
対象外（na）MX がない、または SPF レコードがない採点から除外

SPF の有無は「SPFレコード」、レコードの重複・+all・DNS 参照数超過といった致命的な誤りは「SPFの一意性・構文・DNS参照数」（dns.spf-validity、重み3、+all やレコード重複は「× 要改善」）で評価しています。この項目に「× 要改善（fail）」はありません。

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

SPF レコード判定
v=spf1 ip4:203.0.113.10 include:_spf.example-mail.jp -all○ 問題なし
v=spf1 include:_spf.google.com ~all○ 問題なし
v=spf1 +ip4:198.51.100.0/28 ~all○ 問題なし（+ip4 は通常の許可）
v=spf1 ip4:203.0.113.10 ?all△ 要確認
v=spf1 ip4:203.0.113.10△ 要確認（all なし＝neutral）
v=spf1 redirect=_spf.example.lg.jp△ 要確認（リダイレクト先を手動確認）

-all と ~all の扱い

-all と ~all はいずれも本項目では「○ 問題なし」で、得点に差はありません。どちらを選ぶかは、DMARC の運用段階や転送メールの有無を踏まえて各団体が判断する事項です。-all が途中にあり後ろに別の機構が続くレコードも「○ 問題なし」になりますが、all より後ろの機構は評価されない（5.1節）ため、書き順の誤りがないかは目視で確認してください。

診断の限界

  • redirect= の先は追跡しません。リダイレクト先で -all / ~all を設定している場合は実質的に問題ありませんが、本項目では「△ 要確認」になります。根拠を確認し、リダイレクト先を手動で確認してください。
  • include: 先の内容は評価しません。
セキュリティAIチェッカーを利用する

SPFの終端ポリシーが不十分だとどんなリスクがあるか

  • なりすましの見逃し：終端が ?all や all なしでは、一覧外のサーバーから自治体ドメインを名乗るメールも neutral となり、受信側の迷惑メール判定で不利な材料になりません。
  • +all の場合：攻撃者のサーバーも SPF pass になり、DMARC を設定していても SPF アラインメント経由で pass し得るため、DMARC による保護まで無力化されるおそれがあります（エンベロープ送信者を自治体ドメインにした場合）。
  • 受信側要件への不適合：主要メールサービスの送信者ガイドラインは SPF/DKIM/DMARC による認証を求めています。終端ポリシーが曖昧な状態は認証設計の不備として扱われやすく、正規メールの到達率にも影響し得ます。

SPFの終端ポリシーの設定方法（DNS・Windows Server）

1. 送信元を確定してから終端を設定する

; 段階1：一覧外は softfail
city.example.lg.jp.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all"

; 段階2：DMARC集計レポートで漏れがないと確認できたら fail も検討
city.example.lg.jp.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

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

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

Web 専用のサブドメインやキャンペーン用ドメインにも設定しておくと、それらを名乗るなりすましを防ぎやすくなります。

3. redirect を使う場合

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

リダイレクト元に all を書くと redirect が無視されるので、どちらか一方にします。

4. Windows Server の DNS で管理している場合

既存の SPF レコードを削除してから新しい値を登録します（2件並存させない）。削除は -WhatIf で対象を確かめてから実行します。

Get-DnsServerResourceRecord -ZoneName "city.example.lg.jp" -Name "@" -RRType Txt
Get-DnsServerResourceRecord -ZoneName "city.example.lg.jp" -Name "@" -RRType Txt |
  Where-Object { $_.RecordData.DescriptiveText -like "v=spf1*" } |
  Remove-DnsServerResourceRecord -ZoneName "city.example.lg.jp" -WhatIf
Add-DnsServerResourceRecord -ZoneName "city.example.lg.jp" -Name "@" -Txt `
  -DescriptiveText "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all"

クラウド DNS やレジストラの管理画面では、既存の TXT 値を編集する形で変更します。

5. 確認方法

dig +short TXT city.example.lg.jp | grep -i 'v=spf1'
# 終端ポリシーだけを取り出す
dig +short TXT city.example.lg.jp | grep -io '[-~?+]\?all\b'

テスト送信したメールのヘッダーで Received-SPF: や Authentication-Results: の spf=pass を確認します。一覧外のサーバー（テスト用の別サービス等）から送った場合に spf=softfail / spf=fail になることも確認できます。

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

  • -all への変更は、全送信元の棚卸しと DMARC レポートでの確認が済んでから行います。漏れた送信元（複合機、外部委託の通知システム、職員が使う外部メール配信サービス等）からのメールが拒否されます。
  • メーリングリストや自動転送を経由するメールは SPF が失敗しやすいため、DKIM 署名を必ず併用します。
  • ?all から直接 -all にせず、~all を経由すると影響を観察しやすくなります。
  • レコードの編集は既存レコードの書き換えで行い、新しい v=spf1 レコードを追加しないでください（2件あると permerror）。

よくある質問（FAQ）

SPFの -all と ~all はどちらを使うべきですか？

メールを送らないドメインは v=spf1 -all が定番です。送信を行うドメインでは、DMARC運用下では転送メールでSPFが失敗しやすいため ~all を選ぶ組織も多くあります。本診断では両者を同等に扱い、大切なのは一覧外の送信元を「許可」や「判断なし」にしないことです。

?all は安全側の書き方ですか？

安全側ではありません。?all は neutral、つまり「判断しない」の意味で、SPFがないのと実質同じです。なりすまし判定には役立たないため、-all か ~all にします。

+all を付けると自分のメールが確実に届くのではありませんか？

+all は世界中のどのサーバーにも送信を許可する宣言で、なりすましを公認することになります。エンベロープ送信者を自治体ドメインにすれば攻撃者のメールもSPF passとなり、DMARCの保護まで無力化されるおそれがあります。

redirect= を使っているのに△になるのはなぜですか？

セキュリティAIチェッカーは redirect= の先を追跡しないためです。リダイレクト先で -all か ~all を設定していれば実質的に問題ありません。根拠を確認し、リダイレクト先のレコードを手動で確認してください。

-all にすればDMARCは不要ですか？

不要ではありません。SPFはエンベロープ送信者しか検証しないため、Fromヘッダーの偽装を防ぐにはDMARCが必要です。終端ポリシーは「SPF単独での最低限の意思表示」、DMARCは「From偽装への最終的な対処方針」と役割が異なります。

終端ポリシーを変更するときの注意点は？

既存のSPFレコードを書き換える形で変更し、新しい v=spf1 レコードを追加しないでください（2件あるとpermerror）。-all への変更は全送信元の棚卸しとDMARCレポートでの確認が済んでから行い、?all から直接 -all にせず ~all を経由します。

セキュリティAIチェッカーを利用する

この項目を含む127項目を、URLを入れるだけで無料診断します。

参考資料

「SPFの終端ポリシー」と関連する診断項目

セキュリティ診断127項目ガイドのトップへ戻る