Daftar dan hubungi dukungan untuk mendapatkan 100 pemeriksaan gratis.Daftar gratis
Ilustrasi alur kerja EmailCheckPro untuk Verifikasi Email vs Validasi Email: Apa yang Diberitahukan oleh Setiap Langkah
Gambaran visual alur kerja yang dibahas dalam artikel EmailCheckPro ini.

Validasi email mengonfirmasi bahwa alamat ditulis dengan benar; verifikasi email memeriksa apakah alamat tersebut dapat dikirimi pada saat pemeriksaan, dan masing-masing langkah ini berada pada titik yang berbeda dalam alur kerja.

Perbedaan antara verifikasi email dan validasi email terletak pada dua pertanyaan yang berbeda. Validasi menanyakan apakah alamat ditulis dalam format yang dapat diterima: satu tanda @, bagian lokal, domain, dan tidak ada karakter ilegal. Verifikasi menanyakan apakah alamat yang diformat dengan benar dapat dikirimi, yang berarti alamat tersebut dapat menerima email pada saat pemeriksaan dilakukan. Validasi berjalan secara instan dalam kode Anda sendiri dan tidak memakan biaya, tetapi tidak dapat memberi tahu Anda apakah kotak surat tersebut ada atau tidak. Pemeriksaan keterkiriman, seperti Pemeriksaan Keterkiriman Email dari EmailCheckPro, memberikan hasil dapat dikirimi atau tidak dapat dikirimi tanpa mengirim apa pun ke alamat tersebut. Sebagian besar tim membutuhkan keduanya: validasi terlebih dahulu untuk menangkap kesalahan pengetikan, kemudian pemeriksaan keterkiriman pada alamat yang lolos validasi.

Apa yang Diperiksa oleh Validasi Email

Validasi adalah serangkaian aturan format yang diterapkan pada teks yang diketik seseorang atau yang terkandung dalam sebuah file. Validasi tidak pernah menghubungi apa pun di luar aplikasi Anda. Aturan umum meliputi:

  • Tepat satu @ yang memisahkan bagian lokal dan domain.
  • Tidak ada spasi, koma, atau karakter khusus yang tidak diapit tanda kutip.
  • Domain dengan setidaknya satu titik dan label tingkat atas yang masuk akal.
  • Batas panjang. RFC 5321 membatasi bagian lokal hingga 64 oktet dan jalur penerusan penuh hingga 256 oktet, jadi apa pun yang lebih panjang aman untuk ditolak.

Peramban sudah menerapkan serangkaian aturan yang disederhanakan secara sengaja untuk <input type="email">; HTML Living Standard menjelaskan definisinya sebagai pelanggaran yang disengaja terhadap tata bahasa RFC 5322 yang lengkap, yang dipilih karena tata bahasa lengkap tersebut menerima string yang tidak pernah diketik oleh pengguna asli.

Apa yang tidak dapat dilakukan oleh validasi sama pentingnya. jane.doe@example.com dan jdoe1987@example.com keduanya lolos setiap aturan format, namun satu mungkin merupakan kotak surat yang berfungsi dan yang lainnya mungkin tidak pernah ada. Pemeriksaan format juga tidak dapat mendeteksi domain yang salah ketik tetapi memiliki format yang benar seperti gmial.com, karena string tersebut secara sintaksis benar.

Apa yang Diberitahukan oleh Langkah Verifikasi Email

Verifikasi dimulai di tempat aturan format berhenti. Dengan EmailCheckPro, Pemeriksaan Keterkiriman Email yang selesai melaporkan salah satu dari dua hasil untuk alamat yang diformat dengan benar:

  • Dapat dikirimi: alamat tersebut dapat menerima email pada saat pemeriksaan.
  • Tidak dapat dikirimi: alamat tersebut tidak dapat menerima email pada saat pemeriksaan.

Situasi ketiga ditangani secara terpisah. Beberapa domain menerima email untuk bagian lokal apa pun (domain catch-all), sehingga satu kotak surat tidak dapat dikonfirmasi dengan cara apa pun. EmailCheckPro memperlakukan ini sebagai tidak dapat ditentukan alih-alih menebak; permintaan realtime mengembalikan kode bisnis bukan nol tanpa hasil, dan pemeriksaan tidak dikenakan biaya.

Dua properti praktis membuat verifikasi berguna dalam produksi. Pertama, tidak ada yang dikirim: pemilik alamat tidak menerima pesan atau pemberitahuan apa pun. Kedua, hasilnya menjelaskan satu momen. Alamat yang dapat dikirimi hari ini bisa saja ditutup pada kuartal berikutnya, jadi hasil yang disimpan harus mencantumkan tanggal saat hasil tersebut dibuat.

Verifikasi juga memiliki cakupan. Verifikasi menginformasikan apakah sebuah alamat dapat menerima email; verifikasi tidak mengatakan apa pun tentang siapa yang mengendalikan kotak surat tersebut atau apakah mereka setuju untuk dihubungi oleh Anda.

Perbandingan Verifikasi Email vs Validasi Email

Validasi format Pemeriksaan keterkiriman
Pertanyaan yang dijawab Apakah alamat ditulis dengan benar? Bisakah alamat ini menerima email sekarang?
Di mana langkah ini berjalan Formulir, skrip, atau alat impor Anda Layanan eksternal seperti EmailCheckPro
Kecepatan Instan, lokal Satu permintaan jaringan per alamat atau batch
Biaya Tidak ada selain kode Anda Ditagih per hasil yang selesai
Hasil umum Lolos atau gagal Dapat dikirimi, tidak dapat dikirimi, atau tidak dapat ditentukan
Mendeteksi kotak surat yang tidak ada Tidak Ya, sebagai tidak dapat dikirimi

Tabel tersebut menunjukkan mengapa langkah-langkah ini dilapisi alih-alih ditukar. Validasi murah dan menyaring sampah yang jelas sebelum Anda mengeluarkan biaya apa pun. Pemeriksaan keterkiriman adalah satu-satunya dari keduanya yang berbicara langsung kepada kotak surat itu sendiri. Alamat yang gagal dalam validasi hanyalah input yang tidak valid; alamat tersebut tidak boleh dicatat sebagai tidak dapat dikirimi, karena tidak ada pertanyaan keterkiriman yang pernah diajukan mengenainya.

Di Mana Setiap Langkah Berada dalam Alur Pendaftaran

Formulir pendaftaran atau pembayaran memiliki orang yang menunggu, jadi buat urutannya tetap sederhana dan fleksibel:

  1. Validasi di peramban dan di server. Gunakan type="email" untuk umpan balik segera, lalu ulangi aturan yang sama di sisi server, karena pemeriksaan klien dapat dilewati.
  2. Tawarkan saran koreksi untuk kesalahan ketik domain yang umum. Daftar singkat kesalahan pengetikan yang sering terjadi (gmial.com, hotmial.com) menangkap kesalahan yang lolos aturan format.
  3. Jalankan satu pemeriksaan keterkiriman. Panggil POST /api/v1/check dengan alamat yang dikirimkan setelah lolos validasi.
  4. Bercabang berdasarkan hasil. Dapat dikirimi: lanjutkan. Tidak dapat dikirimi: minta orang tersebut untuk meninjau alamat alih-alih menolaknya secara diam-diam. Tidak dapat ditentukan: terima pendaftaran dan andalkan email konfirmasi normal Anda.
  5. Simpan hasil dengan stempel waktu. Tim dukungan kemudian dapat melihat seperti apa alamat tersebut saat pendaftaran.

Buat pesan tidak dapat dikirimi tetap ramah dan spesifik, misalnya "Kami tidak dapat mengonfirmasi bahwa alamat ini dapat menerima email. Harap periksa ejaannya." Pemblokiran keras tanpa penjelasan cenderung membuat frustrasi pengguna sah yang salah mengetik satu karakter.

Di Mana Setiap Langkah Berada dalam Impor Daftar

Impor dari acara, spreadsheet, atau CRM lama biasanya membawa campuran masalah, jadi jalankan validasi sebagai langkah pembersihan sebelum pemeriksaan apa pun:

  1. Normalisasi. Pangkas spasi putih, ubah domain menjadi huruf kecil, dan pisahkan sel yang berisi dua alamat.
  2. Validasi dan sisihkan kegagalan. Masukkan baris yang gagal dalam aturan format ke dalam wadah "input tidak valid" untuk peninjauan manual.
  3. Hapus duplikat. Alamat yang sama dalam tiga baris hanya perlu satu pemeriksaan.
  4. Pilih jenis permintaan berdasarkan volume. Untuk daftar pendek, POST /api/v1/batch-check menerima 1 hingga 100 alamat dan mengembalikan hasil dalam urutan input dalam respons yang sama. Untuk file besar, POST /api/v1/bulk-tasks menerima TXT atau CSV dengan satu alamat lengkap per baris; tugas bersifat asinkron, dan Anda melakukan polling GET /api/v1/bulk-tasks/{id} hingga CSV hasil siap. Batas tugas per produk tercantum dalam dokumentasi API EmailCheckPro.
  5. Simpan empat wadah. Dapat dikirimi, tidak dapat dikirimi, tidak dapat ditentukan, dan input tidak valid masing-masing memerlukan pemilik dan langkah selanjutnya yang berbeda.

Dalam respons multi-alamat sinkron, entri tanpa hasil yang selesai tidak sama dengan vonis tidak dapat dikirimi. Perlakukan sebagai "tidak diperiksa" dan coba lagi nanti.

Kesalahan Umum Saat Menggabungkan Keduanya

  • Mengandalkan regex yang terlalu ketat. Pola yang menolak tag + atau domain tingkat atas yang panjang akan menolak pengguna asli. Lebih baik gunakan aturan format yang permisif ditambah pemeriksaan keterkiriman.
  • Menggabungkan input tidak valid dan tidak dapat dikirimi. Keduanya berasal dari langkah yang berbeda dan memerlukan perbaikan yang berbeda: input tidak valid biasanya perlu dikoreksi oleh seseorang, sementara tidak dapat dikirimi mungkin berarti kotak surat ditutup.
  • Menebak pada domain catch-all. Menandai setiap alamat yang tidak dapat ditentukan sebagai buruk akan menghapus kontak asli; menandai semuanya sebagai baik akan menyembunyikan risiko. Simpan mereka di segmen mereka sendiri.
  • Menggunakan kembali hasil lama tanpa batas waktu. Periksa kembali alamat sebelum pengiriman besar jika hasil terakhir sudah berusia beberapa bulan.
  • Memperlakukan verifikasi sebagai izin. Hasil dapat dikirimi hanya menginformasikan kualitas daftar; penanganan persetujuan dan opt-out adalah kewajiban terpisah.

FAQ

Bagaimana tim dapat memutuskan apakah validasi format saja sudah cukup?

Validasi format sering kali cukup untuk bidang yang berisiko rendah, seperti kotak buletin opsional di mana email konfirmasi akan menyusul. Ketika sebuah alamat mendorong pemulihan akun, tanda terima pesanan, atau daftar jangkauan yang besar, biaya dari kotak surat yang salah ketik atau ditutup lebih tinggi, dan pemeriksaan keterkiriman pada alamat yang lolos validasi menambahkan informasi yang tidak dapat diberikan oleh aturan format.

Bagaimana tim harus menyimpan hasil verifikasi dalam basis data?

Simpan hasil sebagai salah satu dari sekumpulan kecil nilai, seperti dapat dikirimi, tidak dapat dikirimi, tidak dapat ditentukan, atau input tidak valid, bersama dengan tanggal pemeriksaan. Menyimpan tanggal memungkinkan alur kerja di kemudian hari memutuskan kapan sebuah alamat memerlukan pemeriksaan baru. Hindari menimpa alamat asli dengan versi yang dikoreksi tanpa mencatat bahwa seseorang atau aturan telah melakukan perubahan tersebut.

Bagaimana pengembang menangani hasil tidak dapat ditentukan saat pendaftaran?

Biarkan pendaftaran berlanjut. Hasil tidak dapat ditentukan biasanya berasal dari domain catch-all di mana satu kotak surat tidak dapat dikonfirmasi, jadi memblokirnya akan menolak pengguna asli. Tandai catatan tersebut secara internal, kirim email konfirmasi atau selamat datang yang normal, dan gunakan hasil dari pesan tersebut, seperti klik atau pantulan, untuk memutuskan langkah selanjutnya.

Pelajari Lebih Lanjut

Pilih informasi produk yang sesuai dengan langkah selanjutnya dalam alur kerja Anda.

Sumber