どちらも、メールの中身の構造を知っていれば、すぐに説明できる現象です。前者は「エンベロープとヘッダー」の違い、後者は「日本語の符号化」の問題です。

第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回）。

エンベロープとヘッダーの対応

• Bccの仕組み：メールソフトはTo・Cc・BccのすべてをRCPT TOで伝え、ヘッダーからはBccの行を消して送る。だからBccの宛先にも届き、他の人には見えない
• ただし、1宛先だけの配送では、受信側のReceived:にfor <Bccの宛先>が記録されることがある。Bccの本人のメールには、自分宛てと分かる痕跡が残る
• Return-Pathは、最後に配送したサーバーがエンベロープFromを書き写したもの。ヘッダーのFromとは別物

「差出人は社内なのに、ログには別のアドレス」という食い違いは、配信サービスや転送では普通に起きます。調べるときは、ログ（封筒）とヘッダー（便箋）を並べて見ましょう。

主なヘッダー

作成者が付けるもの

これらはすべて送信者の申告で、受信側は原則として中身を検証せずに受け取ります。画面の差出人が本物である保証はありません。なお、Dateの+0900は日本時間であることを示し、メールソフトは受信者の時間帯に直して表示します。

配送・認証・配信で付くもの

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-Click

Receivedヘッダーの読み方

「メールが遅れて届いた」ときに、どこで時間がかかったかを調べるのが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はそのサーバーのキューID
• ESMTPSAは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つです。

1. 宣言した文字コードと中身の食い違い
2. ISO-2022-JPに無い文字（①、㈱、半角カナなど）の混入
3. 符号化せずにヘッダーへ生の日本語を入れる送信側の実装

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なら「添付ファイルとして転送」なら残る）
• まずAuthentication-ResultsとReceivedを見る。迷惑メール扱いの理由は、X-で始まる製品独自のヘッダー（Microsoft 365のX-Forefront-Antispam-Reportなど）にあることが多い

ヘッダーを解析するWebのツールもありますが、ヘッダーには社内のサーバー名やIPアドレス、利用者のアドレスが含まれます。外部のサイトに貼り付けてよいかは、社内のルールに従ってください。

考えてみよう

1. 最近受け取ったメールのヘッダーを表示して、Receivedを下から上へたどってください。何台のサーバーを経由し、どの区間に時間がかかっていますか。
2. 同じメールのReturn-PathとFromを比べてください。違っている場合、それはなぜだと思いますか。Authentication-Resultsの結果はどうなっていますか。
3. 取引先から「件名が文字化けしている」と言われました。どのヘッダーを見て、どんな原因を疑いますか。

ヒント：この記事の「エンベロープとヘッダーの対応」「Receivedヘッダーの読み方」「文字化けの主な原因」が手がかりです。

まとめ

• メッセージはヘッダー＋空行＋ボディ。画面の件名や差出人は、ヘッダーを整えて見せているだけ
• 差出人・宛先は封筒（エンベロープ）と便箋（ヘッダー）の2組。配達を決めるのは封筒
• ヘッダーはすべて送信者の申告。画面の差出人が本物とは限らない
• Receivedは下から上へ。時差をそろえて比べ、自組織が付けた行から上だけ信用する
• 日本語・HTML・添付はMIME。文字化けは宣言と中身の食い違いなどが原因
• 調査を頼まれたら、転送ではなくヘッダーのコピーをもらう

次回は、SMTPの通信を守るポートと暗号化、送信者の認証（SMTP AUTHとOAuth 2.0）を扱います。

連載「メール入門」全12回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造（この記事）
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール
11. メールのトラブルシュート
12. メールの設計演習