メールヘッダー分析
RFC 5322 の継続行を展開し、From/To/Subject/Date/Message-ID を抽出、すべての Received 行を解析（時系列に逆順）して隣接ホップ間の実時間遅延を計算し、Authentication-Results から spf/dkim/dmarc の判定を抽出する。メッセージがスパムに振り分けられた理由の診断、偽造された Received チェーンの発見、どの MTA が遅延を導入したかの特定に便利。
- 差出人"Alice Sender" <alice@example.com>
- 宛先user@recipient.com
- 件名Hello there
- 日付Mon, 02 Jun 2026 09:15:38 +0000
- Message-ID<abc123@example.com>
- #1from sender-host.example.com → by mail.example.comMon, 02 Jun 2026 09:15:40 +0000 (UTC)
- #2+2sfrom mail.example.com → by mx.recipient.comMon, 02 Jun 2026 09:15:42 +0000 (UTC)
すべてローカルで解析 — ヘッダーがブラウザを離れることはありません。
使い方
- 完全な生ヘッダーを貼り付け（ヘッダーと本文を区切る空行より前すべて）。
- メタデータブロック、認証バッジ、ホップリストを確認。
よくある質問
- 生ヘッダーはどこで取得？
- Gmail：メッセージの ⋮ メニュー →「メッセージのソースを表示」。Outlook：ファイル → プロパティ → インターネットヘッダー。他のほとんどのクライアントにも「ソースを表示」や「オリジナルを表示」オプションがある。
- ホップが時々マイナスの遅延を示すのはなぜ？
- サーバーは時計が数秒ずれていることがよくあり、一部の MTA は Received 行をバックデートする。小さなマイナスは正常；大きなマイナス（またはホップの欠落）は偽造されたヘッダーを示唆する可能性がある。
- Receivedの連なりはどこまで信用できますか?
- 自分が管理している設備が付け加えた部分までです。各サーバーはメッセージを受け取るときに自分の行を先頭に足すので、信頼できる最初のホップより上は、自分が運用していない機械が書いたものであり、まるごと捏造できます。連なりは自分の側から外へ向かって読み、いちばん古いホップは証拠ではなく主張として扱ってください。
- SPFを通っているのに明らかな迷惑メールなのはなぜ?
- SPFは、封筒の差出人のドメインと送信サーバーのアドレスを照合するだけで、そのドメインは読み手に見えるドメインである必要がありません。自分が持つドメインでSPFを通しながら、表示上は他人を装ったFromを見せることができます。見えているFromが、実際にSPFやDKIMで認証されたものと一致することを求めるために存在するのがDMARCです。
関連ツール
SPF レコードビルダー
メカニズム・IP・include から SPF TXT レコードを構成 — ライブ DNS ルックアップカウンタと警告付き。
TXT レコードスプリッター（255 バイトチャンク）
長い SPF、DKIM、または DMARC TXT レコードを、DNS プロトコルが要求する 255 バイトチャンクに分割 — BIND、汎用ゾーンファイル、Cloudflare、または Route 53 構文を出力。
DKIMレコード ビルダー & パーサー
DKIM（DomainKeys Identified Mail）の DNS TXT レコードを構築・解析 — 公開鍵を貼り付け、selector・鍵タイプ（RSA/Ed25519）・ハッシュ・フラグを設定すれば、フルレコード + `selector._domainkey` ホスト名 + 255文字超用の DNS 分割版まで生成。
DMARC レコードビルダー
`_dmarc` TXT レコードを構成 — ポリシー、サブドメインポリシー、パーセンテージロールアウト、アライメント、rua/ruf レポート — 安全警告付き。
mailto: リンクビルダー
宛先・Cc・Bcc・件名・本文を入力して RFC 6068 準拠でパーセントエンコードされた mailto: URL を生成。<a> タグにそのまま埋め込めます。
Cache-Control ヘッダービルダー
ビジュアルチェックリストから HTTP Cache-Control ヘッダーを構築 — 鮮度、再検証、不変性、よく使うプリセット。