メールヘッダー解析

このツールでできること

メッセージを扱うメールサーバーは、それぞれヘッダーの先頭に行を加えていき、最後に受け取ったサーバーは、送信者が検査に合格したかどうかを記録します。その結果、ヘッダーは折り返された長いテキストになり、目で追うのはひと苦労です。この解析ツールはメール1通分の生ヘッダーを読み取り、次の5つに整理します。

• 概要：From、To、Subject、Date、Message-ID、Return-Path、Reply-To。
• 認証：Authentication-ResultsヘッダーとReceived-SPFヘッダーから読み取ったSPF・DKIM・DMARCの判定（pass、fail、noneなど）と、各DKIM-Signatureヘッダーのドメイン（d=）とセレクター（s=）。
• アライメント：FromのドメインがDKIMのd=のドメインやReturn-Pathのドメインと一致するかどうか。
• Receivedの経路：古い順に番号を付けた各ホップと、その送信元（from）と受信側（by）のホスト、プロトコル（ESMTPSなど）、タイムスタンプ、前のホップからの遅延、そして配送にかかった合計時間。
• 警告：Fromと異なるReply-To、タイムスタンプの順序が乱れたホップや時計のずれ、認証結果の欠落。

解析はブラウザ上のJavaScriptが行います。何かがアップロードされたり送信されたりすることはなく、ページを一度読み込めば、回線を切った状態でも引き続き使えます。このツールはDKIM署名を暗号的に検証したりDNSに問い合わせたりはせず、受信サーバーがヘッダーに書き込んだ内容を報告します。

使い方

1. メールの生のソースを開きます。Gmailでは、返信アイコンの横にある「その他」アイコン（縦に並んだ3つの点）をクリックし、「メッセージのソースを表示」を選びます。Windows版のクラシックOutlookでは、メールをダブルクリックして別のウィンドウで開き、「ファイル」＞「プロパティ」を選んで、「インターネット ヘッダー」ボックスの内容をコピーします。Outlook on the webと新しいOutlookでは、メッセージ上部の「その他のアクション」（3つの点）から「表示」＞「メッセージの詳細を表示する」を選びます。Apple Mail（Macの「メール」）では、メニューバーの「表示」＞「メッセージ」と進み、メールのソースをそのまま表示する項目を選びます。
2. ヘッダー部分をコピーします。最初の空行までがヘッダーで、その下の本文は必要ありません。
3. このページの入力欄に貼り付けます。
4. 概要と認証結果を読み、次に警告、最後にホップの一覧を確認します。

メールを転送すると元のヘッダーは失われます。受信したメールボックスにある元のメールで作業するか、受信者に添付ファイルとして転送してもらってください。

こんなときに

• 怪しいメールを確かめる。取引先を名乗る支払い依頼のメールに、dmarc=fail、Fromのドメインと無関係なDKIMのd=ドメイン、Fromと違うReply-Toが見つかったとします。返信せずに報告するには、それで十分です。
• 遅延がどこで起きたかを突き止める。パスワード再設定のメールが40分遅れて届いたとします。ほとんどのホップは1〜2秒で済んでいるのに、1つの中継サーバーが38分抱えていたなら、どこのキューについて問い合わせればよいかがわかります。
• 自分のドメインをテストする。メールマガジンの配信サービスをつないだ後、自分宛てにテストメールを送り、SPFとDKIMがpassしていること、d=がサービスの共用ドメインではなく自分のドメインになっているかを見ます。
• ログでメッセージを追跡する。メール管理者に、Message-IDと、利用しているメールサービスがメールを受け付けた時刻を伝えます。どちらも配送ログで検索できます。
• 経路上の暗号化を確認する。ホップにESMTPSとあれば、その区間はTLSを使っています。ESMTPやSMTPだけなら使っていません。

Receivedの経路の読み方と、偽造できるもの

各サーバーは自分のReceived行を既存の行の上に加えるので、最新のホップがいちばん上に来ます。下から上へ読むと、メッセージの動きを時間の順に追えます。このツールは順序を逆にして表示します。

Received: from mx-out.shop.example (mx-out.shop.example [198.51.100.25])
        by mx1.recipient.example with ESMTPS id 4f2ac81e
        for <you@recipient.example>; Tue, 6 Oct 2026 14:02:11 +0000
Received: from app01.internal (app01.internal [10.0.4.7])
        by mx-out.shop.example with ESMTP id 91c0d3;
        Tue, 6 Oct 2026 14:02:09 +0000

信頼できるかどうかは、各行を誰が書いたかで決まります。自分が利用しているメールサービスが加えた、いちばん古いホップを探してください。この例ではmx1.recipient.exampleが記録した行です。その行とそれ以降の行は信頼でき、その行の角かっこ内のIPアドレスが、実際にメッセージを引き渡したマシンです。それより前に記録されたもの、つまり生のテキストではその行より下にあるものは送信者側から来ており、別の送信元を装う偽のReceived行も含めて、でっち上げることができます。From、Reply-To、Subject、Date、Message-IDも送信者が設定するものです。

各タイムスタンプは、そのサーバー自身の時計によるものです。遅延がマイナス数秒になっている場合は、たいていどれかの時計がわずかにずれているだけです。長い空白は、キューでの待機、一時的な拒否の後の再送、スキャンのための保留などを示しています。

SPF・DKIM・DMARCがそれぞれ証明すること

SPFは、接続してきたIPアドレスを、ドメインがDNSに載せている送信サーバーと照合します。検査されるのはエンベロープの送信者（のちにReturn-Pathになるもの）のドメインで、画面に表示されるFromではありません。passが証明するのは、このサーバーがReturn-Pathのドメインの名義で送信してよい、ということだけです。転送サーバーはその一覧に入っていないので、転送するとSPFはよく失敗します。

DKIMは、本文と選ばれたヘッダーに対する署名です。d=は署名したドメインを、s=は公開鍵を探すためのセレクターを示します。passは、署名された部分が改変されておらず、d=のドメインがそれを保証したことを意味します。ドメインが一致しない限り、Fromについては何も示しません。

DMARCは、この2つの検査を、読み手に見えるアドレスに結び付けます。SPFかDKIMがpassし、かつpassしたドメインがFromのドメインとアライメントがとれているときにpassになります。大量配信の業者が自社のドメインでSPFとDKIMにpassしていても、From欄に銀行の名前が書かれていれば、DMARCはpassになりません。

Authentication-Results: mx1.recipient.example;
       dkim=pass header.d=shop.example header.s=s2026;
       spf=pass smtp.mailfrom=bounce.shop.example;
       dmarc=pass header.from=shop.example

DMARCの標準である緩和（relaxed）モードでは、bounce.shop.exampleとshop.exampleは組織ドメインが同じなので、アライメントがとれているとみなされます。このヘッダーの最初の名前が、自分が利用しているメールサービスのサーバーであることを確かめてください。送信者は偽のAuthentication-Results行を差し込むことができ、慎重な受信サーバーはそうした行を取り除きます。

最後に、表示名の奥にあるアドレスを見てください。PayDesk Billing <billing@paydesk-help.example>の場合、ほとんどのメールアプリは親しみやすい表示名しか見せませんが、ここまでの検査が対象にしているのはアドレスのほうです。

よくいただく質問

この解析は、受信サーバーがヘッダーに書き込んだ内容をなぞり、簡単な経験則を当てはめたものです。誰が送ったかを証明することはできません。お金や認証情報が絡むときは、以前から信頼している別の連絡手段で確認してください。