Tiny Online Tools
Received チェーンとは
メールを扱ったサーバーはそれぞれ、ヘッダーブロックの先頭に Received: 行を足していきます。つまり積み重なった順序は新しいものから古いものへ。ひっくり返せば、それがメールのたどった経路です。各中継には、どのホストから来たか（from）、どのホストが受け取ったか（by）、たいていは相手の IP アドレスとその逆引き DNS 名、到着に使われたプロトコル、そしてタイムスタンプが書かれています。隣り合うタイムスタンプの差が、その中継で生じた遅延です。届くのに 6 分かかったメールが、その 6 分がどこで費やされたのかを自分で語ってくれるわけです。ほとんどの場合、キューかグレイリストの再送です。
マイナスの遅延は異常ではありません。数秒ずれた時計を持つ二つのリレーがあればそうなりますし、ローカル時刻を誤ったオフセットで刻むサーバーでも起こります。
分かること、分からないこと
ここが多くのヘッダー解析ツールの黙っている部分です。**一番上の Received: より下にあるものはすべて、受信者が管理していないマシンが書いたものです。**偽造されたチェーンは本物とまったく同じに見えます。何かの証拠になるのは、自分の側のインフラが付けた中継（上のほう）と、最後に受け取ったサーバーが書いた Authentication-Results だけです。
しかもその認証結果は記録であって、検証ではありません。ここに出る SPF・DKIM・DMARC の判定は、受信サーバーがすでに書いたヘッダーから読み取ったものです。自前で検証するには DNS 照会——送信側の SPF レコード、セレクターに対応する DKIM 公開鍵——が要りますが、このツールはネットワーク要求を一切行いません。対応する Authentication-Results のない DKIM-Signature ヘッダーは、送信者が「署名した」と主張したことを示すだけです。だからこそ未検証と表示しています。
整合（アライメント）
DMARC が通るのは、SPF または DKIM が認証したドメインが From: のドメインと一致するときです。この比較をはっきり表示しているのは、spf=pass を掲げていてもなお偽造でありうるからです。その pass が、見えている差出人とは無関係なバウンス用ドメインのものである場合があります。
貼り付けた内容がアップロードされることはありません。解析はこのタブ内で行われ、JSON として保存できます。