「+」付きメールアドレスは本当に使っていいのか？RFC 5322はOKでも、現実の壁は厚かった

はじめに

メールアドレスに「+（プラス）」を含めて使うこと、開発者の方なら一度は聞いたことがあるはずです。たとえば、次のようなアドレス

user+test@example.com

技術的にはまったく問題ありません。実際、メールアドレスの構文を定義する RFC 5322 においても、「+」はローカルパート（@の前）で有効な文字とされています。

RFC 5322: Internet Message Format

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer use...

datatracker.ietf.org

しかしながら、現実にはこの「+」を使ったアドレスが通らなかったり、届かなかったり、ログインできなかったりするケースが意外なほど多いのです。この記事では、技術仕様と現実のギャップについて深掘りし、「+」をメールアドレスに使うことの是非を常識的な観点も交えて検討していきます。

RFC 5322では「+」は問題なし

RFC 5322（インターネットメッセージ形式の標準仕様）によると、メールアドレスのローカル部には以下のような記号が利用可能です

! # $ % & ' * + - / = ? ^ _ ` { | } ~

このうち「+」も当然含まれており、仕様的には何ら問題ありません。多くのメールサービス、特に Gmail はこの「+」を「エイリアス」として扱い、たとえば user+shopping@gmail.com というメールは user@gmail.com に届きます。

こうした「+」の利用は、メールの振り分けやスパムの特定など、非常に便利な技術的テクニックとして知られています。

しかし、現実にはこんな問題がある

登録フォームで「+」が弾かれる

多くのWebサービスでは、メールアドレスのバリデーションがRFCに準拠しておらず、「+」が含まれているだけでエラーになることがあります。例：

• 「無効な文字が含まれています」
• 「正しいメールアドレスを入力してください」

なぜこのようなことが起きるかというと、正規表現のバリデーションが間違っている、もしくは意図的に「+」などの特殊文字を禁止している場合があるからです。

メール配信システムで弾かれる

「+」付きメールアドレスが一部のメール配信サービスや古いメールサーバでエラーになることもあります。原因としては：

• メールアドレスのサニタイズ処理のバグ
• 独自仕様のSMTPサーバーでの対応漏れ
• 特殊文字の扱いがメールシステムで正しく実装されていない

ユーザーサポートで混乱を招く

たとえば、「ログインできません」という問い合わせでメールアドレスが example+aaa@gmail.com の場合、サポート側が「+aaa」を除いたアドレスと混同してしまうことがあります。また、口頭や紙媒体でのやり取りでは「プラス記号」を伝えるのが厄介です。

常識的な観点での「+」使用のリスク

技術者視点と一般ユーザー視点のズレ

開発者としては「+が使えないなんておかしい」と思うかもしれませんが、一般のユーザーやサービス提供者にとっては「例外的で面倒な記号」に映ります。つまり、「仕様上正しい」ことと、「現場で安全に使える」ことは別なのです。

フォールトトレランス（耐障害性）の欠如

重要な通知メール（パスワード再発行など）で届かないリスクがあるなら、それは十分なリスク要因です。仕様に従っているからといって、実害を無視できるわけではありません。

実際に問題が起きたとき、ユーザーの自己責任になる

「+」を含むメールアドレスが原因でアカウント登録できなかった場合、サービス側に責任を問うのは難しいケースもあります。仕様に従っていないフォームではあっても、多くのユーザーが問題なく登録できるなら、サポート対応も及び腰になるのが現実です。

セキュリティの観点から見た「+」付きメールアドレスの利点とリスク

セキュリティ的に有利な使い方

「+」付きアドレスは、スパム対策やサービスごとの識別に非常に役立ちます。たとえば

• user+amazon@example.com
• user+facebook@example.com

このように、どのサービスに登録したか一目で分かるようにすることで、以下のような利点があります：

1. データ流出の検知が容易
   たとえば、user+uniquesite@example.com でしか使っていないのにスパムが届いたら、そのサイトから情報が漏洩した可能性が高いと判断できます。
2. 不正なリスト転用の追跡
   メールアドレスの使い回しを業者に知られずに済み、漏れた時の特定も容易です。
3. フィルタリングによる整理や隔離が簡単
   Gmailなどでは「+」以降を条件にした自動振り分けが可能です。これにより、重要メールと通知メールを明確に分けて管理することができます。

セキュリティ上の潜在的リスク

ただし、セキュリティ面でプラス記号付きアドレスを使うことがリスク要因になる可能性もあります。

1. 「+」の有無を識別情報に使ってしまう実装ミス
   サービス側がメールアドレスを一意の識別子（主キーやログインID）として扱う場合、user@example.com と user+shop@example.com を別人と判断してしまうことがあります。
   これが原因で アカウントの重複登録・乗っ取りの原因になることも。
2. パスワードリセットURLが「+」付き宛に届かない場合
   仮にサービス側で「+」を除去してメール送信した場合、正規のメールアドレスに届かず、ユーザーがパスワードリセットできなくなるケースがあります。これがセキュリティの「可用性」を損ねるリスクになります。
3. メールアドレスを加工して使い回す悪意ある攻撃者
   フィッシングやリスト型攻撃で、ドメインだけで一致するメールをかき集める際に、「+」を使った無数のエイリアスを作ってWebサイトの入力検証を回避する目的で使われる場合もあります。

セキュリティの視点

セキュリティの観点でも「+」は諸刃の剣

正しく使えば強力な武器、でも対応していないシステムでは足かせに。

セキュリティ意識が高い開発者やユーザーほど「+」を使いたくなりますが、それを受け入れる側（サービス運営者）の実装ミスや設計ミスによって、逆にリスクになる可能性がある──。
この点を理解しておくことが、より健全で安全なWebサービス運営につながるはずです。

結論：「+」は技術的にはOK、でも実務では避けた方が無難

メールアドレスに「+」を使うかどうかの判断は、利用する相手や場面に合わせたリスク評価が重要です。技術的には問題なくても、社会的・運用的には「避けるのが賢明」というのが現場感覚としての結論です。

おわりに

「仕様上は問題ないのに、現実では使えない」──こうしたギャップは、エンジニアや運営者にとって永遠のテーマかもしれません。本記事が、そんな実務上の落とし穴を避ける一助になれば幸いです。