## この記事でわかること

- SPF レコード末尾の `-all` / `~all` / `?all` / `+all` がそれぞれ何を意味するか
- 受信側がどう扱い、配信性とセキュリティにどう影響するか
- DMARC と組み合わせたときに、どの値が現実的に安全か

SPF レコードを読むと、必ず末尾に `~all` か `-all`、ときどき `?all` が付いています。この末尾の修飾子（all qualifier）は、レコードに列挙していない送信元から届いたメールを **受信サーバーがどう扱うべきか** を指示する一番大事な部分です。`include` の数や IP の列より、まずここを正しく選ぶのが運用の出発点になります。SPF レコード全体の構文や設定手順は[SPF レコードの設定方法](/blog/spf-setup-guide)で解説しています。本記事では `all` 修飾子だけにフォーカスし、4 種類の違いと選び方を整理します。

![all 修飾子の挙動と推奨度](/blog/spf-all-qualifier/all-qualifier-comparison.svg)

## `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 の違い・対処早見表](/blog/spf-fail-vs-softfail)にまとめています。

導入直後で送信元の棚卸しが終わっていない時期に向きます。DMARC を `p=none` または `p=quarantine` で並走させ、aggregate レポートで「SPF が fail しているのに自社の正規送信元」を見つけるフェーズと相性が良いです。新しいクラウドサービスを社内で勝手に契約されがちな企業ほど、観察期間を取るメリットが大きくなります。

### `?all`（neutral）と `+all`（絶対禁止）

`?all` は「SPF として何も判断しないでください」という宣言で、レコード自体は存在するのに事実上 SPF を無効化しているのと同じです。テスト用途以外で本番運用する理由はほぼありません。受信側は neutral 結果を「未設定とほぼ同じ」と扱うため、なりすまし対策の効果が出ません。

`+all` はさらに危険で、**「どの送信元から届いてもすべて pass にしてください」** という意味になります。攻撃者があなたのドメインを名乗って送ってきても SPF=pass になってしまうため、なりすまし放置宣言と同じです。設定例を Web で見つけて意味がわからず真似しないでください。

DMARC の解説とあわせて[DMARC のポリシー段階強化](/blog/dmarc-policy-tightening)も読むと、なぜ `+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. **フェーズ 1（導入期）**: SPF を `~all`、DMARC を `p=none` にして 2〜4 週レポートを集める
2. **フェーズ 2（観察期）**: DMARC を `p=quarantine` に上げ、未登録の正規送信元を SPF か DKIM で救い上げる
3. **フェーズ 3（強化期）**: SPF を `-all` に切り替え、DMARC を `p=reject` で固める

![~all から -all への段階強化フロー](/blog/spf-all-qualifier/spf-tightening-flow.svg)

各フェーズの所要期間は事業規模によりますが、相場感としては合計 1ヶ月〜3ヶ月、外部に運用代行を頼む場合は数千円〜数万円/月の運用費を見ておくと現実的です。

`include` の入れ子による 10 lookup 上限超えで `~all` 自体が機能していないケースも多いので、修飾子を選ぶ前に[SPF の include 入れ子と上限](/blog/spf-include-nesting)もあわせて確認しておくと事故が減ります。RFC ベースの仕様を一次情報で確認したい方は [RFC 7208 §4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4) を参照してください。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。