要約

このメールヘッダー解析ツールは、メールの生ヘッダーを貼り付けるだけで、受信側メールサーバーがすでに計算したAuthentication-Results行を読み取り、SPF・DKIM・DMARCが実際にパスしたかどうかを判定します。Receivedヘッダーからリレーのホップ数を数え、タイムスタンプが揃っていればホップ間の転送時間も算出します。Gmailの「メッセージのソースを表示」、Outlookの「ソースの表示」、Apple Mailの「すべてのヘッダー」からヘッダーを貼り付けてください。解析はすべてブラウザ内で完結し、登録も不要です。

メールヘッダー解析で生ヘッダーからSPF・DKIM・DMARCを確認

任意のメールの生ヘッダーを貼り付けると、受信メールサーバーがすでに検証済みのSPF・DKIM・DMARC、リレーのホップ数、ホップ間の転送時間を読み取って表示します。

ヘッダーを解析する

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

下に生のヘッダーブロック全体を貼り付けてください。解析とスコア計算はすべてブラウザ内で行われ、外部には送信されません。

メールの生ヘッダーブロック（メッセージのソースを表示、元のメッセージを表示、またはメッセージの詳細から取得）を貼り付けてください。チェックはブラウザ内でのみ実行されます。

-
上にヘッダーを貼り付けると結果が表示されます
SPF、DKIM、DMARCはAuthentication-Results行から読み取られます。
    仕組み

    このスコアが実際に読み取っている内容

    Authentication-Resultsを解析

    このツールは受信サーバーが記録したAuthentication-Results行を探し、すでに計算済みのspf=、dkim=、dmarc=の値を読み取ります。DNSルックアップを自前で再実行することはなく、メッセージを実際に受信したメールボックスプロバイダーがその行に書いた結果をそのまま信頼します。

    リレーのホップ数をカウント

    各Receivedヘッダー行は、メールサーバー間の1つのホップを表し、下から上の順に読み取られます。2つ以上のホップに解析可能な日時があれば、最初と最後のホップ間の転送時間も推定します。タイムスタンプが解析できない場合は、無理に推測せずその統計値を非表示にします。

    サーバーではなくブラウザ内で実行

    ヘッダーには社内ホスト名やチケット番号、IPアドレスなど、見知らぬWebフォームに貼り付けたくない情報が含まれることがあります。このツールはテキストを一切外部に送信しません。正規表現による解析、スコア計算、ホップ数のカウントはすべて、今読んでいるこのタブの中でクライアントサイドに実行されます。

    ヘッダーチェックに関するよくある質問

    このメールヘッダー解析ツールは無料で使えますか？
    はい。登録は不要で、リクエスト数の上限もありません。スコアはブラウザ内でヘッダーテキストを解析して算出するため、当社側でリクエストごとのコストが発生することはありません。
    メールの生ヘッダーはどこで取得できますか？
    Gmailではメッセージを開いて「メッセージのソースを表示」を選択します。Outlookでは「表示」から「ソースの表示」、またはメッセージの詳細パネルを使います。Apple Mailでは「表示」→「メッセージ」→「すべてのヘッダー」です。Authentication-Results行とすべてのReceived行を含む、ヘッダー全体をコピーしてください。
    ここに貼り付けたヘッダーは保存されますか？
    いいえ。テキストエリアの内容はお使いの端末上で動作するJavaScriptによって読み取られるだけです。アップロードも記録もされず、当社サーバーに送信されることもありません。このページが発する唯一の通信は、サイト全体で共通の匿名ページビュービーコンだけです。
    「Authentication-Resultsヘッダーが見つかりません」と表示されるのはなぜですか？
    受信サーバーによってはこの行を追加しない場合があり、転送またはエクスポートされたコピーでは途中で取り除かれることもあります。チケットやスレッドから貼り付けた転送コピーではなく、メッセージが最初に届いた元の受信トレイを確認してください。
    SPFはパスしたのにDMARCが失敗しました。これはどういう意味ですか？
    DMARCはSPFとDKIMそれぞれのパスだけでなく、アライメント（一致）も確認します。エンベロープ送信者に対してSPFはパスしても、表示されるFromドメインがドメイン所有者のDMARCポリシーに対して十分に一致しない場合があります。ここでDMARCが失敗する場合、通常はFromドメインと認証済みドメインが異なっています。
    スコアが100であれば、送信者が正当であると保証されますか？
    いいえ。これは受信メールサーバーがすでに実施した技術的なチェックにメッセージが合格したことを意味するだけです。送信サーバーがそのドメインについて認可されており、署名とアライメントが一致していたということです。意図については何も示しません。侵害されたドメインやなりすましドメインからの、認証済みのフィッシングも実際に発生します。
    転送時間が表示されない、または「クロックずれ」と表示されるのはなぜですか？
    Receivedのタイムスタンプは各リレー自身の時計によって設定されており、時計にはずれが生じます。あるホップの時計が直前のホップより遅れている場合や、ヘッダーに解析可能な日時がない場合、このツールは無理に数値を示さずその項目をスキップします。
    リレーのホップ数だけで何か分かりますか？
    単独ではあまり多くを語りません。ほとんどのB2Bの送信は、送信元サーバーから受信トレイまでの間に2〜4のリレーを経由します。ホップ数が多いこと自体は必ずしも不審ではありませんが、見慣れないホスト名がチェーンに現れた場合は、送信者の既知のインフラと照らし合わせて確認する価値があります。

    自分自身の送信インフラを可視化する

    このチェッカーは、すでに送信された他人のヘッダーを事後的に読み取るものです。Notification Harborが扱うのは、あなた自身がコントロールする送信そのものです：ドメインウォームアップ、トレース単位の可観測性、そして苦情が来てから診断するのではなく、最初の送信からSPF・DKIM・DMARCを正しく設定しておくこと。

    Notification Harborの仕組みを見る
    notificationharbor
    無料で始める