2026 Python 3.15.2で非ASCIIメールアドレスのエラーが出たら？

Python 3.15.2は2026年10月25日に公開されました。Python 3.15で非ASCIIメールアドレスを含むアドレスヘッダーを正確に平坦化できない場合、メール生成器はエラーになります。ただし、これはすべての国際化アドレスが送れないという意味ではありません。まず生成時のポリシーを切り分け、次にSMTPUTF8の対応を確認し、最後に管理下の受信箱で到着を検証します。

Python 3.15.xへ更新後、EmailMessageの直列化で停止した開発者向けです。
自社製品の国際化アドレス対応を確認するQA担当者や、SMTP送信経路の保守担当者にも役立ちます。

最終更新：2026年11月1日。Python 3.15.2の公開情報、Python 3.15の更新説明、email.policyおよびsmtplibの公式ドキュメントを確認しています。

Python 3.15.2の非ASCIIメールアドレスエラーは段階で切り分ける

Python 3.15の公式更新説明が示す対象は、非ASCIIメールアドレスを含むアドレスヘッダーを正確に平坦化できないケースです。本文に日本語がある場合や、表示名だけに日本語がある場合まで一律に失敗する、と広げて解釈しないでください。

エラーが出た場所を先に記録します。EmailMessageのas_bytes()などで失敗したなら生成・直列化段階、smtplibの送信呼び出しで失敗したならSMTP段階です。送信結果が成功でも、受信箱への到着は別途確認が必要です。

テスト対象	何を分けて見るか	主な確認点
ASCIIアドレス＋ASCII表示名	対照ケース	既存の生成・送信経路が動くか
ASCIIアドレス＋非ASCII表示名	表示名とアドレス本体	生成後ヘッダーの表示名の符号化
非ASCII文字を含むアドレス	EAIアドレス	パーサー、ポリシー、直列化
EAIアドレスをSMTP送信	サーバーの拡張対応	SMTPUTF8の広告、送信例外、受信結果

この比較では、テスト対象を自社製品または許可された環境に限定します。まずASCIIのみのケースを基準にし、表示名、アドレス本体、SMTP送信の条件を一つずつ変えると、原因を特定しやすくなります。

表示名の文字とアドレス本体を分離する

開発通知 <dev@example.test>のように、表示名だけに非ASCII文字があるケースと、アドレス本体に非ASCII文字を含むケースは別の条件です。前者では表示名がどう符号化されたか、後者ではアドレス自体を現在のポリシーで表現できるかを確認します。

ログに出力されたメール全体を見て原因を決めつけず、例外が発生した操作と、生成後に得られたアドレスヘッダーを照合します。EmailMessageを作る箇所、ポリシーを指定する箇所、as_bytes()などで直列化する箇所を含む最小再現例を残してください。表示名をASCIIに置き換えた対照ケースも作れば、問題が表示名かアドレス本体かを切り分けられます。

設定・処理	向いている確認	注意点
標準のSMTPポリシー	ASCIIアドレスや通常の表示名の基準確認	EAIアドレスを送れる保証にはなりません
`EmailPolicy.utf8`	UTF-8を使うヘッダー生成の設定確認	送信先サーバーのSMTPUTF8対応とは別です
`email.policy.SMTPUTF8`	SMTPUTF8を使うメッセージ生成の検証	受信サーバーや配送先まで対応する保証ではありません

Python 3.15のemail.policy公式説明では、EmailPolicy.utf8がEAI関連の選択肢として示されています。設定変更だけで送信経路全体が対応するわけではありません。プロジェクトで使うポリシーを明示し、生成されたヘッダーと対象のアドレスを確認してください。

EAIアドレスでは生成と送信の対応を別々に検証する

EAI（国際化メールアドレス）は、ASCIIだけで構成される従来のアドレスと同じ前提では扱えません。特にアドレス本体に非ASCII文字が含まれる場合は、表示名の符号化とは別に、アドレスの解析、メッセージポリシー、直列化を確認します。PythonのEmailMessage公式ドキュメントも、メッセージの生成・直列化を調べる際の基準になります。

SMTP送信では、SMTPUTF8が必要なアドレスを扱えるかをサーバー側で確認します。RFC 6531はSMTPUTF8拡張を定義しています。Pythonのsmtplib.SMTP.send_messageの説明では、必要なSMTPUTF8をサーバーが広告していない場合にSMTPNotSupportedErrorとなる境界が示されています。

直列化に成功したことは、SMTPサーバーが受け付けた証拠でも、受信箱に届いた証拠でもありません。例外、SMTP応答、受信側の確認を別々の記録として扱ってください。

自社製品の受信確認を同じ試行で記録する

次の手順なら、生成エラー、SMTP側の拒否、受信未確認を混同しにくくなります。

テスト対象を限定します。 自社製品か許可された環境を使い、実在する第三者のアカウント登録やメール送信には使いません。
アドレスの種類を記録します。 ASCIIアドレス、非ASCII表示名、EAIアドレスを分け、どの要素に非ASCII文字があるかを残します。
直列化を単独で実行します。 SMTP接続より前にメッセージを生成し、例外の型、発生した操作、ポリシー、生成結果を保存します。
SMTPの対応を確認します。 対象サーバーがSMTPUTF8を広告しているかを確認し、send_messageの例外または応答を記録します。
管理下の受信箱を確認します。 同じテストの宛先でメールが実際に受信されたか、ヘッダーと本文が想定どおりかを確認します。
結論を条件付きで残します。 Pythonの版、アドレス種別、使用ポリシー、送信先の能力、受信結果を紐付け、検証していない組み合わせまで対応済みとしないでください。

使い捨ての受信先を検証に使う場合も、一般的な受信テストがEAIアドレスへの対応を証明するわけではありません。受信先が対象のアドレス形式を扱えるかを別に確かめます。受信先の露出や利用条件は、受信先の公開範囲を確認する案内やプライバシーに関する案内も確認し、テストデータに実在の個人情報を含めないでください。

エラーの位置に応じて次の確認先を選ぶ

表示名だけが非ASCIIなら、まずアドレス本体をASCIIの対照ケースにして、ヘッダーの生成結果と符号化を比較します。アドレス本体がEAI形式なら、アドレス解析とEmailPolicy.utf8の設定を確認し、SMTPUTF8対応を別の条件として記録します。サーバーが必要な拡張に対応しない場合は、送信サービスの能力やアドレス要件を見直します。具体的な修正は利用中の依存関係と送信サービスに合わせてください。

FAQ

Python 3.15で非ASCIIアドレスを扱うとき、なぜエラーになることがありますか？

Python 3.15の更新説明では、非ASCIIのメールアドレスを含むアドレスヘッダーを正確に平坦化できない場合、メール生成器がエラーを送出すると説明されています。本文や表示名に非ASCII文字があるだけで必ず失敗する、という意味ではありません。まず例外がEmailMessageの直列化時か、SMTP送信時かを分けてください。

EmailMessageの直列化に失敗したら、何を確認すればよいですか？

最初に例外が発生した操作を特定し、FromやToなどのアドレスヘッダーを表示名とメールアドレス本体に分けて確認します。次に、使用中のポリシーとEmailPolicy.utf8の設定を記録し、ASCIIアドレスだけの対照ケースと比較します。メール全体のログだけで判断せず、最小の再現コードと生成後のヘッダーを保存します。

SMTPUTF8に対応していないサーバーへ送信すると、どうなりますか？

SMTPUTF8が必要な国際化アドレスを送る場合、サーバーが拡張を広告しているかが判断材料になります。Pythonのsmtplib.send_messageは、必要なSMTPUTF8がサーバー側で利用できない場合にSMTPNotSupportedErrorを送出します。これは送信要求の受け付けや実際の受信とは別の段階なので、例外とSMTP応答を記録してください。

メール生成が成功したあと、テストメールの到着はどう確認しますか？

生成成功は、メッセージを直列化できたことを示すだけです。送信処理の例外とSMTP応答を記録し、その後、管理下にある受信箱で対象メール、宛先、ヘッダー、本文を確認します。テスト記録には同じ試行のアドレス種別、使用ポリシー、送信結果、受信結果を結び付け、サーバーの受け付けを到着の証拠として扱わないでください。

Python側の直列化とSMTPサーバーの能力を確認した後は、実際の受信確認に管理下のテスト用受信先を使う方法もあります。MXTempは、登録や試用など自社製品のメール確認に使う選択肢の一つです。利用する場合はMXTempの受信先で扱える範囲を確認し、国際化アドレスへの対応や到着を前提にせず、受信結果を個別に検証してください。

よくある質問