メールアドレス正規表現の正解はない｜RFC 5322の現実と妥協点

RFC 5322のフル仕様を厳密に表現する正規表現は数千文字。だから現場は「実用的な妥協」を選びます。

参照した一次情報

・RFC 5322「Internet Message Format」（IETF Standard Track／メールアドレス文法 addr-spec / local-part / domain 定義）
・RFC 5321「Simple Mail Transfer Protocol」4.5.3.1（local-part最大64オクテット、ドメイン最大255オクテット）
・RFC 2142「Mailbox Names For Common Services」（postmaster等の共通エイリアス義務）

そもそもメールアドレスとは何か

RFC 5322 はメールアドレスをlocal-part "@" domainと定義します。一見シンプルですが、それぞれが許容する文字の幅がとても広いのが厄介です。

・local-part：英数字＋特定の記号（! # $ % & ' * + - / = ? ^ _ ` { | } ~ .）、さらに引用文字列形式（"..."）も許容
・domain：ドット区切りのドメイン名（ラベル）、もしくはIPv4/IPv6リテラル（[192.0.2.1]のような形）

つまり「"a b@c"@example.com」のような奇怪なアドレスもRFC 5322では合法です。だから「完全な正規表現」は数千文字に膨れ上がります。

現場で使われる「実用的な正規表現」

実務ではRFC 5322の99%のケースをカバーする、よりシンプルなパターンを使います。

正規表現	カバー率	代表用途
/\S+@\S+\.\S+/	90%	ざっくり抽出
/[\w.%+-]+@[\w.-]+\.[A-Za-z]{2,}/	99%	本ツール採用
HTML5 input[type=email]	99%	ブラウザの入力検証

本ツールは2行目の現実的な正規表現を採用。引用文字列やIPリテラルは諦める代わりに、99%以上の実在アドレスを取り出せます。

実際にヒットする・しない例

// 本ツールでヒットする
"info@example.com"          → ヒット
"first.last@example.co.jp"  → ヒット
"name+tag@example.com"      → ヒット（gmail エイリアス形式）
"123@456.com"               → ヒット
"x@y.io"                    → ヒット（2文字TLD）

// 本ツールではヒットしない（RFC 5322 では合法）
"\"weird name\"@example.com"  → 引用文字列形式（諦め）
"user@[192.0.2.1]"          → IPアドレス指定
"user@localhost"            → TLDなし
"user@xn--p1ai"             → 2文字以上のTLDだが日本語ドメイン

// 明らかな誤り
"@example.com"              → local-partなし
"user@"                     → domainなし
"user@.com"                 → ラベル先頭ドット

抽出でよく起きるトラブル

・末尾の句読点まで取り込み：「info@example.com。」の「。」が混入しやすい。本ツールは末尾の句読点を自動で除外
・全角英数字の見逃し：ｉｎｆｏ＠ｅｘａｍｐｌｅ．ｃｏｍは半角化が必要
・HTMLエンティティ：info@example.comは事前にデコードが必要
・連絡先を保護する目的の置換：info[at]example[dot]comは機械抽出を避けるために行われる（=スパム対策）。本ツールは取得しない

RFC 5321/5322の長さ制限

RFC 5321（SMTP）の4.5.3.1は実装の上限を次のように定めます。

・local-part：最大64オクテット
・domain：最大255オクテット
・path全体（< local-part @ domain >）：最大256オクテット
・1行の長さ：本文1000オクテット、コマンド512オクテット

つまり「aaaaa...@example.com」のように local-part が65文字を超える場合、RFC 5321 では届かない可能性があります。本ツールは長さ制限を強制しませんが、検証は別途エンジニアにご相談ください。

正規表現で「有効性検証」は不可能

正規表現はあくまで「文字列の形」が正しいかを判定するもので、「実在するか」「到達できるか」は判定できません。

営業先リストとして使う場合は、SMTPの疎通確認、もしくは確認メールを送って受信があるかで「届くアドレスかどうか」を別途検証する必要があります。本ツールは「文章から取り出す」までを行います。

本ツールでの位置づけ

本ツール「メール・URL・電話番号抽出」は、RFC 5322のフル仕様ではなく「現実的に流通する形」のメールアドレスを優先するパターンを採用しています。具体的にはlocal-partに英数字＋. _ % + -を許容し、ドメインは英数字＋ハイフン＋ドット、TLDは2文字以上。

このパターンで、Gmailのエイリアス形式（name+tag@gmail.com）、ハイフンドメイン（co-jp.example.com）、サブドメイン付き（user@mail.dept.example.co.jp）まで含めて取り出せます。