メールヘッダ解析

メールを受け取ったサーバは、自分の Received 行をヘッダの先頭に足していきます。そのため生のヘッダでは一番上が最後の中継、一番下が最初の中継になります。このツールでは逆順に直して、送信側から受信側へ読める向きで表示します。

その Received 行に書かれた日時と、1つ前（より古い）Received 行の日時との差です。ここが大きいホップが、遅延の発生している中継です。ただし各サーバの時計がずれていると差も歪むので、極端な値は時計ずれを疑ってください。

できません。Received の from に書かれるのは接続してきた相手が名乗ったホスト名で、送信側が自由に書けます。角括弧の中のIPアドレスは受信側が観測した値なので、こちらのほうが確かです。

Authentication-Results の spf= / dkim= / dmarc= / arc= / compauth=、Received-SPF の先頭の結果語、DKIM-Signature の d=（署名したドメイン）です。これらは受信側のサーバが書いたものなので、そのサーバを信頼できる場合にだけ意味を持ちます。

=?UTF-8?B?...?= のような RFC 2047 のエンコードワードは自動でデコードして表示します。ブラウザが扱えない文字セットのときは、元の文字列のまま残します。

いいえ。解析はすべてお使いのブラウザ内で行われます。ヘッダには社内のホスト名や宛先アドレスが含まれるため、サーバへ送信も保存もしません。

問題ありません。ヘッダ部分は最初の空行で終わるため、それより後ろは読み飛ばします。ただし不要な情報を扱わないよう、ヘッダだけを貼ることをおすすめします。

中継のどこで時間がかかったかは分かります。所要時間の大きいホップが原因の候補です。ただしサーバの時計がずれていると差が正しく出ないため、極端な値はまず時計を疑ってください。

いいえ。SPF が確かめるのはエンベロープの送信元ドメインとIPの対応だけで、本文の内容や、画面に表示される From の正しさは保証しません。表示名の詐称は SPF が pass でも成立します。

中継を経ていないか、ヘッダの一部だけを貼り付けている可能性があります。その場合も他のヘッダの一覧と認証結果は表示されます。