すべてのメールには隠された技術的な履歴がある——メールソフトが普段は表示しないヘッダー群だ。そこにはメッセージがどのサーバーを経由したか、送信者が本当に名乗っている本人かどうかが正直に記録されている。
件名が「=?ISO-2022-JP?B?...?=」のような文字列になる理由
メールヘッダーは数十年前に7ビットASCIIだけを前提として設計されたため、「明日の会議について」のような日本語の件名をそのままヘッダーに書くことはできない。RFC 2047はこれを「エンコード語」構文で解決する——=?ISO-2022-JP?B?GyRCJEQlKiVpJUghSyU5GyhC?=のように、まず文字コード名、次にBase64ならB、quoted-printableならQ、最後にエンコードされたバイト列が続く。日本のメールでは歴史的にUTF-8ではなくISO-2022-JP（いわゆるJISコード）がこの文字コードとして使われてきた経緯があり、UTF-8を使う海外のメールソフトとの間でこの文字コード名の違いが原因の文字化けが今も起こりうる。
Receivedヘッダー: メッセージの経路を示す地図
メッセージが通過する各メールサーバーは、リストの一番上に自分のReceivedヘッダーを追加していく——そのため送信者から受信箱までの実際の経路をたどるには、ヘッダーを下から上へ、つまり追加された順序とは逆に読む必要がある。
SPF・DKIM・DMARC: 3つの独立した信頼性チェック
SPF（Sender Policy Framework）はドメインのDNSレコードで、そのドメインの代わりにメールを送信してよいサーバーを列挙したものだ。Received-SPFヘッダーは、送信元サーバーがそのリストに含まれていたかどうかを示す。DKIMはメッセージに暗号署名を付加し、送信者のDNSに公開された公開鍵で検証できる仕組みで、本文が途中で改ざんされていないことを証明する。そしてDMARCは、SPFやDKIMに失敗したメールをどう扱うか——拒否する、迷惑メールとして扱う、警告付きで配信する——を受信サーバーに指示する。宅配便の不在通知や銀行を装ったフィッシングメールでは、この3つのうちどれかが必ずと言っていいほど失敗している。
何の役に立つか
- 不審なメールが送信者を偽装したフィッシングかどうかを確認する。
=?ISO-2022-JP?B?...?=のような読めない文字列になった件名や送信者名をデコードする。- 自分が送ったメールが相手の迷惑メールフォルダに振り分けられる原因を調べる。
Message-IDが何のためにあるか
Message-IDヘッダーは、メールソフトが送信時に付与する一意の識別子で、理論上は世界中のどのメールとも重複しない。これは会話を「スレッド」としてまとめるために不可欠で、メッセージに返信すると、メールソフトは元のMessage-IDをIn-Reply-Toヘッダーにコピーする——このつながりによって、メールサービスは個別のメッセージではなく1つの会話として表示できる。