Validator Email

Validator email gratis yang berjalan di browser Anda

Validator email ini memeriksa apakah alamat email terformat dengan benar dan menandai alamat yang paling mungkin bounce — semuanya tanpa mengirim satu pesan pun dan tanpa mengunggah daftar Anda ke mana pun. Tempel satu alamat atau ribuan alamat dan masing-masing langsung diperiksa untuk sintaks yang valid, salah ketik umum, domain sekali pakai, dan akun berbasis peran.

Tidak ada pendaftaran, tidak ada API key, dan tidak ada biaya. Ini adalah validator email gratis dan pengecek email yang bisa Anda buka terus di sebuah tab dan gunakan kapan pun Anda perlu memvalidasi alamat email atau membersihkan daftar sebelum mengimpornya ke Mailchimp, HubSpot, Klaviyo, atau platform lain mana pun. Berfungsi di iPhone, Android, tablet, dan desktop.

Seperti apa alamat email yang valid

Alamat email yang valid memiliki sebuah nama (local part) sebelum @, tepat satu simbol @, dan domain dengan setidaknya satu titik serta top-level domain yang sah — misalnya nama@contoh.com. Local part bisa mencakup huruf, angka, dan beberapa simbol, tetapi tidak boleh diawali atau diakhiri titik, mengandung spasi, atau memiliki dua titik berturut-turut.

Pengecek sintaks email ini mengikuti aturan RFC 5322 tersebut dan memberi tahu Anda persis aturan mana yang dilanggar sebuah alamat, sehingga bad@@contoh.com ditolak karena memiliki dua simbol @ dan john@perusahaan ditolak karena tidak memiliki top-level domain — alih-alih sekadar 'tidak valid' yang samar. Banyak validator form HTML5 dasar hanya menangkap kasus paling jelas; alat ini menerapkan aturan secara penuh.

Pemeriksaan tunggal dan pembersihan daftar massal

Gunakan kolom di bagian atas untuk memeriksa alamat email saat Anda mengetik, dengan putusan langsung dan alasan tepat mengapa alamat itu lolos atau gagal. Turun ke validator email massal untuk membersihkan seluruh daftar: tempel atau unggah CSV dan setiap baris mendapat putusannya sendiri, dengan hitungan berjalan untuk alamat valid, berisiko, dan tidak valid.

Ekspor hasilnya sebagai CSV atau salin hanya alamat valid yang bersih kembali ke clipboard Anda — berguna sebelum mengimpor kontak ke newsletter, CRM, atau alat outreach, tempat setiap alamat tidak valid merusak reputasi pengirim Anda dan membuang kredit pengiriman. Alat berbayar seperti ZeroBounce dan NeverBounce melakukan pekerjaan yang sama tetapi mengenakan biaya $0,008–$0,01 per alamat dan memerlukan akun.

Bagaimana ini dibandingkan dengan ZeroBounce, NeverBounce dan Hunter.io

ZeroBounce dan NeverBounce adalah layanan verifikasi email berbayar terkemuka. Mereka menawarkan pemeriksaan SMTP real time yang bisa memastikan apakah sebuah kotak surat spesifik ada — sesuatu yang tidak bisa dilakukan alat berbasis browser mana pun. ZeroBounce mengenakan biaya sekitar $0,008 per email ($16 untuk 2.000 alamat); NeverBounce serupa. Keduanya mengharuskan Anda mengunggah daftar Anda ke server mereka dan membuat akun, yang menimbulkan pertanyaan transfer data GDPR dan CCPA. Hunter.io menyertakan verifikasi email dalam API-nya dengan 50 pemeriksaan gratis/bulan sebelum paket berbayar dimulai.

Alat ini mencakup 90% alamat buruk yang bisa Anda tangkap tanpa pemeriksaan SMTP: salah ketik, layanan sekali pakai, alamat berbasis peran, dan kesalahan sintaks. Untuk sebagian besar kasus penggunaan — membersihkan daftar sebelum impor Mailchimp, memeriksa alamat pada form pendaftaran, memvalidasi kontak sebelum kampanye outreach dingin — validasi sintaks dan kualitas sudah cukup. Bagi pengirim bervolume tinggi yang memerlukan jaminan tingkat SMTP, ZeroBounce atau NeverBounce sepadan dengan biayanya. Bagi yang lain, gratis dan privat adalah titik awal yang tepat.

Tangkap salah ketik, alamat sekali pakai, dan berbasis peran

Sebagian besar alamat buruk bukanlah hal yang eksotis — hanya jari yang keseleo. Validator ini mendeteksi salah ketik domain umum seperti gmial.com, yahooo.com, hotmial.com, dan outlok.com serta menyarankan penyedia yang benar dengan perbaikan satu klik.

Alat ini juga menandai alamat email sekali pakai atau sementara (mailinator.com, guerrillamail.com, 10minutemail, dan puluhan lainnya), kotak surat berbasis peran seperti info@, support@, dan admin@ yang jarang dimiliki orang sungguhan, dan apakah sebuah domain adalah penyedia gratis atau domain kustom/korporat. Untuk Gmail, alat ini menampilkan alamat yang dinormalisasi, karena Gmail mengabaikan titik dan apa pun setelah +, sehingga john.doe+news@gmail.com dan johndoe@gmail.com sampai ke kotak masuk yang sama.

Privat sejak dirancang — daftar Anda tidak pernah meninggalkan perangkat

Karena validator email ini berjalan sepenuhnya di browser Anda, daftar yang Anda tempel tidak pernah meninggalkan perangkat Anda — tidak diunggah, dicatat, atau dijual, berbeda dari verifier email massal berbasis server seperti ZeroBounce, NeverBounce, Hunter.io, dan Kickbox yang mengharuskan Anda menyerahkan kontak Anda. Untuk daftar pelanggan yang tunduk pada GDPR atau CCPA, pendekatan lokal-saja menghindari terciptanya catatan transfer data apa pun.

Simpan sebagai bookmark sebagai pengecek email andalan Anda untuk pemeriksaan sintaks cepat, perbaikan salah ketik, dan pembersihan daftar massal — alternatif yang cepat dan privat untuk layanan berbayar saat Anda hanya perlu tahu alamat mana yang layak dipertahankan.

RFC 5321 dan RFC 5322: apa yang sebenarnya diizinkan oleh spesifikasi

Aturan otoritatif untuk sintaks alamat email berasal dari dua dokumen IETF: RFC 5321 (Simple Mail Transfer Protocol) dan RFC 5322 (Internet Message Format). Bersama-sama, keduanya mendefinisikan local part — segala sesuatu sebelum @ — sebagai rangkaian karakter yang diambil dari huruf, angka, dan simbol ! # $ % & ' * + / = ? ^ _ ` { | } ~ . -. Yang krusial, spasi dan koma yang tidak di-escape dilarang, dan titik tidak boleh muncul di awal atau akhir, atau berturut-turut. Sisi domain mengikuti aturan hostname DNS: setiap label yang dipisahkan titik bisa mencapai 63 karakter, harus diawali dan diakhiri karakter alfanumerik, dan boleh mengandung tanda hubung di tengahnya.

Spesifikasi ini juga menerapkan batas panjang yang keras: local part dibatasi hingga 64 karakter dan alamat lengkap (local + @ + domain) tidak boleh melebihi 254 karakter. Detail yang kurang dikenal adalah bahwa local part secara teknis case-sensitive menurut RFC — User@contoh.com dan user@contoh.com secara formal adalah alamat yang berbeda — meskipun dalam praktiknya hampir semua server email memperlakukannya sebagai identik. Aturan ini juga mengizinkan beberapa alamat yang secara keliru ditolak oleh validator yang terlalu mengandalkan regex: a@b.io (satu karakter di setiap sisi) sepenuhnya valid, begitu pula user+tag@contoh.co.uk (plus-tagging), "very.unusual"@contoh.com (local part berkutip yang mengizinkan karakter yang seharusnya ilegal), dan test@xn--nxasmq6b.com (domain terinternasionalisasi dalam Punycode). Validator yang tangguh menghormati spesifikasi secara penuh, bukan hanya jalur umum yang mudah.

Yang menjadi ambigu dalam spesifikasi ini adalah alamat email terinternasionalisasi yang kemudian didefinisikan oleh RFC 6530 dan RFC 6532, yang mengizinkan karakter Unicode di local part (misalnya, 用户@例子.广告). Alamat semacam ini valid di infrastruktur email modern yang mendukung SMTPUTF8, tetapi banyak sistem lawas masih menolaknya. Memperlakukan local part non-ASCII sebagai selalu tidak valid secara teknis keliru; memperlakukannya sebagai selalu aman juga keliru. Pendekatan pragmatis — dan yang diambil alat ini — adalah menandainya sebagai memerlukan penanganan hati-hati, bukan diam-diam menerima atau menolaknya.

Keterkiriman email: hard bounce, soft bounce, dan reputasi pengirim

Validasi paling penting karena dampak alamat buruk terhadap reputasi pengirim Anda. Saat Anda mengirim ke alamat yang tidak ada, server email penerima mengembalikan hard bounce — kegagalan permanen dengan kode error SMTP 5xx, artinya alamat itu tidak akan pernah menerima email. Saat sebuah server sementara menolak pengiriman (kotak surat penuh, server kelebihan beban, di-greylist), Anda mendapat soft bounce — error 4xx yang akan dicoba ulang oleh Email Service Provider (ESP) Anda selama beberapa waktu sebelum menyerah. Hard bounce adalah sinyal yang lebih merusak: setiap ESP dari Mailchimp, SendGrid, hingga Klaviyo melacak tingkat hard-bounce Anda dan mulai membatasi atau menangguhkan akun begitu naik di atas 2–3%.

Mekanisme di balik kerusakan ini adalah reputasi IP. ESP mengirim email Anda lewat alamat IP bersama atau khusus. Penyedia layanan internet dan jaringan anti-spam seperti Spamhaus, Barracuda, dan SNDS milik Microsoft memantau berapa banyak email dari setiap IP yang berujung pada bounce, keluhan spam, dan jebakan spam (spam trap). Tingkat bounce yang tinggi menandakan bahwa pengirim membeli daftar, mengais alamat, atau memiliki kebersihan daftar yang buruk — semua pola yang berkaitan dengan spammer. Begitu sebuah IP atau domain masuk blacklist, email yang sah mulai masuk ke folder spam atau ditolak sama sekali, dan pemulihannya bisa memakan waktu berminggu-minggu mengirim volume rendah dari daftar bersih untuk membangun kembali kepercayaan.

Standar emas untuk memastikan alamat itu valid sekaligus benar-benar dimiliki adalah double opt-in: setelah pengguna mengirimkan alamatnya, Anda mengirim email konfirmasi berisi tautan unik, dan langganan hanya diaktifkan saat mereka mengkliknya. Double opt-in menghilangkan salah ketik yang kebetulan membentuk alamat asli lain, pendaftaran bot, dan alamat yang dimasukkan oleh orang selain pemilik kotak masuk. Dipadukan dengan validasi sintaks di titik masuk, ini menghasilkan daftar sebersih mungkin. Validasi sintaks dan double opt-in saling melengkapi — yang pertama mencegah pemborosan pengiriman konfirmasi ke alamat yang jelas-jelas salah format; yang kedua memastikan alamat yang bisa dikirimi email itu benar-benar milik orang yang mengetiknya.

Apa yang bisa dan tidak bisa dideteksi validasi email

Validasi sintaks — pemeriksaan yang dilakukan alat ini — bisa secara pasti menangkap alamat yang salah format: penggunaan karakter yang salah, simbol @ yang hilang atau ganda, penempatan titik yang ilegal, pelanggaran panjang, dan kesalahan format domain. Satu langkah lebih maju adalah pemeriksaan MX record, yang meng-query catatan DNS domain untuk memastikan domain tersebut memiliki setidaknya satu server Mail Exchange yang dikonfigurasi, membuktikan domain itu ada dan disiapkan untuk menerima email. Ini menghilangkan alamat di domain yang sudah dihapus atau tidak pernah nyata. Kedua pemeriksaan ini tidak memerlukan pengiriman pesan atau koneksi ke server email.

Lebih jauh lagi, pemeriksaan koneksi SMTP — teknik yang digunakan layanan berbayar — terhubung ke server email penerima dan mengeluarkan perintah RCPT TO dengan alamat target, lalu menutup koneksi sebelum mengirim isi pesan apa pun. Banyak server merespons dengan jujur: mereka akan mengembalikan 250 OK jika kotak surat itu ada atau error 550 jika tidak. Namun, pendekatan ini menemui dua keterbatasan signifikan. Domain catch-all dikonfigurasi untuk menerima email untuk alamat apa pun di domain tersebut, sehingga setiap alamat terlihat valid meskipun sebagian besar fiktif. Penyedia yang sadar privasi termasuk Google (Gmail) dan Microsoft (Outlook) sengaja mengembalikan 250 OK untuk semua alamat terlepas dari apakah mereka ada, untuk mencegah pengumpulan alamat lewat probing SMTP. Hasilnya, bahkan pemeriksaan SMTP pun tidak bisa menjamin keterkiriman untuk domain-domain ini.

Apa yang tidak akan pernah bisa dideteksi oleh pemeriksaan otomatis mana pun: apakah orang yang memasukkan alamat itu benar-benar memiliki akses ke sana, apakah kotak surat itu dipantau atau akun yang terlupakan, atau apakah kotak masuknya hampir penuh. Layanan email sekali pakai dan sementara seperti Mailinator, Guerrilla Mail, dan 10MinuteMail patut mendapat perhatian khusus — mereka menghasilkan alamat yang valid secara sintaks di domain nyata dengan MX record yang berfungsi, sehingga lolos pemeriksaan sintaks maupun MX. Satu-satunya cara andal untuk memblokirnya adalah dengan memelihara daftar blokir domain sekali pakai yang diketahui, yang disertakan alat ini. Untuk alur pendaftaran tempat keterlibatan sungguhan penting — uji coba, newsletter, akun berbayar — memblokir domain sekali pakai dipadukan dengan double opt-in adalah pertahanan praktis terkuat.

Kesalahan umum validasi email dalam pengembangan web

Kesalahan paling umum adalah regex yang terlalu ketat. Developer meraih pola yang terlihat komprehensif tetapi menolak alamat yang sah: memblokir karakter + merusak penyaringan alias Gmail (jutaan pengguna mengandalkan user+label@gmail.com untuk menyortir email masuk), menolak subdomain memblokir user@mail.perusahaan.com, dan beberapa pola menolak TLD kode negara yang lebih dari dua karakter atau gTLD baru sepenuhnya. Jeff Atwood dari Coding Horror mendokumentasikan pola ini dengan terkenal — kesimpulannya adalah satu-satunya regex yang layak digunakan adalah yang memeriksa struktur dasar, dan satu-satunya cara untuk benar-benar memverifikasi sebuah alamat adalah dengan mengirim ke sana. Pola alat ini mengikuti RFC 5322 cukup dekat untuk menerima kasus tepi seperti a@b.io, user+tag@sub.domain.co.uk, dan local part satu karakter.

Detail implementasi yang sering diabaikan adalah atribut maxlength pada kolom input email. Maksimum menurut RFC adalah 254 karakter, tetapi banyak form menghardcode batas 50 atau 100 karakter. Alamat email korporat sungguhan di organisasi besar — dengan nama depan, nama belakang, inisial tengah, dan nama domain yang panjang — bisa secara sah mendekati atau melebihi 100 karakter. Menyetel maxlength="254" pada kolom input adalah implementasi yang benar. Sama pentingnya adalah kapan Anda memvalidasi: memicu validasi pada keyup (saat pengguna mengetik) bersifat agresif dan menjengkelkan — alamatnya selalu 'tidak valid' di tengah pengisian. Memvalidasi pada blur (saat pengguna meninggalkan kolom) atau saat pengiriman form adalah konvensi standar. Atribut HTML type="email" memberikan validasi dasar tingkat browser secara gratis dan harus selalu disetel; ini tidak menggantikan validator yang tepat tetapi menangkap kesalahan struktural paling jelas sebelum JavaScript bahkan berjalan.

Kesalahan yang lebih halus adalah mencampuradukkan validasi dengan verifikasi dalam pesan error yang dilihat pengguna. Memberi tahu pengguna 'alamat email ini tidak ada' padahal Anda hanya memeriksa sintaksnya secara teknis keliru dan berpotensi membingungkan jika mereka memasukkan alamat yang sepenuhnya sungguhan. Framing yang benar adalah 'alamat ini tampaknya tidak terformat dengan benar' untuk kegagalan sintaks, dan 'kami telah mengirim email konfirmasi — silakan klik tautannya untuk melanjutkan' untuk verifikasi keterkiriman. Yang terakhir secara benar menyampaikan bahwa Anda menggunakan double opt-in alih-alih secara keliru mengklaim Anda tahu status kotak surat itu. Pesan error yang baik, dipadukan dengan validasi format yang menerima seluruh rentang alamat yang valid menurut RFC, mengurangi friksi pendaftaran sambil tetap menangkap sebagian besar kesalahan.