届いたはずのメールが迷惑メールのフォルダに入っていたり、送ってから届くまでに何分もかかったりすることがあります。
そうしたときの手がかりは、メールの「ヘッダー」に残っています。
ヘッダーには、どのサーバーを通って届いたかと、受け取った側がどう判定したかが書かれています。
この記事では、ヘッダーの取り出し方と、見るべき場所、貼るだけで読み解く方法を紹介します。
この記事で使うメールヘッダー解析は、当サイトと同じMOTOKI合同会社が作った「WEBツール箱」の1つです。
無料で、会員登録なしで使えます。
最終確認日：2026年9月28日
この記事で分かること
- Gmail・Outlook・Apple Mailでのヘッダーの取り出し方
- ヘッダーで最初に見る3か所
- SPF・DKIM・DMARCの判定の読み方
- Receivedの行から、どこで配送が遅れたかを見つける方法
- 迷惑メールに入る原因の切り分け方
答え｜見るのは3か所だけ
ヘッダーは長く、慣れないと読む気になれない量があります。
ただ、原因を探すときに見る場所は限られています。
| 見る場所 | 分かること |
|---|---|
| Authentication-Results | 受け取った側のサーバーが、SPF・DKIM・DMARCをどう判定したか |
| Received（下から上へ） | どのサーバーを通ったかと、それぞれの時刻 |
| From と Return-Path | 見た目の送り主と、実際に送ったドメインが同じかどうか |
この3か所を読めれば、「なりすましと疑われた」のか「途中で止まっていた」のかを切り分けられます。
ヘッダーの取り出し方
| メールソフト | 操作 |
|---|---|
| Gmail | メールを開き、右上の「︙」→「メッセージのソースを表示」 |
| Outlook | メールを開き、「ファイル」→「プロパティ」→「インターネットヘッダー」 |
| Apple Mail | 「表示」→「メッセージ」→「すべてのヘッダ」 |
Gmailの「メッセージのソースを表示」では、ヘッダーと本文がまとめて出ます。
解析に必要なヘッダーだけを使い、本文は貼り付けないでください。実メールを共有する場合は、メールアドレス・Message-ID・IPアドレスなどの公開範囲も確認します。この記事の架空サンプルで先に操作を試せます。
ツールで解析する｜貼って「解析する」を押す
- メールヘッダー解析を開く
- 取り出したヘッダーを入力欄に貼る
- 「解析する」を押す
ここからは、説明用に作った例で読み方を見ていきます。
実在する人のメールではなく、ドメインは例示用の example.com などを、IPアドレスは説明用に取っておかれた番号を使っています。
メール配信サービス（example.net）を通して、お店（example.com）がお知らせを送った、という想定です。
Delivered-To: user@example.org
Received: from mx1.example.org
(mx1.example.org [203.0.113.5])
by mail.example.org with ESMTP
id B2c4; Mon, 28 Sep 2026
10:05:14 +0900
Received: from out.example.net
(out.example.net [198.51.100.20])
by mx1.example.org with ESMTPS
id A1b3; Mon, 28 Sep 2026
10:05:12 +0900
Received: from app.example.net
(app.example.net [192.0.2.10])
by out.example.net with ESMTP
id Q9z1; Mon, 28 Sep 2026
10:01:02 +0900
Received: from localhost
by app.example.net with ESMTP
id L0a0; Mon, 28 Sep 2026
10:01:00 +0900
Authentication-Results:
mx1.example.org;
spf=pass
smtp.mailfrom=bounce.example.net;
dkim=pass header.d=example.com
header.s=s1;
dmarc=pass header.from=example.com
Return-Path:
<bounce-7f3a@bounce.example.net>
DKIM-Signature: v=1; a=rsa-sha256;
d=example.com; s=s1;
h=from:to:subject:date;
bh=（省略）; b=（省略）
From: =?UTF-8?B?44K144Oz44OX44Or5ZWG5bqX?=
<info@example.com>
To: user@example.org
Subject: =?UTF-8?B?MTDmnIjjga7lrprkvJHml6U=?=
Date: Mon, 28 Sep 2026 10:01:00 +0900
Message-ID:
<20260928100100.q9z1@app.example.net>
List-Unsubscribe:
<https://example.com/unsubscribe>このヘッダーは、上の枠からそのままコピーしてツールで試せます。
ヘッダーでは、行の頭に空白があると前の行の続きという決まりなので、長い行は折り返して載せています。
解析した結果です。
SPF・DKIM・DMARCはすべて「pass」で、「認証はすべて通過しています」と出ました。
件名とFromの名前は、ヘッダーの中では記号の並びになっていますが、ツールが日本語に戻して「10月の定休日」「サンプル商店」と表示しています。
配送経路の表を見ると、中継したサーバーは4台でした。
3行目の、out.example.net から mx1.example.org へ渡ったところだけ、「前からの経過」が250秒になっています。
Receivedの時刻差は遅延箇所を探す手掛かりです。ただしサーバーの時計ずれや信頼できない行があり、差だけで原因を断定せず配送ログと照合します。
FromとReturn-Pathのドメインが違うという注意
結果には「From と Return-Path のドメインが異なります」という注意も出ています。
見た目の送り主は example.com ですが、実際に送ったのは配信サービスの bounce.example.net だからです。
SPFが確かめるのは、Return-Pathのほうのドメインです。
DMARCは、SPFかDKIMのどちらかが「passで、しかもFromのドメインと一致している」ことを求めます。
この例では、DKIMの署名が example.com（header.d=example.com）で付いているので、DMARCも通りました。
配信サービスを使うときにDKIMの設定が欠かせないのは、このためです。
DKIMがなくても、SPFがpassし、その認証ドメインがFromドメインと整合すればDMARCは合格します。SPFがpassしただけでは、整合しているかは分かりません。
認証に失敗している例｜転送されたメール
もう1つ、説明用に作った例です。
example.com から送られたメールが、途中の fwd.example.net で転送されてから届いた、という想定です。
Received: from fwd.example.net
(fwd.example.net [198.51.100.40])
by mx1.example.org with ESMTPS
id C7d2; Mon, 28 Sep 2026
11:00:30 +0900
Received: from mail.example.com
(mail.example.com [192.0.2.25])
by fwd.example.net with ESMTP
id F1e8; Mon, 28 Sep 2026
11:00:02 +0900
Authentication-Results:
mx1.example.org;
spf=softfail
smtp.mailfrom=example.com;
dkim=none;
dmarc=fail header.from=example.com
Return-Path: <info@example.com>
From: info@example.com
To: user@example.org
Subject: test
Date: Mon, 28 Sep 2026 11:00:00 +0900
SPFは「softfail」、DKIMは「none」、DMARCは「fail」で、「DMARC認証に失敗しています」と出ました。
転送では接続元が転送サーバーになるため、元のエンベロープ送信者を使ったSPFが失敗することがあります。転送方式によって結果は異なり、必ず失敗するわけではありません。
転送後もDKIM署名の検証に成功し、署名ドメインがFromと整合すればDMARCは合格できます。この例はSPFがsoftfailでDKIMもnoneのため、合格条件を満たしません。
受け取る側がDMARCの設定に従うと、このメールは迷惑メールに入ったり、受け取りを断られたりします。
送信側ではFromと整合するDKIM署名を設定します。ただし転送途中の本文や署名対象ヘッダーの変更によって検証に失敗する場合があり、転送後の合格を保証するものではありません。
手で読むときのコツ
- Receivedは下から上へ、古い順に積み重なっている
- Authentication-Resultsは位置だけで信用せず、自分の受信サービスが信頼する認証サーバーの結果を確認する。外部から付けられた同名ヘッダーは偽装できる
- 時刻の末尾の +0900 は日本時間、+0000 は世界標準時を表す
- Fromの名前や件名が「=?UTF-8?B?」で始まるのは、日本語を記号に置き換えて送っているため
サーバーごとに時計が少しずれていることもあるので、数秒の差は気にしなくて構いません。
見るべきなのは、分単位以上の大きな差です。
送る側の設定と見比べる
ヘッダーで分かるのは、実際に届いたメールで何が起きたかです。
送る側のDNSの設定が正しいかどうかは、メール認証（SPF・DKIM・DMARC）診断で確かめます。
解析結果のいちばん下にある「送信側のDNS設定を確認する」から、そのまま移れます。
SPF・DKIM・DMARCの確かめ方と直し方は、「SPF・DKIM・DMARCの確認方法」にまとめています。
ヘッダーの「DKIM-Signature」の行にある「s=」の値（この例では s1）が、DNSでDKIMを探すときのセレクタです。
ツールの限界
- 判定は、受け取った側のサーバーが書いた結果を読むだけで、ツールが改めて検査するわけではない
- Authentication-Resultsが無いヘッダーでは、判定は「不明」になる
- 迷惑メールに入った理由が本文の内容や送り主の評判にある場合は、ヘッダーからは分からない
- 時刻はヘッダーに書かれたものなので、サーバーの時計がずれていると経過時間もずれる
認証がすべて通っているのに迷惑メールに入る場合は、ツールも「原因は認証以外にある可能性が高い」と表示します。
よくある質問
Q. 仕事のメールのヘッダーを貼っても大丈夫ですか？
このツールは、貼った内容をサーバーに送らず、ブラウザーの中だけで解析します。
通信が起きないので、ヘッダーに含まれるアドレスが外に出ることはありません。
Q. Receivedの行が多いのは問題ですか？
数そのものは問題ではありません。
社内のサーバーやウイルス検査を通るたびに1行ずつ増えるので、10行を超えることもあります。
見るべきなのは、行と行の間の時間の差です。
Q. SPFがpassなのに迷惑メールに入ります
SPFがpassでも、Return-PathのドメインがFromと違えば、DMARCは失敗することがあります。
まずAuthentication-Resultsの「dmarc=」の値を確かめてください。
信頼する受信サーバーの結果がdmarc=passなら、本文、送信元の評判、受信者側のルールなども調べます。認証合格は受信箱への配達を保証しません。
まとめ
- ヘッダーで最初に見るのは、Authentication-Results・Received・FromとReturn-Pathの3か所
- Receivedは下から上へ読み、時刻の差が大きい行で配送が遅れている
- 配信サービスではSPFまたはDKIMの合格に加え、Fromとのドメイン整合を確認する
- 転送でSPFが失敗しても、Fromと整合するDKIMが有効ならDMARCは合格できる
- メールヘッダー解析なら、貼るだけで判定と経路を一覧にできる
WordPressのお問い合わせメールが届かないときは、「お問い合わせメールが届かない・迷惑メールに届く場合の設定方法」もあわせてご覧ください。
ほかの項目もまとめて点検するなら、「WordPressサイトを自分で点検する手順」で順番と使い分けを解説しています。
ツールの一覧はWEBツール箱にあります。
