メールアドレスの正規表現｜実用パターンとチェックの注意点

メールアドレスの入力チェックには、「@の前に使える文字が1文字以上、@の後にドットで区切られたドメイン」という形を確かめる、ほどほどに緩い正規表現を使うのが実務の定番です。メールアドレスの仕様（RFC）は非常に複雑で、それを完全に再現する正規表現は現実的ではないうえ、厳しくしすぎると実在するアドレスを拒否してしまうからです。

そして、正規表現で確認できるのは「形式」だけです。そのアドレスが実在し、本人が受け取れるかは、確認メールを送らなければわかりません。この記事では、実用的な正規表現のパターンと、言語別の書き方、文字数の上限、日本特有の古い携帯のアドレス、処理が止まる危険な正規表現まで、実際に動かした結果とあわせて解説します。

まずは結論：実用パターン

パターン1：実用的なチェック（おすすめ）

^[A-Za-z0-9._%+-]+@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+[A-Za-z]{2,}$

パターン2：HTML5の入力欄と同じ基準

<input type="email"> がブラウザで使っている基準（HTMLの仕様で定められたもの）と同じパターンです。

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

画面側（HTML5の入力欄）とサーバー側で、同じ基準でチェックしたい場合に使います。ただし、user@localhost のようにドット（.com など）のないアドレスも通す点に注意します。

2つのパターンの判定結果

Pythonで実際に判定した結果です。

言語別の書き方

どの言語でも、文字列全体が一致することを確かめる書き方を使います（後述の「末尾の改行」の問題を避けるため）。

JavaScript

const EMAIL = /^[A-Za-z0-9._%+-]+@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+[A-Za-z]{2,}$/;

EMAIL.test("user@example.com");     // true
EMAIL.test("user@-example.com");    // false

ブラウザの入力欄なら、<input type="email" required> だけでも、HTML5の基準でのチェックができます。

Python

import re

EMAIL = re.compile(r"[A-Za-z0-9._%+-]+@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+[A-Za-z]{2,}")

bool(EMAIL.fullmatch("user@example.com"))     # True
bool(EMAIL.fullmatch("user@example.com\n"))   # False

Pythonでは re.match と ^...$ の組み合わせだと、末尾に改行があっても一致してしまいます。実際に試すと、re.match(r"^...$", "user@example.com\n") は一致しました。re.fullmatch を使うのが確実です。

Java

private static final Pattern EMAIL = Pattern.compile(
    "[A-Za-z0-9._%+-]+@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\\.)+[A-Za-z]{2,}");

EMAIL.matcher("user@example.com").matches();   // true（matchesは全体一致）

Javaの文字列の中では、\. を \\. と書く必要があります。Bean Validationを使っている場合は、@Email アノテーションも利用できます。

PHP

$pattern = '/\A[A-Za-z0-9._%+-]+@(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+[A-Za-z]{2,}\z/';
preg_match($pattern, 'user@example.com');   // 1

PHPでは、標準の filter_var($email, FILTER_VALIDATE_EMAIL) も使えます。ただし、実際に試すと、abc..def@docomo.ne.jp のような古い携帯のアドレスは不合格になりました。日本の利用者を想定する場合は、この点を考慮して選びます。

日本で特に注意すること：古い携帯のアドレス

かつてdocomoやauでは、ドットが連続する（abc..def@）、@の直前がドット（abc.@）といった、メールの仕様（RFC）に厳密には合わないアドレスが作れました。現在は新しく作れませんが、今も使い続けている人がいます。

厳しいチェックで拒否すると、その人は会員登録ができなくなります。登録を受け付けたうえで、確認メールで届くかを確かめる方が、利用者にとって親切です。

一方、こうしたアドレスは、送信するメールサーバーの設定によっては送れないこともあります。受け付けるかどうかは、送信の仕組みとあわせて判断します。

文字数の上限もチェックする

正規表現とは別に、文字数の上限も確認します。

function isValidEmail(s) {
  return s.length <= 254 && EMAIL.test(s) && s.split("@")[0].length <= 64;
}

データベースの列の長さも、254文字以上にしておくと、長いアドレスで保存に失敗することを防げます。

＋を含むアドレスを拒否しない

user+shop@example.com のように、@の前に「＋」を付けて用途を分ける使い方（サブアドレス）は、Gmailなどで広く使われています。＋を使えない入力チェックは、利用者にとって不便なだけでなく、よくある改善要望の1つです。この記事のパターンは、＋を受け付けます。

日本語ドメインや、国際化されたアドレス

user@例え.jp のような日本語ドメインは、内部では xn-- で始まる英数字（Punycode）に変換して扱われます。受け付ける必要がある場合は、入力された日本語ドメインをPunycodeに変換してから正規表現でチェックします。

"例え.jp".encode("idna").decode()   # 'xn--r8jz45g.jp'

@の前に日本語を使うアドレスも仕様上は定義されていますが、対応しているメールサービスは限られています。多くのサービスでは、@の前は英数字と記号に限るのが現実的な判断です。

危険な正規表現：ReDoS

正規表現の書き方によっては、特定の入力で処理に極端に時間がかかり、サーバーが止まることがあります。これをReDoS（正規表現によるサービス妨害）と呼びます。

# 危険な例：繰り返しの中に、さらに繰り返しがある
bad = r"^([a-zA-Z0-9]+)*@example\.com$"
re.match(bad, "a" * 26 + "!")

実際に計測すると、次のように、入力が2文字増えるごとに処理時間が約4倍になりました。

30文字を超えると数十秒〜数分かかり、1回の入力でサーバーの処理を占有できてしまいます。

避けるべき書き方は、(a+)+ や (a|a)* のように、同じ文字に一致する繰り返しが入れ子になっているものです。この記事のパターン1は、ドメインの各部分がドットで区切られているため、5万文字の入力でも一瞬で判定が終わることを確認しています。

インターネットで見つけた正規表現を使う場合は、入れ子の繰り返しがないかを確認し、入力の長さの上限（254文字）を先にチェックしておくと安全です。

正規表現でできること・できないこと

会員登録では、確認メールで本人確認をするのが確実な方法です。正規表現のチェックは、明らかな入力ミス（@の抜け、空白の混入など）をその場で知らせるための補助と考えます。

入力のしやすさも考える

• 前後の空白は、チェックの前に取り除く（コピー＆ペーストで混ざりやすい）
• 全角で入力された英数字は、半角に変換してからチェックする
• 大文字・小文字は、@の後（ドメイン）は区別されない。重複登録のチェックでは、少なくともドメイン部分を小文字に揃える
• 確認用にもう一度入力させるより、確認メールで確かめる方が、利用者の負担は小さい

よくある質問

Q. RFCに完全に準拠した正規表現はありますか？ A. 理論上は作れますが、数千文字に及ぶ非常に複雑なものになり、実在しないような形式まで受け付けます。実務では、この記事のような実用的なパターンと、確認メールを組み合わせるのが一般的です。

Q. フロントエンドでチェックすれば、サーバー側のチェックは不要ですか？ A. 必要です。ブラウザでのチェックは、開発者ツールなどで簡単に回避できます。画面側は利用者への案内、サーバー側は最終的な防御として、両方でチェックします。

Q. 「.co.jp」のような2段のドメインにも対応していますか？ A. 対応しています。ドメインの部分は、ドットで区切られた部分をいくつでも受け付けます。

Q. ライブラリを使った方がいいですか？ A. 使えるなら、実績のあるライブラリ（Pythonのemail-validator、JavaのBean Validationなど）を使うのがおすすめです。ただし、ライブラリによって判定の基準が違うため、古い携帯のアドレスや＋を含むアドレスなど、自分のサービスで受け付けたいアドレスが通るかを確認してから使います。

まとめ

• メールアドレスのチェックは、ほどほどに緩い実用パターンを使う。厳しすぎると実在するアドレスを拒否する
• 画面とサーバーで基準を揃えるなら、HTML5の仕様と同じパターンも使える
• Pythonは fullmatch、Javaは matches、PHPは \A と \z で、全体一致を確実にする
• 全体254文字・@の前64文字の上限も確認する
• 古い携帯のアドレスや＋を含むアドレスを拒否しない
• 入れ子の繰り返しがある正規表現は、ReDoSで処理が止まる危険がある
• 実在の確認は確認メールで。正規表現は、入力ミスをその場で知らせる補助

株式会社RJCでは、入力チェックのような小さな部分にも、利用者の立場で考える姿勢を大切にしています。こうした知識を仲間と共有しながら、一緒に成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。