「Toに自分が入っていないのに、メールが届いたんですけど…」
「取引先から『件名が文字化けしている』と言われました」
どちらも、メールの中身の構造を知っていれば、すぐに説明できる現象です。前者は「エンベロープとヘッダー」の違い、後者は「日本語の符号化」の問題です。
第2回では、SMTPのコマンドと応答を見ました。第3回では、DATAで送られる「中身」、つまりヘッダーと本文の構造を見ていきます。メールのトラブル調査で最も役に立つ、ヘッダーの読み方も身につけましょう。
ヘッダーとボディ（RFC 5322）
DATAの後に送られる中身（メッセージ）の形は、SMTPとは別の規格RFC 5322が定めています。
- メッセージはヘッダーとボディ（本文）からなり、間を空行1つで区切る
- ヘッダーは「名前: 値」の行の並び。長い値は、次の行の先頭に空白を置いて続ける（折り返し）
- 必須のヘッダーはFromとDateだけで、Message-IDも付けるべきとされている
- 1行はCRLFを除いて998文字以内（必須）、78文字以内（推奨）
- RFC 5322はASCIIの文字しか扱わないため、日本語や添付ファイルはMIMEで符号化して入れる
大事なのは、メールソフトの画面の件名や差出人は、ヘッダーを整えて表示したものにすぎないということです。実際のヘッダーには、経路や認証の結果など、画面に出ない情報がたくさん含まれています。画面に出ない行こそ、調査の手がかりになります。
メッセージの実例
Return-Path: <taro@example.jp>
Received: from mail.example.jp (mail.example.jp [203.0.113.25])
by mx1.example.com (Postfix) with ESMTPS id 9A7D12B4C1
for <hanako@example.com>; Thu, 24 Sep 2026 10:15:38 +0900 (JST)
From: Taro Yamada <taro@example.jp>
To: Hanako Sato <hanako@example.com>
Subject: Meeting on Friday
Date: Thu, 24 Sep 2026 10:15:30 +0900
Message-ID: <20260924011530.3E5B0C1D22@mail.example.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
The meeting starts at 10:00 on Friday.- 上の2つ（Return-Path・Received）は、配送の途中で受信側が付けたもの。Fromから下は、作成者のメールソフトが付けたもの
- Receivedの2〜4行目は行頭が空白で、前の行の続き（折り返し）
- 空行の後が本文。日本語や添付を含む例は、この記事の後半で見る
エンベロープとヘッダー ― 封筒と便箋
冒頭の「Toに自分がいないのに届いた」の答えがここです。メールには、差出人と宛先が2組あります。
- エンベロープ（封筒）：SMTPの
MAIL FROMとRCPT TOで伝える差出人・宛先 - ヘッダー（便箋）：メッセージのヘッダーに書かれた
From:・To:・Cc:
郵便にたとえると、郵便局（メールサーバー）は封筒の宛名だけを見て配達し、中の便箋は読みません。便箋の「○○様」「△△より」は、受け取った人が読むためのものです。
普段は両者が同じなので違いを意識しませんが、メーリングリスト、転送、メール配信サービス、そして迷惑メールでは、両者が食い違います。Toに自分が無いメールや、Fromが社内のアドレスの外部からのメールが届くのは、このためです。配達を決めるのは封筒。便箋のFromは誰でも書けます。
送信ドメイン認証では、SPFがエンベロープの差出人を、DMARCがヘッダーのFromを確かめます（第5回）。
エンベロープとヘッダーの対応
| 項目 | エンベロープ（SMTP） | ヘッダー（メッセージ） | 誰が見るか |
|---|---|---|---|
| 差出人 | MAIL FROM:<アドレス>（エンベロープ From） | From:（表示される差出人） | エンベロープはバウンスの返送先・SPF、ヘッダーは利用者・DMARC |
| 宛先 | RCPT TO:<アドレス>（1件ずつ） | To:・Cc:（Bcc: は通常残らない） | 配送はエンベロープだけで決まる |
| 記録される場所 | MTA のログ、Return-Path:、Received: の for <…> | メールソフトの画面 | ログの from・to はエンベロープの値 |
| 空にできるか | MAIL FROM:<>（バウンス等） | From: は必須 |
- Bccの仕組み：メールソフトはTo・Cc・Bccのすべてを
RCPT TOで伝え、ヘッダーからはBccの行を消して送る。だからBccの宛先にも届き、他の人には見えない - ただし、1宛先だけの配送では、受信側の
Received:にfor <Bccの宛先>が記録されることがある。Bccの本人のメールには、自分宛てと分かる痕跡が残る - Return-Pathは、最後に配送したサーバーがエンベロープFromを書き写したもの。ヘッダーのFromとは別物
「差出人は社内なのに、ログには別のアドレス」という食い違いは、配信サービスや転送では普通に起きます。調べるときは、ログ（封筒）とヘッダー（便箋）を並べて見ましょう。
主なヘッダー
作成者が付けるもの
| ヘッダー | 意味 | 注意点 |
|---|---|---|
| From | 作成者（表示される差出人）。名前 <アドレス> の形 | 必須。自由に書けるので偽装できる。DMARC で確かめる（第5回） |
| Sender | 実際に送った人（From と違うとき） | 代理送信のとき。Outlook の「○○の代理」の表示の元 |
| Reply-To | 返信先 | From と違う返信先はフィッシングにも使われる |
| To・Cc | 宛先・写し | 表示用で、配送には使われない |
| Subject | 件名 | 日本語は RFC 2047 の形で符号化される |
| Date | 作成した日時（時差付き） | 必須。送信側の時計しだいで、ずれていることもある |
| Message-ID | 1通ごとの一意な ID | ログや他社の調査との突き合わせに使う |
| In-Reply-To・References | 返信元の Message-ID | スレッド表示に使う。消えると会話がばらばらになる |
これらはすべて送信者の申告で、受信側は原則として中身を検証せずに受け取ります。画面の差出人が本物である保証はありません。なお、Dateの+0900は日本時間であることを示し、メールソフトは受信者の時間帯に直して表示します。
配送・認証・配信で付くもの
| ヘッダー | 意味 | 注意点 |
|---|---|---|
| Return-Path | エンベロープ From の写し | 最終配送のときに受信側が付ける |
| Received | 経由したサーバーが先頭に追記する記録 | 下から上へ読む（次の節） |
| Authentication-Results | 受信側が記録した SPF・DKIM・DMARC の結果 | 自組織のサーバーが付けたものだけ信用する（RFC 8601） |
| DKIM-Signature | 送信ドメインの電子署名 | d= が署名したドメイン、s= がセレクター（第5回） |
| ARC-Seal など | 転送で認証の結果を引き継ぐ | 第6回 |
| List-Unsubscribe・List-Unsubscribe-Post | 配信停止の方法、ワンクリックでの停止 | RFC 2369・RFC 8058。大量送信者の要件（第7回） |
| X- で始まるもの | 製品や組織が独自に付ける情報 | 迷惑メールの判定理由などが書かれることが多い |
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=example.jp;
dkim=pass header.d=example.jp header.s=s1;
dmarc=pass header.from=example.jp
List-Unsubscribe: <https://news.example.jp/unsub?u=a1b2c3>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickReceivedヘッダーの読み方
「メールが遅れて届いた」ときに、どこで時間がかかったかを調べるのがReceivedです。
Received: from mx1.example.com (mx1.example.com [198.51.100.25]) ③
by mbox.example.com (Postfix) with ESMTP id 4F1C22A0B3
for <hanako@example.com>; Thu, 24 Sep 2026 10:15:40 +0900 (JST)
Received: from mail.example.jp (mail.example.jp [203.0.113.25]) ②
by mx1.example.com (Postfix) with ESMTPS id 9A7D12B4C1
for <hanako@example.com>; Thu, 24 Sep 2026 10:15:38 +0900 (JST)
Received: from pc01 (unknown [203.0.113.45]) ①
by mail.example.jp (Postfix) with ESMTPSA id 3E5B0C1D22
for <hanako@example.com>; Thu, 24 Sep 2026 01:15:30 +0000 (UTC)
- 各サーバーが先頭に追記するので、下から上へ読むと①→②→③の順に経路をたどれる
fromは相手が名乗った名前（括弧内は逆引きの名前とIPアドレス）、byは記録した自分、withは方式、idはそのサーバーのキューIDESMTPSAはTLS＋認証、ESMTPSはTLS、ESMTPは暗号化なし（RFC 3848）。unknownは逆引きできなかったことを示す- 時刻は時差をそろえて比べる。①の01:15:30 UTCは日本時間の10:15:30で、①→②が8秒、②→③が2秒。大きく空いた区間が遅延の場所
Receivedは誰でも書けるため、送信者が偽の行を下に足すことができます。信用できるのは、自組織のサーバーが付けた行から上だけです。受信側から見て「最初に自分に渡した相手」のIPアドレス（②の203.0.113.25）が、確かな送信元です。
MIMEの仕組み
日本語、HTML、添付ファイルは、MIME（RFC 2045〜2049）で扱います。
MIME-Version: 1.0とContent-Type（中身の種類）を宣言し、本文を部品（パート）に分けて入れる- 部品は
boundary=の文字列で区切り、入れ子にもできる - 代表的な組み合わせ
- multipart/mixed：本文と添付を並べる
- multipart/alternative：同じ内容のテキスト版とHTML版から、受信側が選ぶ
- multipart/related：HTMLと埋め込み画像をまとめる
- 添付かどうかは
Content-Disposition: attachmentで示し、日本語のファイル名はRFC 2231などで符号化する
メールソフトは入れ子をたどり、見せる部品と添付を選んでいます。
MIMEの実例と符号化の方式
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="b1_Xy7Zq"
--b1_Xy7Zq
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
5pys5pel44Gu5Lya6K2w6LOH5paZ44KS44GK6YCB44KK44GX44G+44GZ44CC
--b1_Xy7Zq
Content-Type: application/pdf
Content-Disposition: attachment; filename*=UTF-8''%E4%BC%9A%E8%AD%B0%E8%B3%87%E6%96%99.pdf
Content-Transfer-Encoding: base64
JVBERi0xLjcK…（以下省略）
--b1_Xy7Zq--部品は--boundaryで始まり、最後は--boundary--で閉じます。本文は「本日の会議資料をお送りします。」、添付のファイル名は「会議資料.pdf」を符号化したものです。
- base64：3バイトを4文字に変換する。大きさは約1.37倍（改行込み）。添付や日本語の本文に使う
- quoted-printable：ASCIIはそのまま、それ以外を
=E3=81=93のように書く。英語が中心の本文向け - 7bit・8bit：変換しない。8bitは相手が8BITMIMEに対応しているときだけ使える（第2回）
日本語のメール
冒頭の「件名が文字化け」の話です。ヘッダーの日本語は、次のように符号化して入れます。
Subject: =?UTF-8?B?5Lya6K2w44Gu5pel56iL44Gr44Gk44GE44Gm?=
Subject: =?ISO-2022-JP?B?GyRCMnE1RCRORnxEeCRLJEQkJCRGGyhC?=
$ echo '5Lya6K2w44Gu5pel56iL44Gr44Gk44GE44Gm' | base64 -d
会議の日程について
$ echo 'GyRCMnE1RCRORnxEeCRLJEQkJCRGGyhC' | base64 -d | iconv -f ISO-2022-JP -t UTF-8
会議の日程について
PS> [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('5Lya6K2w44Gu5pel56iL44Gr44Gk44GE44Gm'))
会議の日程について- ヘッダーの日本語は、RFC 2047の
=?文字コード?B（base64）またはQ?符号化した文字?=の形で入れる。上の2行はどちらも「会議の日程について」 - 日本のメールは長くISO-2022-JP（JISコード、RFC 1468）が標準だったが、今はGmailなど多くのサービスやメールソフトがUTF-8で送る
文字化けの主な原因は次の3つです。
- 宣言した文字コードと中身の食い違い
- ISO-2022-JPに無い文字（①、㈱、半角カナなど）の混入
- 符号化せずにヘッダーへ生の日本語を入れる送信側の実装
Linuxではbase64 -dとiconv、WindowsではPowerShellの.NETのメソッドで、中身を確かめられます（Windows PowerShell 5.1では、コンソールの設定により日本語が化けて見えることがあります）。
国際化メールアドレス（SMTPUTF8）
山田@例え.jpのように、アドレスに日本語などを使えるようにするのが、国際化メールアドレス（EAI）です。
- 規格はRFC 6530〜6533で、SMTPではSMTPUTF8拡張（RFC 6531）を使う。送信側は相手のEHLOの応答にSMTPUTF8があることを確かめ、
MAIL FROM:<…> SMTPUTF8と宣言して送る - ドメイン部分だけなら、Punycode（
xn--で始まる形）で従来どおり運べる - @より左にASCII以外の文字があると、経路のすべてのサーバーが対応していなければエラーになる
- Postfixは3.0から、Gmailは2014年、Microsoft 365は2018年から、こうしたアドレスとの送受信に対応している
業務用のアドレスにはまだ勧めにくいものの、受け付ける側のシステムは弾かないように作ります。
ヘッダーの見方（Outlook・Gmail・Thunderbird）
| メールソフト | 手順 | 補足 |
|---|---|---|
| 従来の Outlook（Windows） | メールをダブルクリックで開く →「ファイル」→「プロパティ」→「インターネット ヘッダー」 | 欄が狭いので、全選択してコピーし、メモ帳に貼って読む |
| 新しい Outlook・Outlook on the web | メールの「その他のアクション」（…）→「表示」→「メッセージの詳細を表示する」 | 同じ画面からコピーできる |
| Gmail（パソコン） | 返信アイコンの横の「その他」→「メッセージのソースを表示」 | 「クリップボードにコピー」でヘッダーごとコピーできる |
| Thunderbird | 「表示」→「メッセージのソース」（Ctrl+U） | 「表示」→「ヘッダー」→「すべて」でも見られる |
- 利用者から調査を頼まれたら、転送ではなくヘッダーのコピーをもらう。普通に転送すると元のヘッダーが失われる（従来のOutlookなら「添付ファイルとして転送」なら残る）
- まずAuthentication-ResultsとReceivedを見る。迷惑メール扱いの理由は、
X-で始まる製品独自のヘッダー（Microsoft 365のX-Forefront-Antispam-Reportなど）にあることが多い
ヘッダーを解析するWebのツールもありますが、ヘッダーには社内のサーバー名やIPアドレス、利用者のアドレスが含まれます。外部のサイトに貼り付けてよいかは、社内のルールに従ってください。
考えてみよう
- 最近受け取ったメールのヘッダーを表示して、Receivedを下から上へたどってください。何台のサーバーを経由し、どの区間に時間がかかっていますか。
- 同じメールのReturn-PathとFromを比べてください。違っている場合、それはなぜだと思いますか。Authentication-Resultsの結果はどうなっていますか。
- 取引先から「件名が文字化けしている」と言われました。どのヘッダーを見て、どんな原因を疑いますか。
ヒント：この記事の「エンベロープとヘッダーの対応」「Receivedヘッダーの読み方」「文字化けの主な原因」が手がかりです。
まとめ
- メッセージはヘッダー＋空行＋ボディ。画面の件名や差出人は、ヘッダーを整えて見せているだけ
- 差出人・宛先は封筒（エンベロープ）と便箋（ヘッダー）の2組。配達を決めるのは封筒
- ヘッダーはすべて送信者の申告。画面の差出人が本物とは限らない
- Receivedは下から上へ。時差をそろえて比べ、自組織が付けた行から上だけ信用する
- 日本語・HTML・添付はMIME。文字化けは宣言と中身の食い違いなどが原因
- 調査を頼まれたら、転送ではなくヘッダーのコピーをもらう
次回は、SMTPの通信を守るポートと暗号化、送信者の認証（SMTP AUTHとOAuth 2.0）を扱います。
連載「メール入門」全12回
- メールが届くまで
- SMTPのやり取り
- メッセージの構造（この記事）
- ポートと暗号化・認証
- 送信ドメイン認証 前編
- 送信ドメイン認証 後編
- 迷惑メール対策と配信
- MTAの運用
- コマンドで調べる
- クラウドと現代のメール
- メールのトラブルシュート
- メールの設計演習
コメント