Regex untuk Validasi Email: Pola yang Benar-Benar Berfungsi

Validasi email adalah salah satu kasus penggunaan regex yang paling umum — dan salah satu yang paling disalahpahami. Spesifikasi RFC 5321 untuk alamat email sangat kompleks, dan tidak ada satu pun regex yang dapat memvalidasinya sepenuhnya. Namun pola praktis yang mencakup 99,9% alamat email nyata dapat dicapai dan berguna.

Pola Sederhana (Cukup Baik)

Untuk sebagian besar aplikasi, pola ini bekerja dengan baik:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Apa yang dicocokkan: Satu atau lebih karakter yang diizinkan, diikuti oleh @, diikuti oleh domain dengan setidaknya satu titik dan TLD dari 2+ huruf.

JavaScript:

const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
emailRegex.test('user@example.com');  // true
emailRegex.test('user@.com');          // false

Uji pola ini dengan Regex Tester kami.

Mengapa Validasi Regex yang Sempurna Itu Mustahil

Spesifikasi email (RFC 5321/5322) memungkinkan struktur yang valid tetapi pada dasarnya tidak pernah digunakan dalam praktik:

"john..doe"@example.com           // Quoted local part with consecutive dots
user@[192.168.1.1]                // IP address as domain
"very.(),:;<>[]\".VERY."very@\ "very".unusual"@strange.example.com

Regex yang menangani semua alamat yang valid menurut RFC memiliki ribuan karakter dan masih mungkin tidak mencakup setiap kasus tepi. Pendekatan praktis: gunakan regex sederhana untuk validasi format dasar, lalu verifikasi email benar-benar ada dengan mengirim konfirmasi.

Rincian Pola

Bagian Lokal (sebelum @)

[a-zA-Z0-9._%+-]+

• Huruf (besar dan kecil)
• Angka
• Titik, garis bawah, persen, plus, tanda hubung
• Satu atau lebih karakter

Kesalahan umum:

• Mengizinkan titik di awal atau akhir (secara teknis tidak valid)
• Mengizinkan titik berturut-turut (secara teknis tidak valid tanpa pengutipan)
• Terlalu ketat (memblokir karakter valid seperti + yang digunakan dalam alias Gmail)

Bagian Domain (setelah @)

[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

• Karakter alfanumerik, titik, tanda hubung
• Setidaknya satu titik
• TLD dari 2+ karakter alfabet

Kesalahan umum:

• Membatasi panjang TLD menjadi 3-4 karakter (.museum, .photography ada)
• Tidak mengizinkan tanda hubung dalam nama domain
• Tidak menangani subdomain (user@mail.example.co.uk)

Pola yang Lebih Baik

Standar HTML5

Spesifikasi HTML5 mendefinisikan pola ini untuk <input type="email">:

^[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])?)*$

Ini lebih permisif di bagian lokal dan lebih ketat tentang panjang label domain.

Pola Praktis yang Direkomendasikan

^[^\s@]+@[^\s@]+\.[^\s@]{2,}$

Pola minimal ini hanya memastikan: tidak ada spasi, satu @, setidaknya satu titik setelah @, TLD dari 2+ karakter. Ini sengaja permisif — menangkap input yang jelas salah tanpa menolak alamat yang tidak biasa tetapi valid.

Implementasi Spesifik Bahasa

JavaScript

function isValidEmail(email) {
  // Basic regex check
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/;
  if (!regex.test(email)) return false;
  
  // Additional checks
  if (email.length > 254) return false;  // RFC 5321 limit
  const [local] = email.split('@');
  if (local.length > 64) return false;   // RFC 5321 limit
  
  return true;
}

Python

import re

def is_valid_email(email: str) -> bool:
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    if not re.match(pattern, email):
        return False
    if len(email) > 254:
        return False
    local, domain = email.rsplit('@', 1)
    if len(local) > 64:
        return False
    return True

Melampaui Regex: Validasi Email yang Tepat

Regex hanyalah garis pertahanan pertama. Strategi validasi lengkap:

1. Pemeriksaan format (regex): Tolak format yang jelas tidak valid
2. Pemeriksaan panjang: Bagian lokal ≤ 64 karakter, total ≤ 254 karakter
3. Pemeriksaan DNS: Verifikasi domain memiliki record MX
4. Deteksi email sekali pakai: Blokir layanan email sementara jika diperlukan
5. Email konfirmasi: Satu-satunya cara untuk benar-benar memverifikasi email — kirim pesan dan konfirmasi pengguna menerimanya

// DNS MX record check (Node.js)
const dns = require('dns');
const [, domain] = email.split('@');
dns.resolveMx(domain, (err, addresses) => {
  if (err || !addresses.length) {
    console.log('Domain has no email server');
  }
});

Kesalahan Umum yang Harus Dihindari

1. Pola yang terlalu ketat: Memblokir user+tag@gmail.com (plus addressing) atau user@subdomain.example.com
2. Sensitivitas huruf besar-kecil: Bagian lokal email bisa peka huruf besar-kecil menurut RFC, tetapi dalam praktiknya, perlakukan sebagai tidak peka huruf besar-kecil
3. Pemangkasan: Selalu pangkas spasi putih sebelum validasi — " user@example.com " seharusnya lolos
4. Domain internasional: .münchen dan 用户@例え.jp valid dalam email yang terinternasionalisasi

Untuk pola regex lainnya, lihat Lembar Contekan Regex kami.

FAQ

Haruskah saya memvalidasi email dengan regex di sisi klien atau server?

Keduanya. Validasi sisi klien memberikan umpan balik instan (UX lebih baik). Validasi sisi server wajib untuk keamanan (pemeriksaan klien dapat dilewati). Jangan pernah hanya mengandalkan validasi sisi klien.

Mengapa beberapa situs web menolak alamat email saya yang valid?

Pola regex yang terlalu ketat biasanya menjadi penyebabnya. Alamat dengan + (alias Gmail), TLD panjang (.technology), atau subdomain sering ditolak oleh validasi yang buruk. Jika Anda mengelola situs web, gunakan regex yang permisif dan verifikasi dengan email konfirmasi.

Sumber Terkait

• Regex Tester — Uji pola validasi email secara real-time
• Lembar Contekan Regex — Referensi pola regex lengkap
• Validasi JSON Schema — Validasi field email di JSON dengan format: email