RFC 6532 – 国際化メールヘッダー

Proposed Standard Core SMTP & Message Format Obsoletes RFC 5322 Published March 2026

ELI5: このRFC以前は、メールヘッダーに「Müller」のような名前や日本語の件名を書きたい場合、`=?UTF-8?B?...?=`のような読み取り不可能な形式にエンコードする必要がありました。RFC 6532は「UTF-8を直接使用するだけ」と言っています。From行は`田太郎 `をプレーンテキストで表示でき、Subjectはエンコーディングのトリックなしで任意の言語で記述できます。メールは、ワイヤ上の表示とスクリーン上の表示が同じです。

このRFCが存在する理由

元のメール形式(RFC 5322)はヘッダーフィールドをUS-ASCII文字に制限しています。件名、差出人表示名、アドレスコメントなど、ヘッダーに非ASCII文字を含めるには、送信者はRFC 2047エンコード語を使用する必要がありました。これはBase64またはQエンコードしたテキストを=?charset?encoding?...?=マーカーでラップする面倒なスキームです。

このシステムは機能しますが、読みやすさに欠け、正しく実装するのが困難で、使用可能な場所が限定されたヘッダーを生成します。例えば、RFC 2047エンコード語はメールアドレスのローカル部内では使用できません。

RFC 6532はRFC 5322を更新して、メールヘッダーでUTF-8を直接許可します。RFC 6531(SMTPエンベロープ用のSMTPUTF8)と組み合わせることで、アドレス、表示名、件名、その他のヘッダーがすべてエンコード処理を行わずにネイティブスクリプトを使用できる完全に国際化されたメールが実現します。

動作方法

メッセージはSMTPUTF8拡張機能(RFC 6531)を使用してSMTPで送信され、メッセージが国際化されたコンテンツを使用していることが示唆されます。
ヘッダーフィールドは、RFC 5322がテキストを許可する場所ならどこでも生のUTF-8オクテットを含むことができます。
ヘッダー内のメールアドレス(From、To、Cc、Reply-To)は、ローカル部とドメイン部にUTF-8文字を含むことができます。
メッセージヘッダーブロックのContent-Typeは、従来のmessage/rfc822の代わりに暗黙的にmessage/global(RFC 6532で定義)です。
RFC 6532をサポートする受信メールクライアントはヘッダーをネイティブに表示します。サポートしていないクライアントは生のUTF-8バイトを表示するか、ヘッダーの解析に失敗する可能性があります。

ヘッダーの例

従来のRFC 2047エンコードヘッダー対RFC 6532ヘッダー:

# 古い方法: RFC 2047エンコード語(ネット上では読みにくい) From: =?UTF-8?B?w4ltaWxpZSBEdXBvbnQ=?= <emilie@example.fr> Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?= To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <taro@example.jp> # 新しい方法: 生のUTF-8を使用したRFC 6532(人間が読める) From: Émilie Dupont <émilie@exemple.fr> Subject: 会議の確認 To: 田太郎 <田太郎@例.jp>

完全に国際化されたメッセージ:

From: 田太郎 <田太郎@例.jp> To: Émilie Dupont <émilie@exemple.fr> Subject: 会議の確認 Date: Wed, 11 Mar 2026 19:00:00 +0900 Message-ID: <20260311.001@例.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 来週の会議を確認します。

主な技術詳細

message/global対message/rfc822

RFC 6532は新しいMIMEタイプを導入します:message/global。これは機能的にはmessage/rfc822と同じですが、メッセージのヘッダーにUTF-8が含まれる可能性があることを示唆しています。メッセージがSMTPUTF8で送信される場合、添付されたメッセージと転送されたメッセージはmessage/rfc822の代わりにmessage/globalを使用する必要があります:

MIMEタイプ	ヘッダーエンコーディング	使用用途
`message/rfc822`	ASCIIのみ(非ASCIIの場合はRFC 2047)	従来のメール
`message/global`	UTF-8をネイティブで許可	国際化されたメール

UTF-8が許可される場所

RFC 6532は、RFC 5322がテキストを許可するすべてのヘッダーフィールド位置でUTF-8を許可します:

表示名: From: 田太郎 <taro@example.jp>
アドレスローカル部: To: <田太郎@example.jp>
ドメイン名: Cc: <user@例.jp>
非構造化フィールド: Subject: 会議の確認
コメント: From: user@example.com (山田太郎)

DKIM署名の注意事項

DKIM署名は特定のヘッダーをカバーします。これらのヘッダーに生のUTF-8が含まれる場合、署名と検証プロセスはバイトを正しく処理する必要があります。DKIMh=タグは署名するヘッダーをリストし、正規化は生のUTF-8バイトに適用されます。署名が一致するには、送信者と検証者の両方が同じバイト列を処理する必要があります。

後方互換性

RFC 6532メッセージは、RFC 5322のみを理解するメールシステムと下位互換性がありません。message/globalメッセージを受け取るが、RFC 6532をサポートしていないサーバーまたはクライアントは、以下のいずれかの可能性があります:

生のUTF-8バイトを表示する(ほとんどの最新クライアントはこれを合理的に処理します)
非ASCII文字を含むアドレスヘッダーの解析に失敗する
実装がUTF-8ヘッダーを処理しない場合、DKIM検証を破す

よくある間違い

エンベロープでSMTPUTF8を使用せずにRFC 6532ヘッダーを使用すること。SMTPセッションがSMTPUTF8パラメータを使用しなかった場合、非ASCII ヘッダーコンテンツにはRFC 2047エンコード語を使用する必要があります。RFC 6532ヘッダーはRFC 6531を介して送信された場合にのみ有効です。
同じヘッダーでRFC 2047と生のUTF-8を混在させること。メッセージごとに1つのアプローチを選択してください。SMTPUTF8を介して送信する場合は、生のUTF-8を使用してください。そうでない場合は、RFC 2047を全体を通して使用してください。これらを混在させると、解析の曖昧性が生じます。
国際化されたアタッチメントにmessage/rfc822を使用すること。UTF-8ヘッダーを含むメッセージを転送または添付する場合は、MIMEタイプとしてmessage/rfc822ではなくmessage/globalを使用してください。
Unicode正規化を無視すること。同じ視覚的文字は、Unicodeで複数のバイト表現を持つことができます。メールアドレスとヘッダーコンテンツで一貫してNFC正規化を使用して、マッチングと検証の失敗を防ぎます。
すべてのメールクライアントがUTF-8を正しくレンダリングすると仮定すること。最新のクライアントはUTF-8をよく処理しますが、古いまたは組み込まれたメールクライアントの中には、そうでないものもあります。重要なトランザクショナルメールの場合は、聴衆に従来のシステムのユーザーが含まれているかどうかを検討してください。
転送中にUTF-8ヘッダーを変更してDKIMを破すること。一部のメール処理システムはUTF-8テキストを正規化または再エンコードします。DKIM署名されたヘッダーへの変更は、Unicode正規化形式を変更するだけでも、署名を無効にします。

配信可能性への影響

国際的な受信者の表示が改善されます。ネイティブスクリプトの表示名と件名は、プロフェッショナルで信頼できるように見えます。ヘッダーのエンコードされたワードのちんぷんかんぷんは受信者を混乱させ、疑いを引き起こす可能性があります。
DKIMはUTF-8を正しく処理する必要があります。DKIMの実装がUTF-8ヘッダーに署名し、検証者が異なる方法で処理する場合(異なる正規化、異なるエンコーディング)、署名が失敗します。これは直接DMARC整列と配信可能性に影響します。
プロバイダーサポートが増加しています。Gmail、Outlook.com、その他の主要プロバイダーはRFC 6532ヘッダーをサポートしています。クリーンなUTF-8ヘッダーを含むメッセージは、これらのプロバイダーによって正しく表示されます。
完全に国際化されたアドレスに必須です。RFC 6532ヘッダーなしで、完全に国際化されたメールアドレスを持つことはできません。EAI採用が増加するにつれて、このRFCのサポートはグローバルユーザーに到達するために必須になります。
フォールバック戦略が重要です。配信可能性を最大化するには、message/globalバージョン(SMTPUTF8対応サーバー向け)と、ダウングレードされたRFC 2047バージョン(その他)の両方を生成してください。送信インフラストラクチャは、受信者の機能に基づいて選択する必要があります。