送信ドメイン認証 その2：メール送受信の仕組みとメールの形式

メールセキュリティ強化策

送信ドメイン認証　その2
メール送受信の仕組みとメールの形式

情報セキュリティG　新井　全勝

　送信ドメイン認証の詳細に進む前に、メールの送受信の仕組みとメールの形式について、概観を見ておきましょう。

メール送受信の流れ

　メールは日常的に使われる通信手段であるが、その裏側の仕組みは意外と知られていない。本稿では、メールがインターネット上をどのように送受信されるのかを追いながら、メール形式についても解説する。

1. 送信者は、MUA（Mail User Agent）―――メールソフトウエアを用いてメールを作成し、送信操作を行う。この操作により、メールはヘッダと本文などから構成される形式に整形される。
   　具体的には、送信者のメールアドレス（From: user1@example.com）、宛先（To: user2@example.jp）、件名（Subject: ご報告）、送信日時（Date: 2025年11月15日 14:32 JST）、およびメッセージ識別子（Message-ID: abc123@example.com）などを含むヘッダが構成される。
   　これらのヘッダ情報と本文は、SMTPプロトコル（通信規約）で送信可能なメッセージ形式としてまとめられ、次のステップへと渡される。
   　
2. MUAはSMTPプロトコルを用いて、送信者が契約しているプロバイダの送信サーバにあるMSA（Mail Submission Agent）へメールを送信する。投稿ともいう。
   　この通信には、STARTTLSやSMTP over SSLなどの方式による暗号化※1 が施され、通信中の盗聴を防止する役割を果たす。
   　
3. MSAは、送信者の認証情報を確認した上で、受け取ったメールを整形し、送信サーバ上の送信側MTA（Mail Transfer Agent）へメールを渡す。
   　
4. 送信側MTAは、メールの宛先に応じて適切な経路を選択し、インターネット上の複数の中継サーバを経由して、受信者のメールサーバ（受信サーバ）の受信側MTAへとメールを配送する。
   　その際に、送信側MTAはDNS（Domain Name System）に問い合わせを行い、宛先ドメインのMXレコードを取得する。得られたホスト名※2 をもとにIPアドレスに変換し、宛先の受信サーバを特定する。
   　
5. 送信側MTAは、取得したIPアドレスを用いて、SMTPプロトコルにより宛先の受信側MTAへメールを送信する。
   　通信路の暗号化は、宛先の受信側MTAがSTARTTLSなどの暗号化方式に対応している場合にかぎり行われる。
   　
6. 受信側MTAは、送信されたメールを受け取り、MDA（Mail Delivery Agent）に引き渡す。
   　また、受信側MTAは、SMTPセッション中に送信者情報（MAIL FROM）および宛先情報（RCPT TO）を受信する。これらの情報は、郵便手紙の封筒になぞらえてエンベロープ情報と呼ばれ、配送制御に用いられる。メール本文のヘッダ情報（From, Toなど）とは別の階層で利用される。
   　
7. MDAは、受信したメールを受信者のMB（Mailbox）に格納する。これにより、メールは受信者の手元に届く準備が整った状態となる。
   　
8. 受信者は、自身のMUA（Mail User Agent）―――メールソフトウエアを用いて、POP3やIMAP、あるいはPOL（Post Office Layer）※3　を通じて、契約しているプロバイダの受信サーバにあるメールボックスMBにアクセスする。メールを取り寄せると、画面上に「From」「To」「Subject」「本文」などの項目が表示され、受信者はその内容を閲覧する。

――――――――――――――
※1）通信路の暗号化：メール送信時に、MUAとMSA間、送信MTAと受信MTA間の通信内容（ヘッダ・本文・添付ファイルなど）をTLSなどの方式で暗号化する技術。これにより、通信中の盗聴を防止することができる。
※2）ホスト名：インターネット上の特定の機器やサービスを識別するための名称。たとえば「mail.example.jp」のように、ドメイン名に基づいて構成される。DNSを通じてIPアドレスに変換され、通信先が決定される。
※3）POL（Post Office Layer）：一部の日本国内プロバイダで採用されている独自のメール受信方式。POP3に類似するが、接続管理や認証方式に特徴がある。　
※４）メールシステム要素一覧（略号と機能・役割）

要素名	英語表記	機能・役割	備考
MUA（送信者）	Mail User Agent	メールを作成し、送信者のプロバイダの送信サーバに送信するためのソフトウエア	・Outlook、Thunderbird、Webメールなど ・SMTP通信で送信
MSA	Mail Submission Agent	MUAから送られたメールを受け取り、MTAに配送する	SMTP通信で受信
MTA（送信側）	Mail Transfer Agent	メールを異なるシステム間で転送する役割をもち、メールの宛先ドメインをIPアドレスに変換し、宛先に応じてメールを振り分けて送信する	・DNSを参照して宛先ドメイン⇒IPアドレスに変換 ・SMTP通信で送信
MTA（受信側）	Mail Transfer Agent	送信側MTAとの間でコネクションを確立し転送されたメールを受信しMDAへ渡す	SMTP通信で受信
MDA	Mail Delivery Agent	MTAから受け取ったメールを受信者のメールボックスに格納する
MB（メールボックス）	Mailbox	受信者のメールが保存される場所。MSPOOL（メールスプール）ともいう
MUA（受信者）	Mail User Agent	メールを受信者のプロバイダの受信サーバにあるメールボックスより取り出し、表示するソフトウエア	POP3 / IMAP / POLでMBにアクセス
DNS	Domain Name System	メールアドレスのドメイン名からMXレコードを取得し、IPアドレスに変換する	メール配送先の特定に使用
SMTP	Simple Mail Transfer Protocol	メールを相手先に送り届ける配送手順を定めた通信規約。メール配送では、メールを送りたい側（送信側）が、メールを届けたい先（受信側）に接続を要求し、受信側が受理することにより、一連の配送手続きが行われる。この一連の手続きはSMTPセッションと呼ばれる。 　送信者情報や宛先情報がヘッダとは別に送信される。 MUA・MSA間、送信MTA・受信MTA間の通信に使用される。
POP3	Post Office Protocol version 3	メール受信に用いられる通信規約。メールをダウンロードして閲覧する方式。
IMAP	Internet Message Access Protocol	メール受信に用いられる通信規約。サーバ上のメールを同期して閲覧する方式。
POL	Post Office Layer	一部国内プロバイダで用いられる独自のメール受信方式。POP3に類似するが、認証方式に特徴がある。
要素名	英語表記	機能・役割	備考

　

メールの形式とヘッダの役割

(1) メールの形式

　インターネットメールは、「インターネットメッセージ形式」の規格に準拠し、以下の2つの主要部分から構成される。

　本文部は MIME（Multipurpose Internet Mail Extensions）に準拠しており、単一コンテンツ形式・複数コンテンツ形式・添付ファイルを扱える柔軟な構造を持っている。形式指定は Content-Type フィールドで行われ、表示互換性やセキュリティ評価に影響します（詳細は次節参照）。
　なお、ヘッダ部と本文部の境界は、1行の空行によって明示される。

(2) メールの本文部 ― MIMEの基本構造と運用分類

　インターネットメールの本文部は、ASCII文字コードをベースに発展してきた。MIMEは、日本語などの非ASCII文字や複数パート形式、添付ファイルを統合的に扱えるようにするための拡張仕様であり、現在のメールの多様性を支える基盤技術である。

① MIMEの構造と主要フィールド

　MIMEは本文部を複数の「パート」に分割し、それぞれに Content-Type や Encoding を指定することで、テキスト・画像・添付ファイルなどを取り扱う取り扱う。

② Content-Typeの例

③ Content-Transfer-Encodingの例

　メールはASCIIベースの通信を行うため、非ASCII文字やバイナリデータはエンコードして送信する必要がある。

(3) メールヘッダの役割

　メールヘッダは、以下の機能を担う制御情報群である。

(4) ヘッダ内容の分類と主要フィールド一覧

　ヘッダは「フィールド名: 値」の形式で記述され、改行で区切られます。配置順は厳密ではありませんが、一般的には以下の順序に並びます。

　下記に主要フィールドの一覧を示します。

分類	フィールド名	説明	備考
送信者情報	From	送信者のメールアドレス	送信者の入力情報に基づき、送信側メールソフト（MUA）が設定
宛先情報	To	宛先のメールアドレス
	Cc	同報送信先（カーボンコピー）
	Bcc	非表示同報送信先。通常ヘッダには表示されない
表示情報	Subject	件名（タイトル）
	Date	送信日時
	Reply-To	返信先アドレス（Fromと異なる場合）
識別・スレッド管理【注1】	Message-ID	メールの一意識別子（グローバルにユニーク）	メッセージの一意性と連続性を保持
	In-Reply-To 【注2】	返信元メッセージのID	スレッド管理に使用
	References 【注3】	関連メッセージID	スレッド履歴の保持
本文形式・構造	Content-Type	本文の形式（例：text/plain, text/html, multipart/mixed）	MIME準拠
	MIME-Version	MIMEのバージョン（通常は1.0）
	Content-Transfer-Encoding	本文のエンコード方式（例：7bit, base64）
配送・認証履歴	Return-Path 【注４】	配送エラー時の通知先メールアドレス	受信サーバ（MTA）が追加
	Received	メールが通過したサーバの履歴
	Authentication-Results	SPF/DKIM/DMARCの認証結果
	DKIM-Signature	DKIMによる電子署名
	DKIM-Signature: d=ドメイン	電子署名を生成したドメイン名。公開鍵の登録時にDNSに登録
	ARC-Seal	ARCの封印署名。対象はARC-Authentication-Results、ARC-Message-Signature、過去のARC-Seal
	ARC-Message-Signature	ARCのメッセージ署名。対象はその中継時点で観察されたメッセージ
	ARC-Authentication-Results	ARCの認証結果履歴
補助・拡張	X-Header	独自拡張ヘッダ（例：X-Mailer, X-Originating-IP）	任意・システム依存

――――――――――――――――――
注1）識別・スレッド：スレッドとは、メールのやり取りの連糸
注２）In-Reply-To：返信元の Message-ID を記録することで、メールのやり取りの連続性（スレッド）を保持する。メールソフトはこの情報をもとに、階層表示を行う。
注3）References：過去の関連　Message-ID　を列挙することで、スレッド履歴全体を保持する。複数の返信が連鎖する場合に、全体の流れを追跡可能にする。
例：References: msgid1@example.com msgid2@example.com msgid3@example.com
注４）Return-Path：
SMTPでメール送信時、 コマンドで指定されたメールアドレスが Return-Path となる。これは Envelope From とも呼ばれ、SPF評価の対象となる。メールソフトのユーザ名が引き継がれる。

メール形式の例

このように、ヘッダ部が先に並び、空行を挟んで本文が続くのが基本構造である。

　

参考文献

1）送信ドメイン認証技術導入マニュアル　第3.1版　迷惑メール対策推進協議会
　　2024年8月発行　一般財団法人　日本データ通信協議会

2） 迷惑メール白書　2022－2024　迷惑メール対策推進協議会
　　2024年8月発行　一般財団法人　日本データ通信協議会