.emlファイルを解析し、ヘッダー、Receivedチェーン、リンク、添付ファイルのハッシュ、送信者の不一致を表示します。
新着
メールヘッダー解析
ローカルで動作
ツール自体は英語ですが、このページではお客様の言語でその使い方を説明しています。
メールヘッダー解析 を使用してください
機能の説明
不審なメッセージの生のヘッダーを貼り付けると、「From」、「To」、「Date」、「Subject」、受信サーバーが記録したSPF、DKIM、DMARCの結果、古い順に並んだすべての「Received」ホップ、および「Reply-To」や「Return-Path」を含むすべてのヘッダーの一覧が表示されます。
すべてブラウザ上で動作します。入力した内容は一切アップロードされません。
メールヘッダー解析 の使い方
- ヘッダーをコピーする. メッセージのソースを開き（GmailのShow original、OutlookのView message source、ThunderbirdのView source）、最初の空行までのヘッダー行をコピーします。
- 貼り付けて解析する. それらを「Raw email headers」に貼り付けて、「Parse」をクリックしてください。本文も貼り付けてしまうと、パーサーは最初の空白行で処理を停止し、読み取れなかった行数を表示します。
- 上部の欄を読む. 最初にFrom、To、Dateが表示され、Subjectがある場合はその次に表示されます。値はデコードせず、書かれたとおりに表示されます。
- 認証結果を確認する. SPF、DKIM、DMARCについては、受信サーバーが最上位の「Authentication-Results」ヘッダーに記述した結果（サーバー名を含む）が表示されます。ここでは再検証は行われません。
- ホップの軌跡をたどる. 受信したホップは、EML Analyzerと同様に古い順に一覧表示されます。ホップ 1 は送信者に最も近く、最後のホップはメッセージをあなたに配信したサーバーによって追加されたものです。
- 表全体をスキャンする. 「All headers」には、Reply-To や Return-Path を含むすべてのヘッダーが一覧表示されます。「Send to」は、解析結果を、例えば EML Analyzer などに転送します。
例
なりすました銀行からの通知
Return-Path: <bounce@mailer.example.net>
Received: from mail.example.net (mail.example.net [203.0.113.25])
by mx.example.com with ESMTPS id 4Xk2Lm; Mon, 19 Oct 2026 09:14:07 +0000
Received: from [198.51.100.10] (unknown [198.51.100.10])
by mail.example.net with ESMTPSA id 77QaZ1; Mon, 19 Oct 2026 09:14:05 +0000
Authentication-Results: mx.example.com; spf=pass smtp.mailfrom=mailer.example.net; dkim=none; dmarc=fail (p=reject) header.from=example.org
From: "Example Bank Security" <security@example.org>
Reply-To: <help-desk@example.net>
To: <alice@example.com>
Subject: Action required: verify your account
Date: Mon, 19 Oct 2026 09:14:03 +0000
Message-ID: <20261019091403.1234@mail.example.net>FROM
"Example Bank Security" <security@example.org>
TO
<alice@example.com>
DATE
Mon, 19 Oct 2026 09:14:03 +0000
SUBJECT
Action required: verify your account
Authentication-Results by mx.example.com (as written by that server, not verified here)
SPF
pass
DKIM
none
DMARC
fail
Received hops (2, oldest first)
HOP 1 · OLDEST, NEAREST THE SENDER
from [198.51.100.10] (unknown [198.51.100.10]) by mail.example.net with ESMTPSA id 77QaZ1; Mon, 19 Oct 2026 09:14:05 +0000
HOP 2 · NEWEST, ADDED BY THE RECEIVING SERVER
from mail.example.net (mail.example.net [203.0.113.25]) by mx.example.com with ESMTPS id 4Xk2Lm; Mon, 19 Oct 2026 09:14:07 +0000
All headers (10)
Return-Path <bounce@mailer.example.net>
Received from mail.example.net (mail.example.net [203.0.113.25]) by mx.example.com with ESMTPS id 4Xk2Lm; Mon, 19 Oct 2026 09:14:07 +0000
Received from [198.51.100.10] (unknown [198.51.100.10]) by mail.example.net with ESMTPSA id 77QaZ1; Mon, 19 Oct 2026 09:14:05 +0000
Authentication-Results mx.example.com; spf=pass smtp.mailfrom=mailer.example.net; dkim=none; dmarc=fail (p=reject) header.from=example.org
From "Example Bank Security" <security@example.org>
Reply-To <help-desk@example.net>
To <alice@example.com>
Subject Action required: verify your account
Date Mon, 19 Oct 2026 09:14:03 +0000
Message-ID <20261019091403.1234@mail.example.net>上部のフィールドには、送信者の表示名とアドレス、続いて受信サーバーが記録した認証結果（spf=pass、dkim=none、dmarc=fail）、そしてEML Analyzerと同様に古い順に並んだ2つの「Received」ホップが表示されます： ホップ1では、mail.example.netが198.51.100.10からのメッセージを受け入れ、ホップ2では、mx.example.comがmail.example.netからのメッセージを受け入れています。 10個のヘッダーすべてを含む表には、別のドメインの「Reply-To」が示されています。これに加え、dmarc=failという結果から、送信者がなりすまされていることを示す2つの兆候が確認できます。
チェック対象
| シグナル | その意味 |
|---|---|
| From | 表示名と山かっこ内のアドレスを比べてください。無関係なドメインの横にブランド名がある場合は、なりすましのよくある兆候です。 |
| To | 自分のアドレスがない場合は、Bccで送られたか、メーリングリスト経由である可能性があります。大量のフィッシングではBccがよく使われます。 |
| Date | 送信者のソフトウェアが書き込むため、偽装できます。Receivedホップの時刻と比べてください。 |
| Subject | 生のまま表示されます。=?UTF-8?B?...?=のような値はエンコードされたテキストで、このパーサーではデコードされません。 |
| SPF、DKIM、DMARC | 受信サーバーの判定結果。ブランドのドメインに対して「dmarc=fail」と表示される場合は、なりすましの強い兆候です。報告がない場合は、そのチェックについてサーバーが結果を記録しなかったことを意味します。 |
| ホップの受領 | 各ホップは200文字に切り詰められます。リストの最後にある、ご自身のプロバイダによって追加されたホップのみが信頼でき、それより前のホップは偽造されている可能性があります。 |
| 返信先 | 「From」とは異なるドメインの返信先アドレスが指定されている場合、返信は別の宛先に送られてしまいます。 |
| Return-Path | SPFが確認するバウンス先アドレス。「From」とは異なるドメインが指定されるのはメールサービスでは一般的ですが、留意しておく価値があります。 |
| Message-ID | @より後の部分は、多くの場合メッセージを作成したシステムを示します。Fromのドメインと比べてください。 |
その他の例
エンコードされた送信者名と件名
Received: from mail.example.org (mail.example.org [192.0.2.44])
by mx.example.com with ESMTPS; Tue, 20 Oct 2026 10:02:11 +0000
From: =?UTF-8?B?UGF5cm9sbCBUZWFt?= <payroll@example.org>
To: staff@example.com
Subject: =?UTF-8?B?U2FsYXJ5IHVwZGF0ZQ==?=
Date: Tue, 20 Oct 2026 10:02:09 +0000「From」、「To」、「Date」、「Subject」は入力されていますが、名前と件名はデコードされていないため「=?UTF-8?B?...?=」のままです（実際には「Payroll Team」と「Salary update」と表示されています）。「Received hops」には折りたたまれたホップが1行にまとめられ、「All headers」にはすべてのヘッダーが一覧表示されます。
ヘッダーと一緒に本文を貼り付けた場合
From: IT Support <it@example.net>
To: you@example.com
Subject: Password expires
Hello,
Action needed: confirm your password today.最初の空白行より前の行のみがヘッダーとして読み込まれます。表の下にある注記によると、その後の行、つまりメッセージ本文はヘッダーとして読み込まれなかったとのことです。
折り返されたSubject行
From: Example Shop <orders@example.com>
Subject: Your order
has shippedFromにはExample Shopとアドレスorders@example.comが表示され、ToとDateにはダッシュが表示されます。Subjectは1行で「Your order has shipped」となります。Received hops (0)、All headers (2)です。
よくある質問
Receivedホップはどのように読みますか？
ホップは、EML Analyzer と同様に、最も古いものから順に番号が付けられます。ホップ 1 は、メッセージを最初に処理したサーバーによって追加された最下位の「Received」ヘッダーであり、最後のホップは、メッセージをあなたに配信したサーバーによって追加された最上位の「Received」ヘッダーです。 信頼できるのは、自身のメールプロバイダによって追加されたホップのみです。なぜなら、送信者はそれより下にある「Received」行を偽造できるからです。
SPF、DKIM、DMARCを検証しますか？
いいえ。これは、最上位の Authentication-Results ヘッダーからの SPF、DKIM、DMARC の結果を表示するものであり、受信サーバーが記述したままの Received-SPF および DKIM-Signature を一覧表示しています。検証は一切行わず、=?UTF-8?B?...?= といった件名をデコードしたり、本文を読み込んだりすることなく（最初の空白行で処理を終了します）、長い値は短縮されます（ホップ数は200文字、表のセルは300文字に短縮されます）。完全な.emlファイルについては、EML Analyzerをご利用ください。
ヘッダーはアップロードされますか？
いいえ。解析はブラウザ内で行われ、何も送信されません。ヘッダーには個人のアドレスや内部IPが含まれることがあるため、共有する前にそれらを削除してください。
本文を含むメッセージ全体を貼り付けてもよいですか？
はい、ただし読み込まれるのはヘッダーブロックのみです。RFC 5322で定義されている通り、解析は最初の空白行で停止し、ページにはスキップされた本文の行数が表示されます。EML Analyzerは、添付ファイルを含め、メッセージ全体を読み込みます。
折り返されたヘッダー行はどうなりますか？
空白またはタブで始まる行は、1つの空白を挟んで上のヘッダーにつなげられます。そのため、長いReceivedやSubjectのヘッダーも1つの値として表示されます。
どの「Authentication-Results」ヘッダーが使用されますか？
一番上にあるものは、メッセージをあなたに配信したサーバーが最後に追加したものです。その下の「Authentication-Results」ヘッダーは、それより前のサーバーから送信されたもの、あるいは送信者によって偽造されたものである可能性があります。