RFC 6531 – 国際化メールのためのSMTP拡張
このRFCが存在する理由
電子メールはASCIIの時代に設計されました。元のSMTP仕様（RFC 5321）は、電子メールアドレスとエンベロープコマンドを7ビットASCII文字に制限しています。これは英語では問題ありませんが、世界の大多数の言語を除外しています。田太郎@例.jpのような電子メールアドレスは単に不可能でした。
RFC 6531はSMTPUTF8拡張機能を定義します。これにより、SMTPエンベロープ（特にMAIL FROM、RCPT TO、およびEHLOドメイン）でUTF-8エンコーディングが可能になります。これは、Email Address Internationalization（EAI）として総称されるRFCのスイートの一部であり、国際化されたメッセージヘッダーのRFC 6532も含まれています。
この拡張機能により、Unicodeでサポートされるあらゆる表記体系にメールが開かれ、グローバルなメール採用に不可欠です。
動作方法
- クライアントは
EHLOを送信し、サーバーが機能リストでSMTPUTF8をアドバタイズしていることを確認します。 - 非ASCII アドレス（エンベロープ、ヘッダー、またはその両方）を使用するメッセージを送信する場合、クライアントは
MAIL FROMコマンドにSMTPUTF8パラメータを追加します。 MAIL FROMおよびRCPT TOアドレスに UTF-8文字を含めることができます。- メッセージヘッダーにはUTF-8を含めることもできます（RFC 6532に従って）。古いRFC 2047エンコード済み単語の回避策に代わります。
- 次のホップサーバーがSMTPUTF8をサポートしていない場合、送信サーバーはメッセージをダウングレードするか拒否する必要があります。国際文字を静かに削除することはできません。
SMTPの例
国際化されたアドレスを使用してメッセージを送信する：
主要な技術的詳細
SMTPUTおおF8パラメータ
MAIL FROM上のSMTPUTF8キーワードは、このメッセージが国際化されたコンテンツを使用していることを示します。次のいずれかに非ASCII文字が含まれている場合は、常に存在する必要があります。
MAIL FROMアドレス- 任意の
RCPT TOアドレス - メッセージヘッダー（From、To、Cc、Reply-Toなど）
SMTPUTF8パラメータが宣言されていない場合、エンベロープに非ASCII文字が含まれていると、サーバーはコマンドを拒否する必要があります。
ドメイン名：IDNとUTF-8
国際化されたドメイン名（IDN）は、Punycodeエンコーディング（例：пример.рфの場合はxn--e1afmapc.xn--p1ai）を使用して長年存在しています。SMTPUTF8により、ドメイン名のUTF-8形式をSMTPで直接使用できますが、Punycode（Aラベル）は有効なままです。DNSルックアップの場合、ドメインをA-label形式に変換する必要があります。
ダウングレードとフォールバック
SMTPUTおおF8の最大の課題は、それをサポートしていないサーバーとの相互運用性です。メッセージをSMTPUTおおF8以外のサーバーにリレーする場合：
- メッセージをダウングレードできる場合（例えば、表示名のみが非ASCII文字を含み、アドレス自体はASCII）、サーバーはダウングレード変換を実行できます。
- エンベロープアドレス自体が非ASCII文字を含む場合、ダウングレードは不可能です。メッセージはそのサーバーに配信できません。送信サーバーはバウンスを生成する必要があります。
認証との相互作用
電子メール認証メカニズムは、国際化されたアドレスの更新が必要です。
-
SPF：
MAIL FROMのドメインを使用します。ドメインが国際化されている場合、DNSルックアップのためにA-label形式に変換する必要があります。 - DKIM：ヘッダーに署名して検証します。SMTPUTF8では、ヘッダーに生のUTF-8を含めることができるため、DKIM実装はこれを正しく処理する必要があります。
- DMARC：ドメイン整列チェックでは、同じドメインのUTF-8形式とA-label形式の両方を考慮する必要があります。
一般的な間違い
-
SMTPUTおおF8パラメータを省略する。メッセージにアドレスやヘッダーに非ASCII文字が含まれている場合、
MAIL FROMコマンドにSMTPUTF8を含める必要があります。忘れるとサーバーがアドレスを拒否します。 - SMTPUTF8の普遍的なサポートを想定する。採用は増加していますが、普遍的ではありません。2025年現在、GmailやOutlookなどの主要プロバイダーはSMTPUTおおF8をサポートしていますが、多くの小規模なサーバーはサポートしていません。送信インフラストラクチャはフォールバックをスムーズに処理する必要があります。
- DNSルックアップ用にドメインを変換しない。SMTPUTF8を使用しても、DNSクエリには国際化されたドメインのA-label（Punycode）形式が必要です。SMTP エンベロープでUTF-8を使用できますが、MX/A/AAAAルックアップはASCII互換エンコーディングを使用する必要があります。
- 正規化なしで国際化されたアドレスを保存する。Unicodeは同じ文字に対して複数の表現を持ちます（例えば、合成形式と分解形式）。メールアドレスに対してNFC正規化を使用して、一貫した照合と重複排除を確保します。
- 静かに非ASCII文字を削除する。システムが国際化されたアドレスを処理できない場合、文字を削除してアドレスを静かに変更することは決してできず、クリーンに拒否する必要があります。それは受信者を変更します。
- バウンスアドレスを忘れている。送信者のアドレスが国際化されており、メッセージがバウンスする場合、バウンスもSMTPUTおおF8を介して送信される必要があります。バウンスパスがSMTPUTおおF8をサポートしていない場合、バウンスは失われます。
配信可能性への影響
- グローバルオーディエンスに到達する。SMTPUTF8サポートは、送信インフラストラクチャが最新で包括的であることを示します。国際化されたアドレスがより一般的になるにつれて、それらをサポートすることはベースライン期待になります。
- バウンス処理の複雑さ。国際化されたアドレスへのメッセージは、中間サーバーがSMTPUTおおF8をサポートしていない場合、異なる方法でバウンスする可能性があります。バウンス処理はASCIIおよびUTF-8アドレスの両方を処理する必要があります。
- 認証整列。SPF、DKIM、およびDMARCはすべて、国際化されたドメインで正しく機能する必要があります。UTF-8とA-labelテpresentations間の不一致により、虚偽の認証失敗が発生する可能性があります。
- 主要なプロバイダーのサポートは強いです。Gmail、Microsoft 365、および他の主要なプラットフォームはSMTPUTおおF8メッセージを受け入れます。国際化されたアドレスからの送信サポートが急速に拡大しています。
- 将来に対応する。非ASCII文字を使用する電子メールアドレスの割合は増加するだけです。今すぐSMTPUTおおF8サポートに投資することで、グローバル採用が増加するにつれて配信可能性のギャップを防ぎます。