SPF softfail の原因と対処｜切り分け手順
目次
この記事でわかること
softfailが「エラー」ではなく、SPF の仕様どおりの判定結果であること~allと-allの違い、受信側での扱われ方- softfail を 対処すべきケースと、対処不要なケースの見分け方
- 送信元 IP から原因を切り分ける具体的な手順
softfail とは何か
メールヘッダや DMARC レポートで spf=softfail を見つけると、設定を間違えたのかと不安になります。しかし softfail は、SPF の仕様（RFC 7208）で定義された正規の判定結果のひとつです。壊れているわけではありません。
SPF レコードの末尾には、~all や -all といった記述を置きます。これは「ここまでに挙げた IP アドレス以外から届いたメールを、受信側にどう扱ってほしいか」の指定です。
~all（softfail）は、このうち中間的な指定にあたります。「記載のない IP から来ているので正規の送信元ではないと思われるが、拒否までは求めない」という意味になります。
したがって spf=softfail が出ている状態は、次の事実を示しているだけです。
- そのメールは、SPF レコードに書かれていない IP アドレスから送られた
- ドメイン所有者は、その場合に拒否ではなく「疑わしい扱い」を求めている
問題は softfail という結果そのものではなく、なぜ記載のない IP から送られているのかにあります。ここを見ずにレコードだけ触ると、原因を外したまま設定を壊すことになります。
対処が必要なケースと、不要なケース
softfail には、急いで直すべきものと、直す必要がないものが混ざっています。これを分けずに扱うことが、遠回りの最大の原因です。
| ケース | 何が起きているか | 対処 |
|---|---|---|
| 記載漏れ | 自社が使っている配信サービスや新しいサーバーが SPF に入っていない | 必要。SPF に追加する |
| メール転送 | 転送されたことで送信元 IP が転送サーバーのものに変わった | SPF では直せない。DKIM で担保する |
| 第三者のなりすまし | 自社と無関係の送信元がドメインを騙っている | 不要。SPF が意図どおり機能している |
3 つ目が特に重要です。自社と無関係の IP に対する softfail は、なりすましを検知できていることを意味します。自社のメールは止まっていません。DMARC レポートに softfail が並んでいても、その送信元が第三者であれば、それは異常ではなく検知結果です。
送信元 IP から切り分ける手順
判断の分かれ目は一点、「その IP は自社が意図して使っている送信元か」です。
1. 送信元 IP を特定する
届かない、あるいは迷惑メール扱いされた実物のメールを開き、ヘッダの Authentication-Results を確認します。ここに判定結果と、判定に使われた送信元 IP が記載されています。読み方はメールヘッダの読み方と Authentication-Results の見方で詳しく扱っています。
DMARC レポートを運用している場合は、レポート内の送信元 IP の一覧からも同じ情報が得られます。
2. その IP に心当たりがあるかを確認する
特定した IP が、自社サーバー・契約中のメール配信サービス・グループ会社など、意図して使っている送信元かどうかを確認します。心当たりがない場合は、第三者による送信（なりすまし）の可能性が高くなります。
3. ケース別に対処する
記載漏れだった場合は、SPF レコードにその送信元を追加します。多くは配信サービスを新しく導入したときに、提供元が案内する include: の追記を忘れているパターンです。書き方は SPF レコードの設定方法を参照してください。
このとき注意したいのが、SPF には参照回数の上限があることです。include: を増やし続けると上限を超え、softfail とは別の永続エラー（permerror）になります。超過したときの対処は SPF 10 ルックアップ超過の対処にまとめています。
転送が原因だった場合は、SPF の仕組み上どうしても通りません。SPF は「最後に接続してきたサーバーの IP」で判定するため、転送されると送信元が転送サーバーのものに変わり、元のドメインの SPF には一致しなくなります。この経路を成立させるには、送信元 IP に依存しない DKIM 署名で担保する必要があります。メーリングリスト経由で認証が壊れる問題はメーリングリストと 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 の段階的強化で、失敗時の切り分けは DMARC fail の原因と切り分けで解説しています。
~all のままにするか、-all に進めるか
この判断で迷うのには理由があります。主要な事業者どうしで推奨が分かれているためです。
- Google は、送信ドメインの SPF に
~allを使うことを推奨しています。記載漏れがあったときにメールが即座に失われるのを避け、切り分けの余地を残す考え方です - Microsoft は
-allを推奨しています。ただしこれは、DKIM と DMARC を併用することを前提とした推奨です
どちらも「自社の前提つきの推奨」であり、一方が誤りというものではありません。共通しているのは順序で、送信元を出し切れたと確認できてから -all に進めるのが原則です。逆順に進めると、記載漏れがそのまま配信停止につながります。
DMARC の状態に応じてどちらを選ぶかの整理と、~all から -all への具体的な切替手順は、SPF Fail と SoftFail の違い・対処早見表にまとめています。本記事は「いま softfail が出ている原因を突き止める」ことに絞っているため、切替の判断まで進む場合はそちらを参照してください。
まとめ
- softfail は仕様どおりの判定結果であり、それ自体は故障ではない
- 対処すべきなのは「記載漏れ」だけで、転送は DKIM の担当、第三者なりすましは対処不要
- 判断は送信元 IP を見て行う。IP を確認しないまま SPF を書き換えない
- DMARC を強化する前に、softfail の内訳を分解しておく
自社の状況を確認してみませんか
自社ドメインの SPF がいまどう書かれているか、DKIM や DMARC と噛み合っているかは、無料ドメイン診断でその場に確認できます。登録は不要で、SPF・DKIM・DMARC の設定状況を重要なものから順に表示します。
~all のまま運用を続けるか、-all に進めるかの判断材料としてもご利用ください。設定内容に迷いがある場合はお問い合わせからご相談いただけます。