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

- Authentication-Results ヘッダで `spf=` / `dkim=` / `dmarc=` の合否を読む方法
- pass / fail / none / softfail / temperror / permerror の意味の違い
- Gmail・Outlook で認証結果を自分で確認する手順

## 「なぜ迷惑メール判定されたのか」を自分で確かめたい

「うちから送ったメールが、取引先の迷惑メールフォルダに入っていた」「逆に、届いたメールが本物か怪しい」——こんなとき、答えはメールの中にあります。

受信したメールには **Authentication-Results（オーセンティケーション・リザルツ＝認証結果）** というヘッダ（メールの裏側に付く管理用の情報）が記録されています。ここを読めば、そのメールが SPF・DKIM・DMARC という 3 つのメール認証をそれぞれ通過したのか、失敗したのかが一目でわかります。

このヘッダの書式は **RFC 8601**（インターネット標準仕様）で定義されており、Gmail や Outlook など主要なメールサービスが共通してこの形式で記録しています。読み方さえ覚えれば、どのサービスでも同じ要領で確認できます。

メール認証そのものの仕組みをまだ押さえていない方は、先に [SPF・DKIM・DMARC の違いをわかりやすく解説](/blog/spf-dkim-dmarc-difference) を読んでおくと、この先の内容がぐっと理解しやすくなります。

## Authentication-Results の全体構造

まず、典型的な 1 通の例を見てみましょう。すべての認証が通っている「理想の状態」です。

```
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@example.co.jp
            designates 203.0.113.10 as permitted sender)
            smtp.mailfrom=bounce@example.co.jp;
       dkim=pass header.i=@example.co.jp header.s=selector1;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.co.jp
```

一見すると暗号のようですが、構造はシンプルです。

![Authentication-Results ヘッダの構造](/blog/authentication-results-yomikata/header-structure.svg)

- **先頭の `mx.google.com`**：どのサーバーが認証を判定したか（authserv-id）。Gmail なら `mx.google.com` になります
- **`spf=` / `dkim=` / `dmarc=`**：それぞれの認証方式と、その結果（合否）
- **カッコ内や `smtp.mailfrom=` などの付帯情報**：判定の根拠になったドメインや IP アドレス

つまり「**方式＝結果**」のセットが 3 つ並んでいるだけ、と捉えれば読みやすくなります。RFC 8601 では各セットを `method=result` の形で記述すると定められています。

## 結果値（pass / fail / none …）の読み分け

結果値は数種類あり、方式ごとに使える値が決まっています。下の早見表を手元に置いて読むと迷いません。

![認証結果値の早見表](/blog/authentication-results-yomikata/result-values.svg)

| 結果値 | 意味 | どう受け止めるか |
|---|---|---|
| **pass** | 認証に成功した | 正常。送信元として正しいと確認できた |
| **fail** | 認証に失敗した | 設定漏れ、または なりすましの可能性 |
| **none** | 認証情報が無い／評価していない | SPF・DKIM・DMARC が未設定の状態 |
| **softfail** | 失敗だが弱い拒否（SPF のみ） | SPF が `~all`。怪しいが拒否まではしない扱い |
| **neutral** | 判定を保留（合否を示さない） | SPF が `?all` 等。明確な合否がない |
| **temperror** | 一時的なエラー | DNS の一時障害など。再送で解消することがある |
| **permerror** | 恒久的なエラー | レコードの記述ミス。直さない限り解消しない |

ポイントは **fail と softfail の差** です。SPF の `softfail` は、SPF レコードの末尾が `~all`（チルダ）の場合に出ます。「登録外の送信元だが、受信は拒否せず迷惑メール寄りに扱う」という弱い判定です。これに対し `fail` は末尾が `-all`（ハイフン）で、より明確に「不正な送信元」と扱われます。SPF の `~all` と `-all` の違いは [SPF の fail と softfail の違い](/blog/spf-fail-vs-softfail) で詳しく整理しています。

なお、SPF と DKIM では `pass` `fail` `none` `neutral` `temperror` `permerror` などが使われ、`softfail` は **SPF だけ** に存在します。DMARC で使われる結果値は `pass` `fail` `none` `temperror` `permerror` の 5 つで、こちらに `softfail` はありません（IANA の Email Authentication Result Names レジストリで定義）。

## 付帯情報（header.from / smtp.mailfrom / header.d）の意味

結果値の前後に並ぶ付帯情報は、「**どのドメインを根拠に判定したか**」を示します。ここを読むと、なぜその合否になったのかの理由までたどれます。

- **`smtp.mailfrom=bounce@example.co.jp`**：SPF が評価した送信元アドレス。封筒でいう差出人（Return-Path）にあたるドメインです
- **`header.d=example.co.jp`**（または `header.i=@example.co.jp`）：DKIM 署名を付けたドメイン。`header.s=` はそのときの「セレクタ（鍵を識別する名前）」です
- **`header.from=example.co.jp`**：DMARC が基準にする、メール本文に表示される From のドメイン

DMARC の合否は、この **`header.from` のドメインと、SPF / DKIM が認証したドメインが一致しているか**（アラインメントと呼びます）で決まります。SPF や DKIM が個別に pass でも、From のドメインと食い違っていると DMARC は fail になり得ます。仕組みの全体像は [DMARC とは？仕組みと SPF/DKIM 違いを 5 分解説](/blog/what-is-dmarc) を参照してください。

### 失敗している例を読んでみる

次は、SPF と DMARC が失敗しているケースです。

```
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of bounce@example.co.jp
            does not designate 198.51.100.7 as permitted sender)
            smtp.mailfrom=bounce@example.co.jp;
       dkim=none;
       dmarc=fail (p=NONE) header.from=example.co.jp
```

読み解くとこうなります。

- `spf=fail` … 送信元 IP `198.51.100.7` が SPF レコードに登録されていない。新しく使い始めた送信サービスの追加忘れ、または第三者によるなりすまし送信
- `dkim=none` … DKIM 署名が付いていない（DKIM 未設定、または署名が壊れて検出されなかった）
- `dmarc=fail` … SPF も DKIM も From ドメインと整合しなかったため、DMARC として失敗

自社の送信であれば、送信に使っているサービスの IP を SPF に追加し、DKIM 署名を有効にすれば pass に近づきます。

## Gmail・Outlook で認証結果を確認する手順

実際のメールでヘッダを開く手順は、サービスごとに少し違います。

![Gmail と Outlook での確認手順](/blog/authentication-results-yomikata/how-to-view.svg)

### Gmail（ブラウザ版）

1. 対象のメールを開く
2. 返信ボタンの右にある三点メニュー（⋮）をクリック
3. **「メッセージのソースを表示」**（英語表示では Show original）を選ぶ
4. 新しいタブが開き、上部の概要に SPF / DKIM / DMARC の合否、本文に Authentication-Results が表示されます

### Outlook（Web 版・新しい Outlook）

1. 対象のメールを開く
2. 三点メニューから **「表示」→「メッセージのソースを表示」**
3. 表示されたソースの中から `Authentication-Results` の行を探します

### Outlook（従来のデスクトップ版）

1. 対象のメールを開く
2. **「ファイル」→「プロパティ」**
3. **「インターネット ヘッダー」** のボックス内に Authentication-Results が含まれます

どのサービスでも、開いたソースの中から `Authentication-Results` という文字列を検索すれば、目的の行にすぐたどり着けます。

## よくある質問

### Authentication-Results が複数行ある場合はどう読みますか

中継サーバーが複数あると、Authentication-Results が複数付くことがあります。自分が **最終的に受信したサーバー**（先頭の authserv-id が自社・自分のメールサービスのもの）が付けた行を基準に読みます。途中の中継サーバーが付けた行は参考情報です。

### `spf=pass` なのに迷惑メールに入るのはなぜですか

SPF が pass でも、DKIM や DMARC が fail だと総合的に迷惑メール判定されることがあります。3 つの結果をそれぞれ確認し、fail や none になっている方式を順に直していくのが基本です。

### `dmarc=none` と `dmarc=fail` は何が違いますか

`none` は DMARC レコード自体が未設定（評価対象がない）状態、`fail` は DMARC レコードはあるが認証が整合しなかった状態です。`none` の場合はまず DMARC レコードの公開から始めます。

## まとめ

- Authentication-Results は「方式＝結果」が 3 つ並ぶだけと捉えると読みやすい
- pass / fail / none に加え、SPF の softfail（`~all`）と fail（`-all`）の差を押さえる
- `header.from` と SPF / DKIM のドメインの一致（アラインメント）が DMARC 合否を左右する

## まずは自社の認証状況を確認しましょう

受信メール 1 通の Authentication-Results を読めば「いま起きていること」がわかりますが、自社ドメインが **そもそも認証を通せる設定になっているか** は、送信前に把握しておくのが安全です。

[無料ドメイン診断](/diagnose) で、自社の SPF / DKIM / DMARC の設定状況をその場で確認できます。確認方法をもっと知りたい方は [SPF / DKIM / DMARC の確認方法は？4 つの手段を比較](/blog/spf-dkim-dmarc-check-how-to) も合わせてご覧ください。設定の切り分けに迷う場合は、お気軽にご相談ください。専門家がわかりやすくサポートいたします。