人気のツール

テーマ

メールヘッダー解析ツール

メールヘッダーを貼り付けるだけで、メールが通った経路、各中継サーバーでかかった時間、受信側のSPF・DKIM・DMARCの結果を確認できます。メールヘッダーの見方を知りたい方や、メール ヘッダーを確認して送信元を調べたい方向けのヘッダー解析ツールです。

ブラウザ内で解析 · 検索するのは公開サーバーのIPだけ（送信元ドメインは操作したときのみ） · 何も保存しません

ヘッダーがお使いの端末の外に出ることはありません。結果の下に表示されるIPアドレスとドメインだけを検索します。

表示される内容

  • 本当の送信元を、プロバイダー自身のチェックだけで判定
  • 途中のすべてのサーバー、各中継での遅延、TLSを使ったかどうか
  • SPF、DKIM、DMARC、ARCと、Fromアドレスとの一致
  • 類似ドメイン、偽造された結果などの兆候を、それぞれ根拠つきで
  • Microsoft 365、Gmail、SpamAssassinのスパム関連ヘッダーを解読
  • GmailとYahooの大量送信者向けルール（ワンクリック登録解除を含む）

メールヘッダーとは？

メールヘッダーとは、メッセージ本文の上にある行のまとまりで、誰が誰に、いつ送ったか、そして処理したすべてのサーバーの記録が含まれます。メールアプリはその大半を隠しているため、「メッセージのソースを表示」や「View source」のような機能で全体を確認します。

各行は、名前、コロン、値で構成されます。長い値は、空白で始まる次の行へ続きます（RFC 5322）。ヘッダーは最初の空白行で終わり、それ以降は本文で、このツールは読み取りません。

ヘッダーを書くのは3種類です。送信者のアプリ（From、To、Subject、Date）、途中のすべてのサーバー（それぞれReceived行を1本）、そしてプロバイダー（Authentication-Results、スパム判定）です。信頼できる相手がチェックしているのは、最後のものだけです。

ニュースレターのサンプル30フィールド · 4.6 KB

プロバイダー（Google）が追加11フィールド

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

途中のサーバー（SendGrid example.org）が追加5フィールド

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

送信者のアプリが記述14フィールド

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

空白行：ここから本文が始まります。このツールは本文を読み取りません

短縮表示です。1フィールドを1行にし、ヘッダーと同じ番号を付けています。色は結果と同じで、プロバイダー、途中のサーバー、送信者を表します。
メールヘッダー解析ツールの結果画面：PayPalに似せたメールの判定、指摘事項、41分の間隔がある配送経路メールヘッダー解析ツールの結果画面：PayPalに似せたメールの判定、指摘事項、41分の間隔がある配送経路判定誰が送ったのかを、プロバイダーが書いたAuthentication-Resultsだけで判定し、チェックしたサーバーも示します。目立つ点指摘事項ごとに重大度、理由、その元になったヘッダー行を表示します。配送経路Dateヘッダーから受信トレイまでのすべてのサーバーを、間隔を縮尺どおりに描き、信頼の境界も示します。ファクト配送にかかった時間、中継の数、外部への中継がすべてTLSだったか、Microsoftが選んだフォルダーを表示します。
不審なサンプルです。Microsoft 365自身のチェックでは送信元を確認できず、指摘事項には根拠が示され、経路にはメッセージが待機した場所が表示されます。番号を選ぶと、各部分に何が表示されているかを確認できます。

メールヘッダーの見方：下から上へ読む

メールヘッダーを解析するには、Received行を下から上へ読みます。各サーバーは、すでにある行の上に自分の行を追加するため、一番下が最初のホップで、一番上がプロバイダーがメールボックスに渡した記録です（RFC 5321 §4.4）。

1本の行には、受信した者（by）、どのサーバーとアドレスから（from、接続で確認されたアドレス）、どの方法で（with：ESMTPSはSTARTTLS、ESMTPSAはSTARTTLSにログインを加えたもの）、いつかが書かれています。サーバーは自分のローカル時刻を記録するため、引き算の前にUTCに直します。07:02:47 -0700は、UTCの14:02:47です。

確実なのは、プロバイダーが書いた行だけです。その最初の行より下はすべて、確認できないサーバーから届いたもので、送信者が自分で行を追加することもできます。

ヘッダー内 · 上が最新

経路 · ホップ1が最初

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Googleの内部14:02:48 UTC+1秒
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33秒

信頼の境界

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3SendGridのフィルター14:02:13 UTC+0.6秒
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2.9秒
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTC最初

上へ向かって読む：各サーバーは自分の行を一番上に追加します

ニュースレターの5本のReceived行です。ホップ1はニュースレターのアプリで、SendGridとGoogleの間の33秒が最大の間隔です。

メールヘッダーのSPF、DKIM、DMARC

SPFは、送信サーバーがエンベロープドメイン（Return-Path）に代わって送信してよいかを確認します。DKIMは、ドメインがメッセージに署名し、その署名が今も一致しているかを確認します。DMARCは、合格したSPFまたはDKIMのドメインが、画面に表示されるFromアドレスと一致しているかを確認します。

プロバイダーは、その答えをAuthentication-Resultsに書き込みます。信頼するのは、プロバイダー自身のReceived行の隣にある、プロバイダーが書いたブロックです。ほかのコピー、ARCのコピー、送信者の行の中にあるものは、誰でも追加できます（RFC 8601）。

合格はドメインを証明するもので、意図を証明するものではありません。examp1e.comは、自身について3つすべてに合格できます。

Authentication-Resultsを分解ニュースレター · 続いて不審なサンプル
Authentication-Results: mx.google.com;1

チェックした者authserv-id：プロバイダー自身のサーバー

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM：example.orgが署名鍵はs1._domainkey.example.orgにあります

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

2つ目の署名送信サービス自身のもので、example.orgとはアラインメントできません

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF：sendgrid.netに代わっての送信を許可Fromではなく、エンベロープ（Return-Path）のドメイン

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC：Fromのドメインが②と一致p=quarantineは、失敗したときの扱いとしてexample.orgが受信側に求めている内容です

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001有効Microsoft 365が、自身が追加した最初のReceived行より上に書きました。

信頼の境界

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100無視Microsoftを名乗っていますが、すべてのReceived行より下にあり、メッセージの中に含まれていたものです。受信側がそこに書くことはありません。
線の下：不審なサンプルの2つのAuthentication-Resultsです。どちらが有効かは、位置で決まります。

このメールは本物？ なりすまし？

ヘッダーから、オファーが誠実かどうかは分かりませんが、Fromのドメインが本当に送信したのか、別の誰かを真似ていないかは分かります。まず、プロバイダーが書いた判定を見て、次に以下の兆候を探します。

どれも、それだけでフィッシングと証明できるものではなく、よくある違いの多くは普通のことです。Microsoftは、類似ドメインでも、所有者が設定していればSPF、DKIM、DMARCに合格できると述べています（Microsoft）。

  • 類似したFromドメイン重大

    paypa1-billing.example対paypal.com

    数字や似た文字が入れ替えられています。自身についてSPF、DKIM、DMARCに合格することがあります。

  • 別の文字種の文字重大

    xn--pypal-4ve.example表示pаypal.example

    аはキリル文字です。ヘッダーにはxn-- 形式（punycode）が残るため、違いが分かります。

  • プロバイダーの判定は不合格重大

    compauth=fail reason=001 · spf=softfail

    受信側は、Fromのドメインを、送信したサーバーと結び付けられませんでした。

  • 別のアドレスを含む名前中

    "accounts@example.com" <notice@mailer.example>

    アプリが表示するのは名前で、アドレスではありません。本当の送信者は、かっこの中にいます。

  • フィルター自身の判定中

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoftはフィッシングに分類し、迷惑メールに振り分けました。9.25は初めての相手のヒントです。

  • 線より下にある合格の結果中

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    すべてのReceived行より下に書かれているため、送信者が書いたものです。有効なのはプロバイダーのものだけです。

普通のことで、それだけでは危険信号ではないもの

  • Return-PathがFromと異なる

    sendgrid.net対example.org

    メール配信サービスがあなたに代わって送信します。一致はDKIMが担います。

  • Reply-ToがFromと異なる

    Reply-To: support@example.org

    返信はヘルプデスクに届きます。確認が必要なのは、そのドメインが別のドメインを真似ている場合だけです。

  • 時刻が逆戻りしている

    09:47:12 → 09:47:11 (−1秒)

    各サーバーは自分の時計で時刻を記録するため、時計が1秒以上ずれていることもあります。

  • 別の国にあるサーバー

    CTRY:US · 209.85.208.54

    それはサーバーの所在地であり、人の居場所ではありません。大手プロバイダーは世界中から送信します。

不審なサンプルと、架空のバリエーションにある兆候です。それだけでフィッシングと証明できるものはありません。

メールが遅れたのはなぜ？

各Received行の時刻を、その上の行の時刻から引きます（UTC）。最大の間隔が、メッセージが待機した場所を示します。30分以上の間隔は、再送と矛盾しません（RFC 5321は、30分以上空けることを勧めています）。

Dateヘッダーは送信者の端末のものなので、Dateから最初のサーバーまでの時間には、時計の遅れや、送信のずっと前に書かれた下書きも含まれます。2台のサーバーの時計がずれていると、時刻が1秒戻ることもあります。

どれだけ長ければ長すぎるのかを定めた標準はありません。

不審なサンプル時刻はUTC
Dateヘッダー09:05:44 UTC
+7秒
mail.paypa1-billing.example09:05:51 · 最初のサーバー
41分21秒30分以上：再送

Microsoft 365

  • 09:47:12エッジ、最初の行
  • 09:47:11内部 · −1秒
  • 09:47:13メールボックスサーバー
  1. 09:05:44Dateヘッダー送信者の時計
  2. +7秒
  3. 09:05:51mail.paypa1-billing.example最初のサーバー
  4. 41分21秒30分以上：再送と矛盾しません
  5. 09:47:12Microsoft 365のエッジMicrosoftが書いた最初の行
  6. −1秒時計がずれています
  7. 09:47:11Microsoftの内部
  8. +2秒
  9. 09:47:13Microsoftのメールボックスサーバー
Dateヘッダーから
41分29秒
最初のサーバーから
41分22秒
ニュースレターのサンプル · 44秒時間がかかった場所
  • Date → 最初のサーバー 6秒
  • SendGridへ 2.9秒
  • SendGridのフィルター 0.6秒
  • SendGrid → Google、最大の間隔 33秒
  • Googleの内部 1秒

Microsoft 365とGmailのスパムヘッダーを解読

Microsoft 365は、フィルターの判定をX-Forefront-Antispam-Reportに書き込みます。CATが判定、SFVがスパムフィルタリングの判断で、X-Microsoft-Antispam-Mailbox-Deliveryが、どのフォルダーに配信されたかを示します。

SCLは今も書き込まれますが、Microsoftによると、Microsoft 365ではもう何も決定しません。代わりにCATを読んでください（Microsoft）。BCLは苦情に基づいて大量メールを0〜9で評価し、ポリシーのしきい値（既定は7）で判断されます。

Gmailは、文書化されたスパム判定を書き込みません。SpamAssassinを実行するサーバーは、スコア、しきい値、検出されたルールを含むX-Spam-Statusを追加します。

X-Forefront-Antispam-Report不審なサンプル
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH 判定：フィッシング（SPMはスパム、SPOOF、BULK、HPHSHなど）
  2. 2SFV:SPM スパムフィルタリングがスパムと判定（NSPM：スパムではない）
  3. 3SCL:5 Microsoft 365ではフィルタリングへの入力であり、判定ではありません
  4. 4SFTY:9.25 初めての相手のセーフティヒントが表示されました
  5. 5IPV:NLI IPはどのレピュテーションリストにもありません
  6. 6DIR:INB 受信。SFSとARAはMicrosoft内部の診断情報です

大量メールの苦情レベルBCL:0

01〜3 少ない4〜7 まちまち8〜9 多い

しきい値は、Strict 5、Standard 6、既定 7です。それ以上なら大量メールです。

振り分け先dest:J

迷惑メール（Junk Email）X-Microsoft-Antispam-Mailbox-Delivery

dest:Iは受信トレイです。ucf、jmr、ENGは内部の情報です。

GmailとSpamAssassin

Gmailは文書化されたスパム判定を書き込みません。X-Received、X-Google-Smtp-Source、X-Gm-*は内部の情報です。

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin：必要なスコア以上のときだけスパムです。

不審なサンプルのすべての値を、Microsoftのスパム対策ヘッダーの表で読み取ったものです。

メールヘッダーの確認方法：Gmail、Outlook、Apple Mailなど

パソコンまたはWebブラウザから、ヘッダー全体、または元のメッセージ全体をコピーします。そのうえで上に貼り付けるか、メッセージを.emlファイルとして保存してアップロードします。

ヘッダーは、アプリごとに別のメニューに隠れています。お使いのアプリを選んでください。手順は、各プロバイダー自身のヘルプページに従っています。

  1. 1メールを開く
  2. 2その他
  3. 3メールのソースを表示

出典：support.yahoo-net.jp · H000007254（日本語）

スマートフォンの場合： Gmail、Outlook、Apple Mailのアプリでは、ヘッダー全体を表示できません。ブラウザ（Gmail、Web版Outlook）またはデスクトップアプリでメッセージを開くか、添付ファイルとして転送し、.emlをここにアップロードしてください。

メールの送信元をたどる方法と、IPから分かること・分からないこと

メールをたどるには、プロバイダーが書いた最初のReceived行にあるfromアドレス、つまりメッセージを引き渡したサーバーを調べます。その所有者を調べれば、それが誰のサーバーかは分かりますが、元の送信者ではなく転送元のこともあります。

ヘッダーに表示されるのはメールサーバーで、送信者自身のネットワークが分かるのは、X-Originating-IPがある場合だけです。

そのアドレスでさえ、示すのはネットワークとおおよその国であり、個人や番地ではありません。

Gmail → Outlookのサンプルブラウザから検索
Anaのパソコンヘッダーにはありません
209.85.208.54mail-ed1-f54.google.com
Microsoft 365最初に書かれたReceived行

209.85.208.54から分かること

所有者
Google LLC · 209.85.128.0/17（ARIN）
国
アメリカ合衆国（サーバーの所在地）
役割
Gmailの送信サーバー（SPFがチェックしたもの）

分からないこと

誰か
Ana、またはexample.netの誰か
場所
その人の市区町村や番地
端末
その人のパソコンやスマートフォン
このツールが検索するのはサーバーの公開アドレスだけで、そのレジストリに問い合わせ、問い合わせた内容をそのまま表示します。

メールヘッダー：よくある質問

メールヘッダーを解析するには？

メールアプリからヘッダー全体をコピーし、上に貼り付けて「ヘッダーを解析」を選びます。メールヘッダーの解析では、下から上へ読み取り、プロバイダーが書いた判定、サーバーごとの経路と各中継での遅延、根拠つきの指摘事項を表示します。

メールヘッダーのここへの貼り付けは安全ですか？

ヘッダーはブラウザ内で読み取られ、当サイトに送信されることはありません。検索するのは公開サーバーのIPだけで、所有者はレジストリ（RDAP、ブラウザが問い合わせ）から、国は当サイトから取得したDB-IPのファイルから調べるため、当サイトのサーバーには、どのアドレス範囲が照会されたかが分かります。送信元ドメインをdns.googleで検索するのは、操作したときだけです。ヘッダーにはアドレスやサーバー名が含まれるため、共有するときは注意してください。

メールヘッダーは偽造できますか？

はい。プロバイダーがメッセージを受け取る前に書かれたものは、すべて偽造できます。各サーバーは自分の行を一番上に追加するため、送信者はその下に偽のReceived行を置き、passと示す偽のAuthentication-Resultsまで置けます。信頼できるのは、一番上にあるプロバイダー自身の行と、その横にプロバイダーが書いた結果です。解析ツールは、それ以外を主張として表示します。

メールが偽物かどうか、どうすれば見分けられますか？

まず、プロバイダーのAuthentication-Resultsを見ます。DMARCのfailや、Microsoft 365のcompauth failは、Fromのドメインが確認されなかったことを意味します。次にドメイン自体を読んでください。paypa1-billing.exampleのような類似ドメインは、自身についてすべてのチェックに合格できます。最後に、返信の宛先と、メッセージを引き渡したサーバーを確認します。解析ツールは、各指摘事項を根拠とともに表示します。

メールから送信者のIPアドレスは分かりますか？

分かるのは、メッセージをプロバイダーに引き渡したサーバー、つまりプロバイダーの最初のReceived行にあるfromアドレスで、SPFがチェックしたものです。多くの場合、メールサーバーであって、本人のパソコンではありません。プロバイダーによってはX-Originating-IPも追加され、通常は送信者の端末やネットワークを示しますが、それでも示すのはネットワークとおおよその国までで、個人ではありません。

Gmailが送信者のIPアドレスを表示しないのはなぜですか？

Gmailのウェブやアプリから送られたメッセージには、通常Googleのサーバーしか含まれません。最初のReceived行にはfrom部分がないため、送信者自身のアドレスはヘッダーにありません。見えるアドレスは、メッセージを次へ渡したGoogleのサーバー、つまりSPFがチェックしたもののため、照会しても所有者は送信者のネットワークではなくGoogleと表示されます。

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

SPFが確認するのはエンベロープドメイン（Return-Path）で、画面に表示されるFromとは異なることがあります。DMARCでは、Fromと完全に、または同じ組織内で一致するドメインでSPFまたはDKIMが合格する必要があります。合格したドメインが他人のもの、たとえばメールサービスのバウンスドメインなら、DMARCは失敗します。FromのドメインによるDKIM署名があれば、それだけでDMARCに合格します。

ホップ間の遅延がマイナスになるのは、どういう意味ですか？

後のサーバーが、その前のサーバーより早い時刻を記録したということです。各サーバーは自分の時計の時刻を書き込み、その時計はずれていることがあるため、解析ツールは遅延ではなく時計のずれとして表示します。プロバイダーが書いた行より下の時刻は偽造されている場合もあるため、その順序や間隔は主張として扱ってください。

SCLとBCLは何を意味しますか？

どちらもMicrosoft 365のスパム対策ヘッダーにあるスコアです。BCLは苦情のレベルに基づいて大量メールを0（大量送信者ではない）から9で評価します。SCLは今も書き込まれますが、Microsoft 365ではフィルタリングへの入力であり、判定ではありません。判定を示すのはCATで、SFVはスパムフィルターがそのメッセージをどう扱ったかを示します。

メールヘッダーにBCCの受信者は表示されますか？

いいえ。ブラインドコピーはヘッダーに書き込まれません。送信サーバーがエンベロープから配信し、ToとCcの行には見える受信者だけが表示されます。Received行のfor句が受信者1人を示すことはあり、そのため、サーバーはこれを慎重に使うよう求められています。Delivered-Toにも、メッセージが届いたメールボックスが表示されることがあります。

このメールヘッダ解析ツールは、MicrosoftのMessage Header Analyzerと同じですか？

いいえ。MicrosoftのMessage Header Analyzerは、Outlookのアドインとウェブページで、メッセージのヘッダーを解読します。このツールは、同じMicrosoftのヘッダーに加えて、GmailとSpamAssassinのヘッダー、すべてのホップの経路も読み取り、結果の位置で信頼できるものを判断し、すべてブラウザ内で動作します。

Authentication-Resultsヘッダーが複数あるのはなぜですか？

メッセージをチェックしたサーバーは、それぞれ1つ追加でき、送信者が偽物を追加することもあるため、1通に複数付いていることがよくあります。有効なのは、プロバイダーが書いたものだけです。一番上にあり、プロバイダー自身のReceived行の横にあって、自分のサーバーを示しているものです。ARC-Authentication-Resultsは、転送した側が封印した結果で、転送でメッセージが変わる前に何が合格していたかを次のサーバーが確認できるようにするものです。

足りないものはありますか？機能や新しいツールを提案する

ほかのメールツール