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

- `Received-SPF:` の後ろにある `pass` `fail` `softfail` `neutral` `none` などが何を意味するか
- このヘッダが「いつ・どのサーバで」付与されるのか
- `softfail`（`~all`）と `fail`（`-all`）が受信結果としてどう違うか
- `Authentication-Results` ヘッダとの役割の違い

## Received-SPF ヘッダとは

`Received-SPF` は、受信したメールのヘッダ（メール本文の前に付く配送記録）に書かれる行で、「このメールの送信元 IP は、差出人ドメインが許可した送信元だったか」を受信側サーバが判定した結果を記録したものです。

具体的には次のような 1 行です。

```
Received-SPF: pass (google.com: domain of info@example.com
  designates 203.0.113.10 as permitted sender)
  client-ip=203.0.113.10;
```

ここで読むべきは先頭の判定値（この例では `pass`）です。SPF（Sender Policy Framework＝差出人ドメインが「正規の送信サーバはこれです」と DNS に公開する仕組み）の照合結果が、この一語に集約されています。

SPF の基礎そのものは [SPF Fail と SoftFail の違い](/blog/spf-fail-vs-softfail) と [DMARC とは何か](/blog/what-is-dmarc) で扱っているため、本記事は **受信側で実際に届いたヘッダをどう読むか** に絞ります。

## ヘッダはどこで付与されるのか

`Received-SPF` は **送信側ではなく、メールを受け取った側のサーバ（受信 MTA）が付けます**。Gmail なら Google の受信サーバ、Microsoft 365 なら Microsoft の受信サーバが、自分のところに届いた瞬間に SPF 照合を行い、その結果をヘッダとして書き足します。

つまりこのヘッダは「送信元が正しいと主張した値」ではなく、「**受信側が DNS を引いて検証した結果**」です。だからこそ、なりすましの判断材料として信頼できます。

逆に言うと、送信元が自分でヘッダを偽装しても、最終的に受信したサーバが上書きで本物の判定を追記します。最も外側（一番上）の `Received-SPF` を読むのが原則です。

![Received-SPF ヘッダが付与される流れ](/blog/received-spf-header-yomikata/where-added.svg)

## 判定値の意味（早見表）

`Received-SPF` の判定値は RFC 7208 で定義された 7 種類が基本です。それぞれの意味と、受信側で一般的に取られる扱いを整理します。

![Received-SPF 判定値の意味と扱い](/blog/received-spf-header-yomikata/result-values.svg)

| 判定値 | 意味 | 一般的な扱い |
|---|---|---|
| `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 の違い](/blog/spf-fail-vs-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=pass` `dkim=pass` `dmarc=pass` のように並ぶ）

`Authentication-Results` の `spf=` の値は、基本的に `Received-SPF` の判定値と一致します。最終的なメール採否は SPF 単体ではなく DMARC の総合判定で決まるため、なりすまし対策の文脈では `Authentication-Results` の `dmarc=` も合わせて読みます。ヘッダ全体の読み方は [メールヘッダの読み方ガイド](/blog/email-headers-reading-guide) で詳しく解説しています。

## よくある質問

**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 の違い](/blog/spf-fail-vs-softfail) の lookup 上限の項を確認してください。

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

自社ドメインから送ったメールが受信側で `pass` になっているか、`softfail` や `none` になっていないかは、無料の[ドメイン診断](/diagnose)で SPF レコードの状態を確認できます。判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。