# メールヘッダー解析 メール1通分の生のヘッダーを貼り付けると、誰が送ったか、SPF・DKIM・DMARCがpassしたか、途中の各サーバーがどれだけメールを抱えていたかがわかります。ヘッダーはブラウザで解析し、アップロードはしません。 ## 要点 メッセージを扱うメールサーバーは、それぞれヘッダーの先頭にReceived行を加えます（RFC 5321の4.4節）。そのため経路は下から上へ読み、いちばん下の行が最初のホップです。受信サーバーはSPF・DKIM・DMARCの検査結果をAuthentication-Results（RFC 8601）に記録します。DMARCがpassになるのは、Fromアドレスとアライメントのとれたドメインで、SPFかDKIMがpassしたときです（RFC 9989。2026年5月にRFC 7489を置き換えました）。 ### 調べ方 貼り付けたテキストの折り返しを解除し（継続行をつなげ）、最初の空行までをヘッダーフィールドとして読みます。Received行は古い順に並べ替え、各行のセミコロンの後にある日時を解析して、ホップ間の遅延を求めます。spf・dkim・dmarcの結果はAuthentication-ResultsとReceived-SPFから読み取ります。結果はすべて残すので、2つのDKIM署名のうち片方がpass、もう片方がfailなら「pass, fail」と表示されます。アライメントは、FromのドメインとDKIMの`d=`のドメイン、Return-Pathのドメインの間で確認します。解析のために何かをネットへ送り出すことはありません。 ### 例 組み込みのサンプルには、14:02:09と14:02:11（+0000）のタイムスタンプが付いた2つのReceived行があるので、2ホップ、合計2.0秒と表示されます。Authentication-Resultsの行にはshop.exampleに対するdkim=pass、spf=pass、dmarc=passが記録されていて、DKIMのドメインshop.exampleはFromのドメインと同じなので、アライメントがとれています。 ### 制限事項 - 結果は受信サーバーが書き込んだとおりに読み取ります。このページはDNSに問い合わせず、DKIM署名の再検証もしません。 - 送信者のものを含め、どのサーバーも偽のReceived行を加えられます。信頼できるのは、自分が利用しているメールサービスが加えた行だけです。 - 兄弟関係にあるサブドメイン同士の緩和モードのアライメントを判定するにはPublic Suffix Listが必要ですが、このページは読み込まないので、そうした組み合わせは一致している可能性がある、という表示にとどめます。 ### 出典 - [RFC 5321, section 4.4: Trace Information](https://www.rfc-editor.org/rfc/rfc5321#section-4.4)：Received行の加え方。 - [RFC 8601: Authentication-Results Header Field](https://www.rfc-editor.org/rfc/rfc8601)：検査結果の記録方法。 - [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208)：SPFの結果。 - [RFC 6376: DomainKeys Identified Mail (DKIM)](https://www.rfc-editor.org/rfc/rfc6376)：DKIM署名とd=。 - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989)：アライメントとDMARCの結果。RFC 7489を廃止。 ## このツールでできること メッセージを扱うメールサーバーは、それぞれヘッダーの先頭に行を加えていき、最後に受け取ったサーバーは、送信者が検査に合格したかどうかを記録します。その結果、ヘッダーは折り返された長いテキストになり、目で追うのはひと苦労です。この解析ツールはメール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 ; 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 `の場合、ほとんどのメールアプリは親しみやすい表示名しか見せませんが、ここまでの検査が対象にしているのはアドレスのほうです。 ## よくいただく質問 **貼り付けたヘッダーを、iseeu.ccのサーバーが受け取ることはありますか？** 受け取りません。ヘッダーはブラウザで動くJavaScriptが解析し、アップロードもほかへの送信もしません。自分で確かめたいときは、このページが表示された後にWi-Fiを切って、もう一度解析してみてください。オフラインでも同じ結果になります。それとは別に、iseeu.ccはIPアドレスや検索内容のログを残さず、訪問者のデータベースも持たず、Cookieを使わず、広告も表示しません。 **ここでDKIMがpassと表示されれば、署名は有効ということですか？** 受信したサーバーが、メールが届いた時点でpassと記録した、という意味です。このツールは暗号による検証をやり直したり、DNSから公開鍵を取得したりはせず、Authentication-Resultsヘッダーに書かれた判定を読み取ります。たいていはそれで十分です。送信者は鍵を入れ替えていくので、配信時には有効だった署名でも、数週間後に検証し直すと失敗することがあるからです。 **本物だとわかっているメールなのに、SPFがfailになるのはなぜですか？** いちばん多い原因は転送です。メールが転送されたりメーリングリストを経由したりすると、中継するサーバーは自分のIPアドレスから接続しますが、そのアドレスは元の送信者のSPFレコードに含まれていません。送信者が新しいメールサービスを追加したのにSPFを更新していない場合も、同じ結果になります。FromとアライメントのとれたドメインでDKIMがpassしていれば、それでもDMARCはpassになり得ます。 **経過時間がマイナスになっているホップがあるのはなぜですか？** 各サーバーはReceivedのタイムスタンプを自分の時計で書き込みますが、サーバー同士の時計は完全には合っていません。前のホップより1〜2秒早く届いたように見える場合は、たいていどちらかの時計が少しずれているだけです。送信者側の部分で大きく時間がさかのぼっている場合は、Receivedの行が作り話である可能性もあります。このツールは、順序がおかしいタイムスタンプと時計のずれに印を付けるので、どちらに当たるかを判断してください。 **フィッシングメールを見抜くのに、ヘッダーはどう役立ちますか？** 表示名と実際のFromアドレスを見比べ、次にDMARCがpassしたか、DKIMのドメインがFromのドメインと一致するかを確認します。Fromと異なるReply-Toは典型的な兆候です。From欄が正しく見えても、返信は攻撃者に届いてしまうからです。あわせて、利用しているメールサービスが最初に付けたホップも見てください。そこにある送信元のIPアドレスは、送信者が申告したものではなく、メールサービス側が記録したものです。 **認証結果がまったく表示されないのはなぜですか？** すべての受信システムがAuthentication-Resultsヘッダーを書き込むわけではありません。企業のメールサーバーや古い構成では省かれることがあり、同じ社内サーバーのユーザー同士でやり取りされたメールは、まったく検査されないことも少なくありません。転送されたコピーからヘッダーを写した場合も、元の結果は失われます。結果が見つからないときは警告が表示され、手がかりとして残るのはホップの一覧とDKIM-Signatureのドメインです。 **ホップに出てくるESMTP、ESMTPS、ESMTPSAとは何ですか？** そのサーバーが受けた接続の種類を表します。ESMTPは暗号化なしの拡張SMTPです。RFC 3848で追加された派生形では、ESMTPSはその区間でTLSを使ったこと、ESMTPAは送信側のクライアントがログインしたこと、ESMTPSAはその両方を表します。どのラベルもその1区間だけについてのもので、ある区間は暗号化され、別の区間はされていない、ということもあり得ます。社内での最後の配送段階には、よくLMTPと表示されます。 この解析は、受信サーバーがヘッダーに書き込んだ内容をなぞり、簡単な経験則を当てはめたものです。誰が送ったかを証明することはできません。お金や認証情報が絡むときは、以前から信頼している別の連絡手段で確認してください。 ## iseeu.ccのほかのツール - [DNSルックアップ](https://iseeu.cc/ja/dns-lookup/): A・AAAA・MX・TXT・NS・CNAME・CAA・SOAレコードをDNS over HTTPSで引きます。 - [Whois検索](https://iseeu.cc/ja/whois/): ドメイン名、IPアドレス、AS番号の登録情報を調べます。 - [セキュリティヘッダーチェック](https://iseeu.cc/ja/security-headers/): URLのレスポンスヘッダーを取得し、HSTSやCSPなどを採点します。 - [Punycode変換](https://iseeu.cc/ja/punycode/): 日本語ドメインなどの国際化ドメイン名とxn--形式を相互に変換します。 - [IPアドレス確認](https://iseeu.cc/ja/): グローバルIP、おおよその地域、プロバイダ、ヘッダー、TLS、リークテストを1ページで確認できます。 [すべてのツールを見る](https://iseeu.cc/ja/tools/) 最終更新：2026-10-11 元のページ：https://iseeu.cc/ja/email-header/