Received-SPF ヘッダの見方・判定値早見表
目次
この記事でわかること
Received-SPF:の後ろにあるpassfailsoftfailneutralnoneなどが何を意味するか- このヘッダが「いつ・どのサーバで」付与されるのか
softfail（~all）とfail（-all）が受信結果としてどう違うかAuthentication-Resultsヘッダとの役割の違い
Received-SPF ヘッダとは
Received-SPF は、受信したメールのヘッダ（メール本文の前に付く配送記録）に書かれる行で、「このメールの送信元 IP は、差出人ドメインが許可した送信元だったか」を受信側サーバが判定した結果を記録したものです。
具体的には次のような 1 行です。
Received-SPF: pass (google.com: domain of [email protected]
designates 203.0.113.10 as permitted sender)
client-ip=203.0.113.10;
ここで読むべきは先頭の判定値（この例では pass）です。SPF（Sender Policy Framework＝差出人ドメインが「正規の送信サーバはこれです」と DNS に公開する仕組み）の照合結果が、この一語に集約されています。
SPF の基礎そのものは SPF Fail と SoftFail の違い と DMARC とは何か で扱っているため、本記事は 受信側で実際に届いたヘッダをどう読むか に絞ります。
ヘッダはどこで付与されるのか
Received-SPF は 送信側ではなく、メールを受け取った側のサーバ（受信 MTA）が付けます。Gmail なら Google の受信サーバ、Microsoft 365 なら Microsoft の受信サーバが、自分のところに届いた瞬間に SPF 照合を行い、その結果をヘッダとして書き足します。
つまりこのヘッダは「送信元が正しいと主張した値」ではなく、「受信側が DNS を引いて検証した結果」です。だからこそ、なりすましの判断材料として信頼できます。
逆に言うと、送信元が自分でヘッダを偽装しても、最終的に受信したサーバが上書きで本物の判定を追記します。最も外側（一番上）の Received-SPF を読むのが原則です。
判定値の意味（早見表）
Received-SPF の判定値は RFC 7208 で定義された 7 種類が基本です。それぞれの意味と、受信側で一般的に取られる扱いを整理します。
| 判定値 | 意味 | 一般的な扱い |
|---|---|---|
pass |
送信元 IP は差出人ドメインが許可した正規サーバ | 正常。認証成功 |
fail |
許可リストに 無い IP（ドメインが -all で明確に拒否） |
なりすまし疑い大。拒否 / 迷惑メール行き |
softfail |
許可リストに無いが、拒否までは要請しない（~all） |
迷惑メールスコア加点。配送は通ることが多い |
neutral |
ドメインが明示的に「判定しない」と表明（?all） |
判定材料にならない。素通り |
none |
差出人ドメインに SPF レコードが存在しない | 照合不能。判定材料なし |
permerror |
SPF レコードの記述に恒久的な誤り（例: include 10 個超過） | 設定ミス。送信側の修正が必要 |
temperror |
DNS 一時障害などで照合できなかった | 一時的。再送で解消することがある |
permerror が出る代表的な原因が SPF の DNS lookup 10 回上限超過です。詳細と対処は SPF Fail と SoftFail の違い を参照してください。
softfail と fail の違いを読み分ける
実務で最も判断に迷うのが softfail と fail の差です。どちらも「許可リストに無い IP からのメール」ですが、差出人ドメイン側の意思表示が違います。
fail: ドメインが SPF レコード末尾を-allにしている。「許可外は拒否してよい」という強い表明softfail: ドメインが末尾を~allにしている。「許可外だが疑わしい程度の扱いにとどめてほしい」という弱い表明
つまり判定値の差は 受信側の気分ではなく、送信ドメインが公開した -all / ~all の差 をそのまま反映しています。自社から送ったメールが相手先で softfail になっていたら、SPF に正規送信元が漏れなく登録されているか、末尾修飾子が適切かを見直すサインです。
neutral や none は「判定不能」であり、安全を意味しません。これらが頻発するドメインはなりすましに弱い状態です。
Authentication-Results ヘッダとの違い
近年のメールには Received-SPF とは別に Authentication-Results ヘッダも付きます。両者の関係は次の通りです。
Received-SPF: SPF 単体の照合結果だけを記録する専用ヘッダAuthentication-Results: SPF・DKIM・DMARC を まとめて 記録する総合ヘッダ（spf=passdkim=passdmarc=passのように並ぶ）
Authentication-Results の spf= の値は、基本的に Received-SPF の判定値と一致します。最終的なメール採否は SPF 単体ではなく DMARC の総合判定で決まるため、なりすまし対策の文脈では Authentication-Results の dmarc= も合わせて読みます。ヘッダ全体の読み方は メールヘッダの読み方ガイド で詳しく解説しています。
よくある質問
Q. Received-SPF が none なのは問題ですか。
差出人ドメインに SPF レコードが無い状態です。自社ドメインで none が出ているなら、なりすましに対して無防備なので SPF の設定を推奨します。受信側としては「判定材料が無い」だけで、即なりすましとは限りません。
Q. softfail のメールは届かないのですか。
多くの受信サーバは softfail でも配送自体は通し、迷惑メールスコアを加点する程度の扱いをします。ただし DMARC が p=reject で運用されている場合、softfail でも拒否されることがあります。
Q. ヘッダが複数の Received-SPF を含むことがあります。どれを読めばよいですか。 中継経路ごとに付くことがあります。最終的に自分の受信サーバが付けた、最も上（外側）の行を読むのが原則です。
Q. 自社から送ったメールが相手先で permerror になります。
SPF レコードの記述ミスが原因です。include の参照が 10 回を超えているケースが代表的です。SPF Fail と SoftFail の違い の lookup 上限の項を確認してください。
まずは現状を把握しましょう
自社ドメインから送ったメールが受信側で pass になっているか、softfail や none になっていないかは、無料のドメイン診断で SPF レコードの状態を確認できます。判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。