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

- `-all`（Fail）と `~all`（SoftFail）が受信側に対してどう違うか
- **SPF の判定結果 7 種類**（pass / fail / softfail / neutral / none / permerror / temperror）の見分け方
- Gmail / Outlook での実質的な扱いの差
- DMARC を併用すると `~all` でも実質 `-all` 相当になる仕組み
- 安全に `~all` → `-all` へ切り替える手順
- **「softfail のまま放置してよいか」への答え**（よくある質問）

本記事は修飾子どうしの**違いと切替判断**を扱います。いま実際に `spf=softfail` が出ていて**原因を突き止めたい**場合は、[SPF softfail の原因と対処](/blog/spf-softfail-fix)で送信元 IP からの切り分け手順を解説しています。

## SPF 末尾修飾子の意味

SPF レコードの末尾には必ず `?all` `~all` `-all` `+all` のいずれかが付きます。これは「許可リストに無い IP から送られたメールをどう扱うか」を示すヒントです。

| 修飾子 | 意味 | 推奨度 |
|---|---|---|
| `+all` | 全許可 | ❌ 絶対 NG |
| `?all` | Neutral（判定保留） | ❌ 意味薄い |
| `~all` | SoftFail（疑わしいが受信側判断） | ⚠️ 過渡期 |
| `-all` | Fail（拒否を強く推奨） | ✅ 推奨 |

![SPF 末尾修飾子の強度](/blog/spf-fail-vs-softfail/qualifiers.svg)

## SPF の判定結果は 7 種類ある

末尾修飾子は「送信側がどう宣言するか」ですが、実際にメールが届いたときに**受信側が出す判定結果**は別の語彙です。ヘッダで見かける値は次の 7 つで、`softfail` はそのうちの 1 つにすぎません。

| 判定結果 | 何が起きたか | 送信側がすべきこと |
|---|---|---|
| `pass` | 送信元 IP が SPF に含まれていた | なし |
| `fail` | SPF に無い IP から送られ、末尾が `-all` | **送信元を SPF に追加する** |
| `softfail` | SPF に無い IP から送られ、末尾が `~all` | 原因による（下記） |
| `neutral` | 末尾が `?all` で、判定を放棄している | `~all` か `-all` にする |
| `none` | **そのドメインに SPF レコードが無い** | SPF を設定する |
| `permerror` | SPF の書式エラー。10 ルックアップ超過が典型 | [10 個制限の対処](/blog/spf-include-limit-fix)へ |
| `temperror` | DNS 問い合わせが一時的に失敗した | 時間をおいて再確認。設定の問題ではない |

**間違えやすいのは `none` と `fail` の違い**です。`none` は「SPF が無い」、`fail` は「SPF はあるが、その IP は許可されていない」。前者は設定漏れ、後者は設定の不足で、直す場所が違います。

`permerror` も要注意で、**書式が壊れていると SPF は「失敗」ではなく「評価不能」**になります。DMARC からは pass しなかったものとして扱われるため、実質 fail と同じ影響が出ます。

## 受信側の挙動

**`-all`（Fail）**: 認証失敗を強く示すシグナル。SPF 単体評価でも spam フォルダ行きの判定に強く影響。

**`~all`（SoftFail）**: 「許可リスト外だが、拒否までは要請しない」。受信側は spam スコアに加点する程度の扱いが一般的で、配送自体は通る場合が多い。

ただし、**DMARC を併用している場合は挙動が変わります**。

![DMARC 併用での実質強度](/blog/spf-fail-vs-softfail/with-dmarc.svg)

DMARC は `~all` も `-all` も「SPF アラインメント fail」として同等に扱います。つまり **DMARC `p=reject` が効いている場合、`~all` でも実質 `-all` 相当**になります。逆に DMARC が `p=none` なら `~all` は実質ほぼ意味なし。

## どちらを使うべきか

- **DMARC `p=reject` が運用中**: `~all` でも `-all` でも実質同じ。ただし**将来の DMARC ポリシー後退や、SPF 単独評価を行う一部古いメールサーバへの配慮として `-all` 推奨**
- **DMARC `p=none` / 未設定**: `~all` は実質的にほぼ機能しない。`-all` に設定する必要がある
- **DMARC 段階強化中**: SPF も `~all` → `-all` に同時に進めるのが整合的

## `~all` → `-all` への安全な切替手順

1. **DMARC レポート（rua）を 2 週間観察**: 認証失敗している正規送信元（マーケツール、CRM、決済通知など）を洗い出す
2. **すべての正規送信元を SPF に include 追加**: 漏れがあれば追加（[SPF 設定ガイド](/blog/spf-setup-guide) 参照）
3. **DMARC を `p=quarantine` に強化**: ここで挙動を 1 週間確認
4. **SPF を `-all` に切替**: 同時に DMARC を `p=reject` に進める

逆順に進めない（先に `-all` だけ切替えると正規メールが弾かれます）。

## よくある質問

### softfail が出ていますが、放置して問題ありませんか

**原因によります。** 転送されたメールや、第三者が勝手に自社ドメインを騙って送ったメールが softfail になるのは**正常な動作**で、`~all` のままでも構いません。一方、**自社が実際に使っている送信サービスが SPF に書かれていない**ために softfail になっているなら、それは設定漏れで、放置すると迷惑メール判定が増えます。切り分けは[SPF softfail の原因と対処](/blog/spf-softfail-fix)を参照してください。

### `~all` のままでもメールは届きますか

多くの場合は届きます。softfail は「拒否してよい」ではなく「疑わしいので受信側の判断に任せる」という宣言だからです。ただし**受信側で迷惑メールスコアに加点される**ため、他の要因（本文の内容、送信 IP の評判）と重なると迷惑メールフォルダに入ります。

### DMARC を設定していれば `~all` でも大丈夫ですか

**DMARC のポリシー次第です。** `p=reject` / `p=quarantine` が効いていれば、DMARC は `~all` も `-all` も同じ「SPF アラインメント fail」として扱うため、実質的な差はありません。逆に `p=none` のままだと `~all` はほとんど機能しません。上の「どちらを使うべきか」を参照してください。

### 受信したメールが softfail かどうかは、どこで分かりますか

メールヘッダの `Received-SPF:` または `Authentication-Results:` に判定結果が入っています。読み方は[Authentication-Results ヘッダの読み方](/blog/authentication-results-yomikata)と[Received-SPF ヘッダの読み方](/blog/received-spf-header-yomikata)で解説しています。

### `-all` にしたら自社のメールが届かなくなりました

**送信元をすべて SPF に書き切れていない状態で `-all` にすると起こります。** 上の切替手順のとおり、まず DMARC のレポートで送信元を洗い出してから切り替えてください。急いで戻す場合は `~all` に戻せば、判定は softfail に緩みます。

## まずは現状を把握しましょう

自社の SPF レコード末尾が `~all` のままになっていないか、無料の[ドメイン診断](/diagnose)で確認できます。判断に迷う場合は[お問い合わせ](/contact)からご相談ください。

関連記事: [SPF 設定ガイド](/blog/spf-setup-guide) / [SPF include 10 個制限の対処](/blog/spf-flattening) / [DMARC ポリシーを quarantine に強化する手順](/blog/dmarc-policy-tightening)