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

- `softfail` が「エラー」ではなく、SPF の仕様どおりの判定結果であること
- `~all` と `-all` の違い、受信側での扱われ方
- softfail を **対処すべきケースと、対処不要なケース**の見分け方
- 送信元 IP から原因を切り分ける具体的な手順

## softfail とは何か

メールヘッダや DMARC レポートで `spf=softfail` を見つけると、設定を間違えたのかと不安になります。しかし softfail は、SPF の仕様（RFC 7208）で定義された**正規の判定結果のひとつ**です。壊れているわけではありません。

SPF レコードの末尾には、`~all` や `-all` といった記述を置きます。これは「ここまでに挙げた IP アドレス**以外**から届いたメールを、受信側にどう扱ってほしいか」の指定です。

![SPF レコード末尾の all で結果が変わる](/blog/spf-softfail-fix/all-mechanism-comparison.svg)

`~all`（softfail）は、このうち**中間的な指定**にあたります。「記載のない IP から来ているので正規の送信元ではないと思われるが、拒否までは求めない」という意味になります。

したがって `spf=softfail` が出ている状態は、次の事実を示しているだけです。

- そのメールは、**SPF レコードに書かれていない IP アドレスから送られた**
- ドメイン所有者は、その場合に**拒否ではなく「疑わしい扱い」を求めている**

問題は softfail という結果そのものではなく、**なぜ記載のない IP から送られているのか**にあります。ここを見ずにレコードだけ触ると、原因を外したまま設定を壊すことになります。

### 対処が必要なケースと、不要なケース

softfail には、**急いで直すべきもの**と、**直す必要がないもの**が混ざっています。これを分けずに扱うことが、遠回りの最大の原因です。

| ケース | 何が起きているか | 対処 |
|---|---|---|
| 記載漏れ | 自社が使っている配信サービスや新しいサーバーが SPF に入っていない | **必要**。SPF に追加する |
| メール転送 | 転送されたことで送信元 IP が転送サーバーのものに変わった | **SPF では直せない**。DKIM で担保する |
| 第三者のなりすまし | 自社と無関係の送信元がドメインを騙っている | **不要**。SPF が意図どおり機能している |

3 つ目が特に重要です。自社と無関係の IP に対する softfail は、**なりすましを検知できている**ことを意味します。自社のメールは止まっていません。DMARC レポートに softfail が並んでいても、その送信元が第三者であれば、それは異常ではなく検知結果です。

## 送信元 IP から切り分ける手順

判断の分かれ目は一点、**「その IP は自社が意図して使っている送信元か」**です。

![softfail が出たときの切り分け](/blog/spf-softfail-fix/softfail-triage-flow.svg)

### 1. 送信元 IP を特定する

届かない、あるいは迷惑メール扱いされた実物のメールを開き、ヘッダの `Authentication-Results` を確認します。ここに判定結果と、判定に使われた送信元 IP が記載されています。読み方は[メールヘッダの読み方](/blog/email-headers-reading-guide)と [Authentication-Results の見方](/blog/authentication-results-yomikata)で詳しく扱っています。

DMARC レポートを運用している場合は、レポート内の送信元 IP の一覧からも同じ情報が得られます。

### 2. その IP に心当たりがあるかを確認する

特定した IP が、自社サーバー・契約中のメール配信サービス・グループ会社など、**意図して使っている送信元**かどうかを確認します。心当たりがない場合は、第三者による送信（なりすまし）の可能性が高くなります。

### 3. ケース別に対処する

**記載漏れだった場合**は、SPF レコードにその送信元を追加します。多くは配信サービスを新しく導入したときに、提供元が案内する `include:` の追記を忘れているパターンです。書き方は [SPF レコードの設定方法](/blog/spf-setup-guide)を参照してください。

このとき注意したいのが、SPF には参照回数の上限があることです。`include:` を増やし続けると上限を超え、**softfail とは別の永続エラー（permerror）**になります。超過したときの対処は [SPF 10 ルックアップ超過の対処](/blog/spf-flattening)にまとめています。

**転送が原因だった場合**は、SPF の仕組み上どうしても通りません。SPF は「最後に接続してきたサーバーの IP」で判定するため、転送されると送信元が転送サーバーのものに変わり、元のドメインの SPF には一致しなくなります。この経路を成立させるには、送信元 IP に依存しない DKIM 署名で担保する必要があります。メーリングリスト経由で認証が壊れる問題は[メーリングリストと ARC](/blog/mailing-list-arc)で扱っています。

なお、記載漏れでも転送でも、**結果が softfail になるか fail になるかはレコード末尾の指定しだい**です。`~all` なら softfail、`-all` なら fail になります。同じ原因でも、自社が `-all` を使っていれば fail として現れます。

## SPF と DMARC の関係で注意すること

softfail を軽視できない理由が、DMARC との関係にあります。

DMARC は、SPF と DKIM の**いずれかが「pass」し、かつドメインが一致している**ことを求めます。softfail は pass ではないため、DMARC の評価上は SPF 側が根拠になりません。

つまり、次の状態が成立します。

- SPF が softfail **かつ** DKIM も通っていない → DMARC は失敗し、公開しているポリシー（`p=quarantine` や `p=reject`）が適用される
- SPF が softfail **でも** DKIM が通っている → DMARC としては成立し、配信は維持される

ここから導かれる実務上の要点は、**DMARC のポリシーを強化する前に、softfail の中身を分解しておく**ことです。記載漏れを残したまま `p=reject` に進めると、自社の正規メールが拒否されます。段階的な進め方は [DMARC の段階的強化](/blog/dmarc-policy-tightening)で、失敗時の切り分けは [DMARC fail の原因と切り分け](/blog/dmarc-fail-troubleshooting)で解説しています。

### `~all` のままにするか、`-all` に進めるか

この判断で迷うのには理由があります。**主要な事業者どうしで推奨が分かれている**ためです。

- **Google** は、送信ドメインの SPF に `~all` を使うことを推奨しています。記載漏れがあったときにメールが即座に失われるのを避け、切り分けの余地を残す考え方です
- **Microsoft** は `-all` を推奨しています。ただしこれは、**DKIM と DMARC を併用することを前提とした推奨**です

どちらも「自社の前提つきの推奨」であり、一方が誤りというものではありません。共通しているのは順序で、**送信元を出し切れたと確認できてから `-all` に進める**のが原則です。逆順に進めると、記載漏れがそのまま配信停止につながります。

DMARC の状態に応じてどちらを選ぶかの整理と、`~all` から `-all` への具体的な切替手順は、[SPF Fail と SoftFail の違い・対処早見表](/blog/spf-fail-vs-softfail)にまとめています。本記事は「いま softfail が出ている原因を突き止める」ことに絞っているため、切替の判断まで進む場合はそちらを参照してください。

## まとめ

- softfail は仕様どおりの判定結果であり、それ自体は故障ではない
- 対処すべきなのは「記載漏れ」だけで、転送は DKIM の担当、第三者なりすましは対処不要
- 判断は送信元 IP を見て行う。IP を確認しないまま SPF を書き換えない
- DMARC を強化する前に、softfail の内訳を分解しておく

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

自社ドメインの SPF がいまどう書かれているか、DKIM や DMARC と噛み合っているかは、[無料ドメイン診断](/diagnose)でその場に確認できます。登録は不要で、SPF・DKIM・DMARC の設定状況を重要なものから順に表示します。

`~all` のまま運用を続けるか、`-all` に進めるかの判断材料としてもご利用ください。設定内容に迷いがある場合は[お問い合わせ](/contact)からご相談いただけます。