# Email Header Analyzer

> メールヘッダーを貼るか .eml／.msg を開くだけで、配送経路と遅延、SPF・DKIM・DMARC の結果を読み解き、DKIM 署名をブラウザ内で検証。本文は送信しません。

- URL: https://bytescope.dev/ja/email-header-analyzer/
- Locale: ja · Also: [en](https://bytescope.dev/en/email-header-analyzer.md) · [zh-Hant](https://bytescope.dev/zh-Hant/email-header-analyzer.md)
- Runs: ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
- Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile.
- Updated: 2026-09-08

## What it does

メールヘッダーを見たくなるのは、だいたい三つの場面です。このメールはなぜ二時間も遅れて届いたのか、銀行を名乗るこのメールは本物なのか、自分のメールはなぜ迷惑メールに入ったのか。手で読むのは骨が折れます。逆順に並んだ十数行の `Received`、タイムゾーンがばらばらの時刻、略語だらけの `Authentication-Results`。このメールヘッダー解析ツールはブラウザの中でヘッダーを分解し、メールが通った経路、各ホップでの待ち時間、受信サーバーが SPF・DKIM・DMARC についてどう判断したか、そして DKIM 署名が今日検証し直しても通るかを並べて見せます。アップロードはしません。ページが行う唯一の通信は DKIM 公開鍵の問い合わせで、それも「DKIM を検証」ボタンを押したときだけです。`selector._domainkey.ドメイン` という名前を公開の DNS-over-HTTPS サービス（Cloudflare、失敗時は Google）に送るので、そのサービスにはあなたの IP アドレスが見えます。DNS の問い合わせとはそういうものです。メール本文、宛先、ヘッダーそのものはどこにも送られません。

### 経路をたどって、どこで止まったかを見つける

`Received` ヘッダー一行が一ホップです。ページは古い順に並べ直し、各ホップを、名乗っている送信ホスト、括弧内の逆引き名と IP、受け取ったホスト、プロトコル（`SMTP`、`ESMTPS`、`ESMTPSA`、`LMTP` など）、時刻に分解します。プロトコルの文字は RFC 3848 に従って読み解き、`S` があれば TLS 接続、`A` があれば送信側が認証済みなので、途中で暗号化されていたかどうかが分かります。ホップの遅延は前のホップとの時刻差で、横棒グラフにして最も長いホップを赤く示します。遅れたメールはたいていそこで待たされています。負の遅延はエラー扱いにせず「時計のずれ」と表示します。メールサーバーの時計は合っていないことが多いからです。時刻がない、または読めないホップは「計算不可」として、後続のホップには影響させません。プライベートアドレス（RFC 1918、`127.*`、`::1`）は「内部転送」と印を付けます。IP アドレスは文字として表示するだけで、位置情報の照会はしません。それには IP を第三者の API に送る必要があるからです。

### Authentication-Results は、信じていい一行だけ信じる

`Authentication-Results`（RFC 8601）は受信サーバーが判断を書き残す場所で、`spf=pass`、`dkim=fail`、`dmarc=none` のほか、`arc`、`iprev`、`bimi` が付くこともあります。ページは各ヘッダーを authserv-id と方式ごとに分解し、結果ごとに平易な一文を添えます。`softfail`、`temperror`、`permerror`、`neutral` が実際に何を意味し、よくある原因は何か、という説明です。一覧の上には警告を一つ置いています。経路上のどのサーバーも、送信者自身も、`Authentication-Results` ヘッダーを追加できます。信用できるのはあなた自身の受信サーバーが書いた行だけで、途中のホップや送信者が書いた行は何の証明にもなりません。ARC ヘッダー（RFC 8617）はインスタンスごとにまとめて参考表示しますが、このバージョンでは ARC シールの検証は行いません。

### ブラウザで DKIM を検証する。使うのは今日の鍵

このページの売りは、誰かの結論を写すのではなく、本物の DKIM 検証（RFC 6376）を行うことです。`DKIM-Signature` ごとにタグを解析し、`s=` と `d=` が示す公開鍵を取得し、署名対象のヘッダーを `c=` の指定どおりに正規化して、WebCrypto で署名を確かめます。`h=` に列挙されているのにメールに存在しないヘッダーは、規格どおり空文字列として扱うので、署名後に追加されたヘッダーが通ることはありません。`rsa-sha256` は RSASSA-PKCS1-v1_5 で検証します。`ed25519-sha256`（RFC 8463）はブラウザの WebCrypto が Ed25519 に対応していれば検証し、対応していなければ失敗ではなく「検証不可」と報告します。`rsa-sha1` は検証はしますが RFC 8301 で非推奨であることを示し、1024 ビット未満の RSA 鍵は同じ RFC の規定どおり拒否します。結論は四つのうちどれかです。通過、失敗（理由付き。鍵が見つからない、`p=` が空で鍵が失効済み、`x=` の期限切れ、署名不一致、本文ハッシュ不一致、鍵が短すぎる）、検証不可（DNS エラー、未対応のアルゴリズム、本文がない）、形式エラー。`l=` のある署名には、本文の先頭 N バイトしか署名されておらず、その後ろに付け足された内容は署名外だという警告を出します。取得する鍵は今公開されている鍵だということも忘れないでください。送信後に鍵が交換されていれば古いメールは検証に失敗しますが、偽物だからではありません。

### ヘッダーだけ、.eml、.msg で、どこまで検証できるか

本文ハッシュ `bh=` を確かめられるのは、完全な `.eml` ファイルを入れたときだけです。本文の生のバイト列が必要だからです。ヘッダーだけを貼った場合でも、ヘッダー署名（`bh=` の値を含む）は検証できるので、「ヘッダーは改ざんされていない、本文は検証できない」という結論になります。`.msg` は常にこの状態です。受信したメールの `.msg` はトランスポートヘッダーをプロパティとして保存しますが元の MIME 本文は残さず、送信前に保存した `.msg` にはトランスポートヘッダー自体がないため、`.msg` の検証はヘッダー止まりです。EML ビューアーと MSG ビューアーからはワンクリックでこのページにメールを渡せます。受け渡しは sessionStorage 経由で、URL には乗せません。概要カードには送信者の三つの身元、`From` のドメイン、`Return-Path` のドメイン、DKIM の `d=` のドメインを並べ、DMARC の整合は RFC 7489 の relaxed モードで組織ドメインを基準に判定します。隣のボタンで `From` ドメインをメール DNS チェックのページに渡し、SPF・DKIM・DMARC の設定を確認できます。URL に入るのはそのドメインだけで、これは公開情報です。

### このページが言わないこと

「このメールは安全」「本物」とは決して言いません。どの検査が通り、どれが失敗したかを言うだけです。DKIM が通っても、証明されるのは `d=` のドメインがこのメールに署名したことだけで、そのドメインがあなたの思う会社のものかどうかは別問題です。SPF は再検証しません。SPF はメールを受け渡した IP とその時点の DNS に依存するので、後からブラウザで実行し直しても意味がなく、受信サーバーが記録した結果を表示するにとどめます。転送されたメール、メーリングリストを経由したメール、会社のメールゲートウェイに書き換えられたメールで DKIM が失敗するのはよくあることで、失敗の説明にもそう書きます。`X-Spam-Status` や `X-Microsoft-Antispam` のような迷惑メール判定ヘッダーは、形式が公開されていないので原文のまま表示し、解釈はしません。Markdown レポートと JSON 出力は宛先アドレスを既定で伏せるので、そのまま共有できます。

## Limits

Does not re-check SPF, look up IP locations or say whether a message is safe; it reads the headers and verifies DKIM signatures locally.

## FAQ

### 自分のメールはなぜ迷惑メールに入ったのですか？

ヘッダーで分かるのは答えの一部です。まず、あなたの受信サーバーが書いた一番上の `Authentication-Results` を見てください。そこに `dkim=fail`、`spf=softfail`、`dmarc=fail` があるか、`From` ドメインが DKIM の `d=` や `Return-Path` のドメインと整合していなければ、迷惑メール行きの十分な理由です。`X-Spam-Status` のような判定ヘッダーも原文のまま並べます。ヘッダーからは分からないのが送信者の評判、本文の内容、送信量で、フィルターはこれらを重く見ます。送信者側なら、メール DNS チェックのページでドメインの SPF・DKIM・DMARC を確認してください。概要カードから直接飛べます。

### 銀行を名乗るメールが本物かどうか、どう見分けますか？

概要カードの三つの身元、受信者に見える `From` ドメイン、`Return-Path` ドメイン、DKIM の `d=` ドメインを見比べ、「DKIM を検証」を押してください。署名が有効なら、`d=` のドメインを管理する者がこのメールに署名し、署名されたヘッダーはその後変更されていないことが分かります。だからこそ `d=` が本当に銀行のドメインで、似せた別ドメインではないかを確かめてください。`Authentication-Results` は途中で追加されたものではなく、あなた自身の受信サーバーの行を読んでください。このページは意図的に「安全」とは言わず、どの検査が通ったかだけを報告します。迷ったら、すでに信頼している連絡手段で銀行に確認してください。

### 本物のメールなのに DKIM が失敗するのはなぜ？

よくある理由は三つです。一つ目、メールが転送された、メーリングリストを通った、会社のメールゲートウェイに書き換えられた。署名対象のヘッダーや本文（件名のタグ、末尾の署名文）が一文字でも変われば署名は壊れ、これは正常な現象です。二つ目、送信後に送信者が DKIM 鍵を交換した。検証に使うのは今日 DNS に載っている鍵なので、古いメールは偽物でなくても失敗します。三つ目、コピーの途中でメールが壊れた。改行や行末の空白が落ちた貼り付けテキストは一致しません。失敗とは「今は検証が通らない」という意味で、それだけで偽造の証明にはなりません。

### メールが遅れた原因と、止まった場所はどこで分かりますか？

経路の表示まで下にスクロールしてください。`Received` の各ホップに、前のホップからの遅延が横棒で表示され、一番長い棒が赤くなります。そのホップで待たされていたわけで、たいていは `by` に書かれた受信ホストのキューです。負の遅延は時間が逆行したのではなく二台のサーバーの時計がずれているという意味で、使える時刻のないホップは「計算不可」と表示され、その後ろのホップには影響しません。

### このページはネットワークに何を送りますか？

「DKIM を検証」を押すまでは何も送りません。押すと、署名ごとに `selector._domainkey.ドメイン` の DNS 問い合わせを一回、Cloudflare の DNS-over-HTTPS サービスに送り、失敗したら Google のサービスに切り替えます。これらのサービスには、問い合わせた名前とあなたの IP アドレスが見えます。どの DNS リゾルバーでも同じです。メール、ヘッダー、宛先、検証結果は、このサイトを含めて誰にも送られません。ネットワークがなくても経路と Authentication-Results は表示され、DKIM は DNS エラーになります。

### ヘッダーだけ、または .msg ファイルでも DKIM を検証できますか？

一部はできます。DKIM 署名が守っているのは二つ、選ばれたヘッダーと、`bh=` に入った本文のハッシュです。ヘッダーだけでもヘッダー署名は検証できるので、`bh=` の値を含めてヘッダーが無傷だと分かります。本文そのものは手元にないので確かめられません。Outlook の `.msg` はトランスポートヘッダーは保持しますが元の MIME 本文は持たないので、`.msg` は常にこの「ヘッダーのみ」の結論になります。本文まで確かめたいときは、元の `.eml` をドロップしてください。

### SPF を再検証しないのはなぜですか？

SPF は後から実行し直せないからです。SPF が問うのは、メールをあなたのサーバーに渡した IP アドレスが、その時点の DNS レコード上で `Return-Path` ドメインの送信を許可されていたかどうかです。後からブラウザで検査すれば IP は別物で、レコードも変わっているかもしれず、答えに意味がありません。だからページは受信サーバーが `Authentication-Results` に記録した SPF の結果を表示します。DKIM は違います。署名はメールと一緒に運ばれ、鍵を取得した誰でも検証できるので、ページ自身が検証します。

### Authentication-Results が複数あるとき、どれを信じればいいですか？

あなた自身の受信サーバーが書いた行だけです。普通は一番上にあり、authserv-id にはあなたのメールプロバイダーのホスト名が入っています。経路上のどのサーバーも、送信者も、`dkim=pass` と書いた `Authentication-Results` を挿入できますし、偽造者にはそうする動機があります。ページは各行の authserv-id を表示して見分けられるようにし、一覧の上でもこの警告を繰り返します。ARC ヘッダーは参考として表示しますが、このバージョンでは検証しません。

## Related tools

- [Email DNS Check](https://bytescope.dev/ja/email-dns-check.md) — ドメインの SPF・DKIM・DMARC・MX・MTA-STS レコードを確認 →
- [EML Viewer](https://bytescope.dev/ja/eml-viewer.md) — .eml メールを開く：ヘッダー、本文、添付ファイル →
- [MSG Viewer](https://bytescope.dev/ja/msg-viewer.md) — Outlook なしで .msg ファイルを開く →