SPF の -all ~all ?all +all の違い
目次
この記事でわかること
- SPF レコード末尾の
-all/~all/?all/+allがそれぞれ何を意味するか - 受信側がどう扱い、配信性とセキュリティにどう影響するか
- DMARC と組み合わせたときに、どの値が現実的に安全か
SPF レコードを読むと、必ず末尾に ~all か -all、ときどき ?all が付いています。この末尾の修飾子（all qualifier）は、レコードに列挙していない送信元から届いたメールを 受信サーバーがどう扱うべきか を指示する一番大事な部分です。include の数や IP の列より、まずここを正しく選ぶのが運用の出発点になります。SPF レコード全体の構文や設定手順はSPF レコードの設定方法で解説しています。本記事では all 修飾子だけにフォーカスし、4 種類の違いと選び方を整理します。
all 修飾子は「許可リストの外側」を決める
SPF は「このドメインから送ってよいサーバー」を ip4: や include: で列挙する仕組みです。問題は、列挙したどれにも当てはまらない送信元から届いたときの判断で、それを 1 文字の修飾子で表現します。
| 修飾子 | SPF 結果 | 一言で言うと |
|---|---|---|
-all |
hardfail | 「該当外は拒否してほしい」 |
~all |
softfail | 「該当外は怪しいので注意してほしい」 |
?all |
neutral | 「判断しないでほしい」 |
+all |
pass | 「全部 OK」（事実上の無効化） |
仕様としては RFC 7208 が定義しており、修飾子に応じて受信側 MTA が Received-SPF ヘッダや内部スコアに反映します。ただし最終的な拒否判断は受信サーバーの実装に委ねられているため、「-all だから絶対拒否される」とは限りません。あくまで送信側の意思表示です。
-all（hardfail）の挙動と使いどころ
-all は「列挙した送信元以外からのメールは絶対に自分が送ったものではない」という強い宣言です。受信側は SPF=fail と判定し、Gmail や Microsoft 365 では拒否または迷惑メールフォルダに直行する挙動が一般的です。
DMARC と組み合わせるとさらに明確で、SPF=fail かつ DMARC ポリシーが p=reject なら受信サーバーは堂々とメールを破棄できます。なりすまし対策としては最強ですが、その分 SPF レコードが不完全だと自社の正規メールまで弾かれる リスクを背負います。請求書発行 SaaS、人事系のクラウドサービス、メールマガジン配信ツールなど、登録漏れがちな送信元が無いかを確認してから適用してください。
~all（softfail）の挙動と使いどころ
~all は「列挙外からのメールは怪しいが、迷惑メールとして受け取ってもらってよい」という弱めの宣言です。SPF=softfail として処理され、多くの受信サーバーは迷惑メールフォルダ行きにする一方、明示的な拒否はしません。fail（-all）と softfail（~all）で Gmail / Outlook の扱いがどう変わるかの早見表はSPF Fail と SoftFail の違い・対処早見表にまとめています。
導入直後で送信元の棚卸しが終わっていない時期に向きます。DMARC を p=none または p=quarantine で並走させ、aggregate レポートで「SPF が fail しているのに自社の正規送信元」を見つけるフェーズと相性が良いです。新しいクラウドサービスを社内で勝手に契約されがちな企業ほど、観察期間を取るメリットが大きくなります。
?all（neutral）と +all（絶対禁止）
?all は「SPF として何も判断しないでください」という宣言で、レコード自体は存在するのに事実上 SPF を無効化しているのと同じです。テスト用途以外で本番運用する理由はほぼありません。受信側は neutral 結果を「未設定とほぼ同じ」と扱うため、なりすまし対策の効果が出ません。
+all はさらに危険で、「どの送信元から届いてもすべて pass にしてください」 という意味になります。攻撃者があなたのドメインを名乗って送ってきても SPF=pass になってしまうため、なりすまし放置宣言と同じです。設定例を Web で見つけて意味がわからず真似しないでください。
DMARC の解説とあわせてDMARC のポリシー段階強化も読むと、なぜ +all が壊滅的に悪いのかが立体的にわかります。
DMARC と組み合わせた現実解
-all でなければ守れない、と思い込む必要はありません。実運用では SPF を ~all のままにして、DMARC で p=reject を出す構成でも、なりすましメールの大半は受信側で破棄されます。なぜなら DMARC は SPF と DKIM の両方を見ており、片方でも整合する pass があれば通過、いずれも fail なら DMARC ポリシーで処理できるからです。
つまり ~all + p=reject という組み合わせは、
- SPF レコードの登録漏れがあっても DKIM が通れば配信される（保険として優しい）
- 攻撃者は SPF も DKIM も持っていないので DMARC で拒否される
という二段構えになります。実際、Google や Microsoft も自社ドメインで ~all を採用しています。重要なのは「~all か -all か」より「DMARC のポリシーが何になっているか」です。
段階強化のすすめ
恐怖訴求で「すぐ -all に」と煽るベンダーもありますが、運用では 段階強化が安全 です。
- フェーズ 1（導入期）: SPF を
~all、DMARC をp=noneにして 2〜4 週レポートを集める - フェーズ 2（観察期）: DMARC を
p=quarantineに上げ、未登録の正規送信元を SPF か DKIM で救い上げる - フェーズ 3（強化期）: SPF を
-allに切り替え、DMARC をp=rejectで固める
各フェーズの所要期間は事業規模によりますが、相場感としては合計 1ヶ月〜3ヶ月、外部に運用代行を頼む場合は数千円〜数万円/月の運用費を見ておくと現実的です。
include の入れ子による 10 lookup 上限超えで ~all 自体が機能していないケースも多いので、修飾子を選ぶ前にSPF の include 入れ子と上限もあわせて確認しておくと事故が減ります。RFC ベースの仕様を一次情報で確認したい方は RFC 7208 §4.6.4 を参照してください。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。