RFC 5322: メールのメッセージ形式

このRFCが決めたこと

横にスクロール

RFC 5322（2008年10月、P. Resnick編）は、電子メールの「メッセージそのもの」の書式を定める現行仕様だ。正式名称はInternet Message Format。系譜は2001年4月のRFC 2822、その前は1982年8月のRFC 822まで遡る。ヘッダ名の登録簿にあたるRFC 4021を更新し、2013年のRFC 6854による小さな追補を受けた以外、40年以上ほぼ同じ形のまま世界中のメールを支えている。

押さえるべきは分業だ。5322が決めるのは便箋の書き方、つまりヘッダと本文の並べ方だけで、そのメッセージをサーバー間でどう運ぶかは同時に発行されたRFC 5321: SMTPの担当になる。範囲は驚くほど狭い。5322自身が定義するのはUS-ASCIIのテキストメッセージだけで、添付ファイルもHTMLメールも日本語も、すべて他の仕様に委ねられている。

要点の精読

ヘッダ、空行ひとつ、本文

メッセージの構造は拍子抜けするほど単純だ。Name: value の形のヘッダフィールドが並び、何も書かれていない空行が1つ入り、その後ろが本文になる。行の区切りはCRLF（CRの13とLFの10）で、本文の終わりまでこの規則は変わらない。ヘッダと本文を分けるものは空行1つだけなので、ヘッダを組み立てるコードが余計な空行を1つ挟むと、以降のヘッダはすべて本文の文字列に化ける。

Return-Path: <dev-list-bounces@lists.example.jp>
Received: from lists.example.jp (lists.example.jp [198.51.100.7])
        by mbox.example.net with ESMTPS id 4a1f2c
        for <hanako@example.net>; Fri, 17 Jul 2026 12:00:03 +0900
Received: from smtp.example.jp (smtp.example.jp [192.0.2.25])
        by lists.example.jp with ESMTP id 9be014;
        Fri, 17 Jul 2026 12:00:01 +0900
Date: Fri, 17 Jul 2026 11:59:58 +0900
From: Taro Yamada <taro@example.jp>
Sender: <dev-list-bounces@lists.example.jp>
To: dev-list@lists.example.jp
Subject: =?UTF-8?B?44Oh44O844Or44Gu5b2i5byP?=
Message-ID: <20260717115958.9be014@example.jp>
In-Reply-To: <20260716.4a1f2c@example.net>
References: <20260715.0001@example.net>
        <20260716.4a1f2c@example.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

（ここから本文）

行の長さには2つの上限がある。CRLFを除いて998文字を超えてはならず（MUST）、78文字以内が推奨される（SHOULD）。この2つは強さが違うだけでなく、理由がまったく別だ。998は送受信や保存を行う実装側の限界で、RFC 5321がテキスト行をCRLF込み1000オクテットまでと定めていることと表裏一体になっている。一方の78は表示幅の話で、これを超えると端末やメールソフトの画面で無残に折り返される、という当時のUI事情に由来する。MUSTとSHOULDの使い分けはRFC 2119: 要求レベルのキーワードの通りで、998は破ると壊れる、78は破っても届く。

では長いヘッダはどうするのか。ここで折りたたみ（folding）が登場する。仕様がFWS（folding white space）を許す位置にCRLFを挿入し、続きの行を空白かタブで始めてよい、という規則だ。上のサンプルでReceived:やReferences:が複数行にまたがっているのがそれで、見た目は複数行でも論理的には1つのフィールドである。逆向きの操作が展開（unfolding）で、定義は拍子抜けするほど機械的だ。直後にWSPが続くCRLFを削除するだけでよい。ヘッダを読む側が最初にやるべき仕事がこれになる。

エンベロープのFromとヘッダのFrom

5322を読むうえで最大の山場がここだ。SMTPが配送先と返送先を決めるのに使うのは、セッション中のMAIL FROMとRCPT TOで渡されるエンベロープ情報だけで、メッセージ冒頭のFrom:やTo:は一切参照されない。郵便に置き換えると、配達員が見るのは封筒の宛名で、便箋のレターヘッドに誰の名前が刷ってあろうと配達には関係ない、ということになる。

そして決定的なのは、この2つを一致させる仕組みが元々どこにも無いという点だ。From:はメッセージの作成者が自分で書く自己申告の項目にすぎない。だからFromなりすましは攻撃ですらなく、仕様通りの操作として成立してしまう。

ただし、エンベロープの情報がメッセージに一切残らないわけではない。最終配送を行うMTAは、MAIL FROMで受け取った逆経路の値をReturn-Path:ヘッダとしてメッセージの先頭に書き込むことがRFC 5321で義務づけられている。エンベロープとヘッダという2つの世界をつなぐ唯一の物理的な接点がこのフィールドで、受信箱に届いたメールでエンベロープ差出人を確認できるのは、この写しのおかげだ。

後付けされた送信ドメイン認証は、この構造をなぞって役割を分けている。SPF（RFC 7208）が検証するのはRFC5321.MailFromのドメイン、つまりエンベロープ側だ。DKIM（RFC 6376）はメッセージ自体に署名し、署名したドメインをd=タグで名乗る（From:への署名は必須とされている）。そしてDMARC（RFC 7489）は、SPFやDKIMで認証されたドメインがRFC5322.Fromのドメインと一致していることを要求する。これがアライメントで、要するに「封筒と便箋の名前を突き合わせろ」という後付けの規律にほかならない。個々の仕組みの詳細はセキュリティ側の記事群に譲る。

アドレス構文と、メール正規表現という幻想

アドレスの基本形はTaro Yamada <taro@example.jp>のような表示名＋山括弧で、taro@example.jpのように山括弧なしで書くこともできる。To:やCc:にはこれをカンマ区切りで並べる。ここまでは誰でも知っている話だが、5322の文法はここから斜め下に伸びていく。

@の左側（local部）は、ドット区切りの英数記号だけでなく引用文字列でもよい。つまり"a b"@example.com——空白を含むアドレスは完全に合法だ。右側（domain部）にはドメイン名のほか、user@[192.0.2.1]のようなドメインリテラルが書ける。さらにCFWSの規則により、アドレスの中に丸括弧のコメントを差し込める。極めつけは、コメントの中にコメントを入れられることだ。文法上、入れ子の深さに上限がない。

この一点が効いてくる。入れ子が無限に深くなりうる構文は、形式言語の分類でいえば正規言語ではない。つまり純粋な正規表現では原理的に書けない。よく引き合いに出される「RFC準拠のメール正規表現」が数千文字に膨れ上がるのは、この文法を有限の深さで力ずくで近似しているからだ。当サイトの正規表現パターン集も同じ結論に立っていて、実務では@が1つあることを確認する程度の割り切った式に留めるのが正解になる。

割り切っているのは実装者だけではない。HTML仕様のinput type="email"は、自前の簡素な正規表現を定義したうえで、これはRFC 5322に対する意図的な違反（willful violation）だと明言している。理由も率直で、5322の構文は@の手前については厳しすぎ、@の後ろについては曖昧すぎ、そしてコメントや空白や引用文字列を許す点では緩すぎて実用に耐えない、という趣旨のことが書かれている。ちなみにdomain部が実在するかどうかは5322の管轄外で、そこはDNSに問い合わせる世界だ（RFC 1035: DNSを参照）。

運用で効くヘッダ

まず驚くべき事実から。5322が必須としているヘッダは2つしかない。発信日時のDate:と、作成者を示すFrom:だけで、それ以外は構文上すべて省略可能だ。To:もSubject:もMessage-ID:も、仕様上は無くてよい。

とはいえMessage-ID:は「あるべき」（SHOULD）とされ、実際にはスレッド表示の背骨として働いている。<左辺@右辺>の形で、グローバルに一意であることを生成したホストが保証する。返信を作るときは、親のMessage-ID:をIn-Reply-To:に入れ、References:には「親のReferences:の内容＋親のMessage-ID:」を連結する。この積み上げがあるからこそ、メールソフトは会話の木を再構成できる。逆に言えば、途中の装置がMessage-ID:を書き換えるとスレッドはそこで切れる。

Date:の書式はFri, 17 Jul 2026 11:59:58 +0900のように曜日と月名が英語3文字で固定されている。ここには面白い決まりがあって、+0000は「UTCである」、-0000は「UTCだが、生成したシステムのローカルタイムゾーンは不明」を意味し、両者は同じ時刻を指しながら含む情報が違う。

From:とSender:の使い分けも押さえておきたい。Sender:は実際に送信した主体を示すもので、著者と送信者が同一なら書くべきではない。ただしFrom:に複数のメールボックスを並べた場合、Sender:は必須になる。冒頭のサンプルがまさにこの構図で、著者はTaroだがメーリングリストのソフトウェアが送信しているためSender:とReturn-Path:がリストのアドレスになっている。なお2013年のRFC 6854は、返信を受け付けられない自動送信システムのためにFrom:へグループ構文を許し、From: Automated System:;のようにアドレスを1つも持たないFrom:を書けるようにした。

最後にReceived:だ。メッセージを受け取ったサーバーは、通過の記録をメッセージ先頭に追記していく。追記は常に先頭なので、上にあるものほど新しい。ヘッダを上から読むと配送経路を逆順に辿ることになり、逆に一番下のReceived:が最初の投稿地点に近い——この読み方が、配送遅延やなりすましを調べるときの実地の技術になる。

RFC 5322がやらないこと

5322に適合するメッセージは、コード1〜127のUS-ASCII文字だけで構成される。0も、128以上も入らない。この一行が意味するところは大きい。日本語のメールも、添付ファイルも、HTMLメールも、5322の枠組みだけでは1文字たりとも送れないということだ。

MIMEの巧妙な点は、5322の構文を壊さずに拡張したことだ。Content-Type:などの新しいヘッダを足し、本文をBase64やquoted-printableでASCIIに符号化する。5322から見れば、それは相変わらずただのASCIIテキストにすぎない。

ヘッダの中身は本文と事情が違い、MIMEの転送符号化を使えない。そこで用意されたのがRFC 2047のencoded-wordで、サンプルの=?UTF-8?B?44Oh44O844Or44Gu5b2i5byP?=がそれだ。=?文字セット?符号化方式?符号化されたテキスト?=という形式で、Bはbase64、Qはquoted-printableに近い方式を指す。encoded-word1つは区切り記号込み75文字までという制限があるため、長い日本語のSubject:は複数のencoded-wordに分割されて折りたたまれる。日本語の件名が文字化けするとき、たいていはこの層のどこかが壊れている。

アドレスそのものを国際化するには、さらに別の仕組みが要る。encoded-wordが使えるのは表示名までで、@の左右は依然としてASCIIだからだ。ここを開いたのが2012年2月のEAI（Email Address Internationalization）で、RFC 6531がSMTPUTF8というSMTP拡張を、RFC 6532が5322のABNFの各トークン（atext、qtext、dtext、ctextなど）にUTF-8を追加する形で国際化ヘッダを定義した。ついでにRFC 6532は998文字という上限を998オクテットへ読み替えている。ASCIIでは文字とオクテットが一致するので問題にならなかった区別が、UTF-8では効いてくるためだ。なお78のほうは表示幅の指標なので、文字数のまま据え置かれた。

つまずきやすい点

第一に、ヘッダを行単位でsplitしてName: valueに分けるだけのパーサは、折りたたまれたフィールドで必ず壊れる。展開（直後にWSPが続くCRLFを削除する）を先に済ませてから解析するのが正しい順序だ。あわせて、998は行ごとの上限であってフィールド全体の上限ではないことにも注意したい。長いReferences:が数千文字になるのは、折りたたんでいる限り違反ではない。

第二に、仕様の§3だけを読んで作ったパーサは実メールで壊れる。5322には§4「廃止構文」という章があり、そこに載っている古い書式は生成してはならない（MUST NOT）が、受信側は受理して解釈しなければならない（MUST）と定められている。生成と解釈で要求を非対称にする、いわゆる寛容性の原則が仕様の構造そのものに埋め込まれているわけだ。1982年生まれの書式が今でも流れてくる以上、パーサの仕事は§3ではなく§4まで含めた範囲になる。たとえばタイムゾーンをMのような1文字で書く軍用ゾーンの廃止構文があるが、RFC 822での定義に誤りがあり意味が不定なため、5322はこれらを原則-0000と等価に扱うよう求めている。

第三に、Message-ID:を軽く見ないこと。仕様上は省略可能だが、省略したりゲートウェイで書き換えたりすれば、In-Reply-To:とReferences:による正しいスレッド化はその時点で成立しなくなる。メールソフトが件名の「Re:」を頼りにした推測へ落ちるのはその後始末であり、件名が同じだけの無関係なメールが1つの会話にまとまる事故はこうして起きる。

まとめ

RFC 5322が定めるのは、ヘッダ・空行・本文という構造、998と78という行長、折りたたみ、そしてアドレスとMessage-IDの構文——本当にそれだけだ。非ASCIIも添付も転送手順も潔く他の仕様へ譲り、40年以上その狭さを守り続けている。にもかかわらずこのRFCが重い意味を持つのは、ここで定義されたFrom:が、配送に使われるエンベロープから切り離された自己申告の値だからだ。RFC5321.MailFromとRFC5322.Fromを常に区別できるようになれば、SPFとDKIMとDMARCがそれぞれ何を守っているのか、なぜ3つとも必要なのかが1枚の図として見えてくる。ほかのプロトコルの精読はRFC精読から辿れる。