RFC 5322 – インターネットメッセージフォーマット
このRFCが存在する理由
RFC 5322は、メールメッセージの構文を定義します。これはSMTPのDATAフェーズで送信されるテキストです。その前身であるRFC 822（1982年）は、最も古いインターネット標準の一つでした。RFC 5322は、より厳密な構文ルール、より明確な廃止構文の取り扱い、および最新の慣行への対応により、その形式を更新しました。
このRFCはメッセージ形式についてのみであり、メッセージがどのように転送されるか（それはRFC 5321）や、添付ファイルがどのように機能するか（それはRFC 2045とMIMEファミリー）については何も述べていません。ヘッダーフィールド、本文、およびアドレス、日付、メッセージ識別のルールを定義します。
動作方法
メールメッセージは、空白行で区切られた2つの部分に分割されます。
-
ヘッダーセクション：
名前: 値の形式の一連のヘッダーフィールド。CRLFで終了します。 - 本文： メッセージコンテンツ。単なる構造化されていないテキスト（MIMEは上に構造を追加します）。
メッセージ構造
必須ヘッダーフィールド
RFC 5322では、すべてのメッセージに以下のフィールドが含まれる必要があります。
| フィールド | 説明 | 例 |
|---|---|---|
From: |
メッセージの作成者 | From: Alice <alice@example.com> |
Date: |
メッセージが作成された時刻 | Date: Wed, 11 Mar 2026 15:30:00 -0500 |
加えて、すべてのメッセージはMessage-IDフィールド（グローバルに一意な識別子）を含むべきです。Message-IDなしのメッセージは、スレッド処理、重複排除、およびDKIM署名に問題を引き起こします。
一般的なヘッダーフィールド
| フィールド | 用途 |
|---|---|
To: |
主要な受信者 |
Cc: |
カーボンコピー受信者 |
Bcc: |
ブラインドカーボンコピー（配信前に削除） |
Subject: |
メッセージのトピック |
Reply-To: |
返信用アドレス（From:を上書きします） |
Sender: |
From:に複数の作成者が含まれている場合、または送信エージェントと異なる場合の実際の送信者 |
In-Reply-To: |
返信対象メッセージのMessage-ID |
References: |
スレッド処理用のMessage-IDのチェーン |
Message-ID: |
このメッセージのグローバル一意識別子 |
Return-Path: |
MAIL FROMから最終配信システムによって追加 |
Received: |
メッセージを処理する各サーバーによって追加されるトレースヘッダー |
主要な技術詳細
アドレス形式
RFC 5322では、2つの有効なアドレス形式が定義されています。
-
Addr-spec：
alice@example.com─ メールボックスのみ。 -
Name-addr：
Alice Smith <alice@example.com>─ 表示名と角括弧で囲まれたアドレス。
特殊文字を含む表示名は引用する必要があります。"O'Brien, Alice" <alice@example.com>のように。ローカルパート（@の前）は仕様では大文字と小文字を区別しますが、実際にはほぼすべてのメールシステムで大文字と小文字の区別なく扱われます。
日付形式
日付形式は特定で許容できません。
形式は曜日、DD Mon YYYY HH:MM:SS タイムゾーンです。曜日はオプションですが、慣例的です。タイムゾーンは「EST」のような名前ではなく、数値オフセット（-0500）である必要があります。仕様は廃止構文として古いタイムゾーン省略形を許容していますが、生成することはお勧めできません。
Message-ID形式
Message-IDはグローバルに一意である必要があり、次の形式に従います。
ベストプラクティスは、UUIDまたはタイムスタンプベースの一意部分を送信ドメインと組み合わせることです。<20260311153000.a1b2c3@mail.example.com>のように。
ヘッダーフォーディング
長いヘッダー値は、CRLFの後に少なくとも1つのスペースまたはタブ（空白）を挿入することで「フォーディング」できます。これにより、長い受信者リストまたはサブジェクト行を998文字の行制限内に保つことができます。
パーサーは、空白で始まる続行行を結合して「アンフォーディング」する必要があります。
トレースヘッダー
メッセージを処理する各メールサーバーはReceived:ヘッダーを先頭に追加します。これらはトップからボトムへのトレイルを形成します。最上位のReceived:ヘッダーは最後に追加されたものです。Return-Path:ヘッダーは最終配信システムによってのみ追加され、MAIL FROMからのエンベロープ送信者を含みます。
一般的な間違い
- Dateヘッダーが見つからないか形式が正しくない。 適切なDateヘッダーのないメッセージ、または日付が遠い過去や未来のメッセージに対してペナルティを科すスパムフィルターもあります。送信時に常に生成してください。
- Message-IDがない。 一意なMessage-IDがないと、返信が正しくスレッドされず、DKIM署名がフィールドをカバーしない可能性があり、一部のスパムフィルターがメッセージにフラグを付けます。
-
アドレス引用が正しくない。 コンマ、ピリオド、または特殊文字を含む表示名は引用する必要があります。
O'Brien, Alice <alice@example.com>は無効です。"O'Brien, Alice" <alice@example.com>である必要があります。 - BCCを誤って使用。 BCCヘッダーは送信前に削除する必要があります。BCC受信者をヘッダーに含めて配信すると、ブラインドカーボンコピーの目的が失われます。
- 行の長さを超える。 ヘッダー行と本文行は998文字を超えてはいけません。長いヘッダーにはヘッダーフォーディングを使用し、長い本文コンテンツには適切なMIMEエンコーディングを使用してください。
-
FromとSenderを混同。
Sender:ヘッダーは、実際の送信エージェントがFrom:作成者と異なる場合にのみ必要です。Fromと一致する冗長なSenderヘッダーを追加しないでください。不要であり、フィルターを混乱させる可能性があります。 -
タイムゾーン形式が正しくない。
-0500の代わりにESTを使用することは廃止構文です。常に数値オフセットを使用してください。
配信可能性への影響
- DKIM署名はヘッダーに依存します。 DKIM（RFC 6376）は特定のヘッダーフィールドに署名します。見つからないか形式が正しくないヘッダーは、署名が予期したものをカバーしていない可能性があり、メッセージが検証に失敗する可能性があります。
-
DMARC整合性チェックはFromヘッダーをチェックします。 DMARC（RFC 7489）は、
From:ヘッダーのドメインをSPFおよびDKIM結果と比較します。Fromヘッダーがないか一致しないと、自動的にDMARC失敗になります。 -
スレッド処理とユーザーエクスペリエンス。 適切な
Message-ID、In-Reply-To、およびReferencesヘッダーにより、メッセージが受信者のメールクライアントで正しくスレッドされることが保証されます。壊れたスレッド処理により、メッセージは非専門的に見えます。 - スパムフィルターヒューリスティック。 フィルターはRFC 5322準拠をチェックします。見つからない必須ヘッダー、形式が正しくない日付、および非標準の形式はすべて、スパムスコアを上げる負のシグナルです。
- 表示名スプーフィング。 メールボックスプロバイダーは、Fromアドレスが疑わしく見える場合の警告をますます表示しています。クリーンで一貫性のあるFromヘッダーを認識できる表示名で使用することで、開封率と信頼が向上します。