本文へスキップ

メールヘッダー解析

生のヘッダーを貼ると、各ホップを追跡し、SPF・DKIM・DMARCの結果を確認、なりすましを検出します。無料、ブラウザ内で完結。

完全非公開：解析はブラウザ内で完結。ヘッダーのアップロード、記録、保存は一切しません。

結果に応じた次のステップ

SPFは合格、DMARCは失敗DMARCで拒否されたメールquarantineとrejectの違い

メールヘッダー解析とは

メールヘッダー解析は、すべてのメールに付く隠れたメタデータを読み解きます。経由したサーバー、各ホップの時刻と遅延、受信サーバーが記録したSPF・DKIM・DMARCの判定です。生のヘッダーは折り返しや逆順、難解なタグで読みにくいため、ホップごとの配送表、認証の要約、送信元のアライメント確認に整理します。遅いメールが止まった場所の特定、名乗るドメインから本当に届いたかの検証、フィッシングやなりすましの証拠集めに使えます。

Gmail・Outlook・Apple Mailでのヘッダー表示方法

生のヘッダーは、どのメールソフトでも「原文を表示」「ソースを表示」の奥にあります。表示された内容をすべてコピーし、上に貼り付けてください。

  • Gmail メッセージを開き、右上の3点メニューから メッセージのソースを表示を選択します。同じ画面にGmail独自のSPF・DKIM・DMARCの要約も出ます。その判定の背景にある経路全体は、本ツールで解析できます。
  • Outlook（Web・新Outlook） メッセージを開き、ツールバーの3点メニューから 表示 → メッセージの詳細を表示を選択。従来のOutlookでは ファイル → プロパティを開き インターネット ヘッダー 欄をコピー。
  • Apple Mail メッセージを開き、 表示 → メッセージ → すべてのヘッダを選択。生データ全体は次から： 表示 → メッセージ → ソース.

ヘッダー関連の解説

メールヘッダーとはオンラインで安全に解析SMTPヘッダー解析の手順DMARCレポート解析

メール認証ナレッジベース

Gmail、Outlook、Apple Mailで生のヘッダーを取得するには？

Gmailはメッセージを開き、3点メニューの「メッセージのソースを表示」から先頭まですべてコピーします。Web版Outlookは3点メニューの「表示」＞「メッセージの詳細を表示」、従来のOutlookは「ファイル」＞「プロパティ」＞「インターネット ヘッダー」。Apple Mailは「表示」＞「メッセージ」＞「すべてのヘッダ」（または「ソース」）、Yahoo MailはMore > View raw message。コピーした内容を上に貼り付けます。

ヘッダーのReceivedチェーンの読み方は？

メールを中継した各サーバーは、ヘッダーの先頭に自分のReceived行を追加します。そのため一番下が送信元、一番上が自社のメールサーバーです。下から読むと配送経路全体をたどれます。本ツールは並べ替えを自動で行い、ホップ1が送信元です。各行に送信サーバー、受信サーバー、プロトコル、時刻、前のホップからの遅延を表示します。

Authentication-Resultsヘッダーでわかることは？

受信サーバー自身による、SPF・DKIM・DMARCの判定記録です。各方式に判定（pass、fail、softfail、noneなど）と、検証したドメインが付きます。SPFはsmtp.mailfrom、DKIMはheader.d、DMARCはheader.fromです。メールを受け取ったサーバーが書くため、ヘッダー内で最も信頼できる認証の証拠です。

SPFは合格なのにDMARCが失敗するのはなぜ？

SPFはReturn-Path（エンベロープ）のドメインで検証されますが、DMARCはさらに、そのドメインが表示上のFromドメインと一致することを求めます。bounce.someesp.comから送り、Fromがyourbrand.comなら、SPFはsomeesp.comで合格してもドメインが一致せずDMARCは失敗します。対策は、自社ドメインで独自のReturn-Path（バウンス）ドメインを使うか、合格かつ一致するDKIM署名です。

FromとReturn-Pathの違いは？

Fromはメールソフトに表示されるアドレス、Return-Pathはバウンスの宛先となる隠れたエンベロープアドレスです。配信サービスは自社のReturn-Pathドメインや貴社のサブドメインを使うことが多く、両者が完全に一致することはまれです。組織ドメインが同じ（mail.acme.comとacme.com）なら正常で、DMARCの既定のrelaxedアライメントを満たします。無関係なドメイン同士なら要注意です。なりすましメールの典型です。

ヘッダーから送信者の本当のIPや場所はわかる？

場合によります。最初のReceived行には、送信したサーバーや端末のIPが入ることが多く、グローバルIPならおおよその場所もわかります。ただしGmailなど大手のWebメールは送信者端末のIPを意図的に隠します。信頼できるサーバーに届く前に追加されたReceived行は偽装も可能です。ヘッダーのIPは手がかりであり、証拠ではありません。

ヘッダーでなりすましを見分けるには？

確認点は、Authentication-ResultsのDMARC失敗、Return-PathやDKIMのドメインと一致しないFromドメイン、無関係なドメインを指すReply-To、名乗る送信者と無関係な送信元サーバーです。1つだけなら正当な理由もあり得ます（転送でSPFが壊れるなど）。複数そろえば（特にp=rejectのドメインでdmarc=fail）、なりすましの可能性が高いです。

ホップ間で大きな遅延が出るのはなぜ？

よくある原因は、グレーリスティング（受信側が意図的に再送を求める）、スパムやマルウェアの検査、混雑したサーバーでの送信制限や待ち行列、DNSの問題です。遅いホップが1つあれば、そこが配送の止まった場所です。「メールが届くまで何時間もかかった」という問い合わせの調査で、ホップごとの遅延が役立つのはこのためです。サーバーの時計はずれることがあり、小さな遅延やマイナスの遅延は多くの場合、実際の遅れではなく時計のずれです。

メールヘッダーの見方は？

Received行は下から読みます。一番下が送信サーバー、一番上が自社のメールサーバーで、その間の各行が時刻付きの中継ホップです。次に、先頭付近のAuthentication-Resultsで自社サーバーが記録したSPF・DKIM・DMARCの判定を確認します。さらにFromアドレスとReturn-Pathを比べ、表示上の送信者とエンベロープの送信者が一致するかを見ます。本ツールはこの並べ替えと比較を自動で行います。ヘッダーを貼り付けると、ホップごとの表、各ホップの遅延、認証の要約を表示します。

ヘッダーをオンラインツールに貼っても安全？

ヘッダーに含まれるのはメタデータ（送信者と受信者のアドレス、サーバー名、IP、件名）で、本文や添付ファイルは含まれません。それでも機密になり得る情報です。本ツールはすべてブラウザ内で解析し、貼り付けた内容のアップロード、記録、保存は一切しません。データが端末の外に出ることはありません。どのツールでも、データの扱いを明記したものを選びましょう。

ヘッダーは偽装できる？

一部は可能です。送信者は自分が生成するものをすべて操作できます。From、Subject、Message-ID、X-Mailer、自分のサーバーより下のReceived行は、どれも偽装できます。偽装できないのは、信頼できる基盤に届いた後に追加されるヘッダー、つまり自社サーバーのReceived行とAuthentication-Resultsです。そのため解析では、送信者の主張ではなく、チェーンの上部とSPF・DKIM・DMARCの判定を拠り所にします。