Verifikasi Email di Node.js: Melampaui Regex ke Pemeriksaan Keterkiriman

Alur layanan Node.js untuk verifikasi email: penyaringan format lokal, pemeriksaan keterkiriman sisi server, dan penanganan yang jelas untuk setiap hasil.

Verifikasi email di Node.js bekerja paling baik sebagai dua lapisan di sisi server. Pertama, normalisasi input dan saring formatnya secara lokal, sehingga kesalahan pengetikan yang jelas tidak pernah keluar dari proses Anda. Kedua, panggil pemeriksaan keterkiriman seperti POST /api/v1/check dari EmailCheckPro melalui kode server dengan batas waktu (timeout), lalu bagi menjadi tiga hasil: Dapat dikirimi, Tidak dapat dikirimi, atau Tidak dapat ditentukan. Regex saja hanya memberi tahu Anda bahwa alamat tersebut terlihat benar; pemeriksaan keterkiriman memberi tahu Anda apakah alamat tersebut dapat menerima email pada saat pemeriksaan dilakukan, tanpa mengirim apa pun ke alamat tersebut. Tautan konfirmasi tetap menjadi langkah terpisah untuk persetujuan dan kepemilikan.

Apa arti verifikasi email di Node.js biasanya

Cari topik ini dan sebagian besar tutorial akan menunjukkan regex atau rute Express yang mengirimkan tautan konfirmasi melalui email. Keduanya berguna, tetapi menjawab pertanyaan yang berbeda, dan mencampurnya akan menyebabkan bug.

Panduan ini mencakup dua lapisan pertama, yang berjalan sebelum Anda mengirim apa pun. Keduanya melengkapi, bukan menggantikan, alur konfirmasi. Pola ini mencerminkan verifikasi lapisan layanan di framework lain: browser dapat memberikan petunjuk cepat, tetapi keputusan ada di server, tempat kunci API dan hasil yang disimpan berada.

Langkah 1: normalisasi dan saring format

Mulailah dengan fungsi kecil yang dapat diprediksi. Hapus spasi, hilangkan tanda baca di akhir yang sering terbawa dari teks yang disalin, ubah domain menjadi huruf kecil, dan biarkan bagian lokal sesuai dengan yang diketik. Kemudian uji hasilnya terhadap pola yang luas.

// Pola dari standar HTML WHATWG untuk input type="email"
const EMAIL_PATTERN = /^[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])?)*$/;

export function normalizeEmail(raw) {
 const trimmed = String(raw ?? '').trim().replace(/[.,;:]+$/, '');
 const at = trimmed.lastIndexOf('@');
 if (at < 1 || at === trimmed.length - 1) return null;
 const email = trimmed.slice(0, at) + '@' + trimmed.slice(at + 1).toLowerCase();
 return EMAIL_PATTERN.test(email) ? email : null;
}

Pola ini berasal dari standar HTML WHATWG, aturan yang sama yang diterapkan browser pada kolom type="email", sehingga klien dan server memiliki kesepakatan yang sama. Jika Anda lebih suka paket yang terawat, isEmail di validator.js adalah pilihan umum; pilih satu sumber kebenaran dan gunakan di mana saja.

Kesalahan umum pada lapisan ini:

• Pola yang terlalu ketat yang menolak tag +, domain tingkat atas yang panjang, atau subdomain. Panduan OWASP merekomendasikan untuk menerima berbagai format yang valid dan hanya menolak input yang jelas salah.
• Mengubah seluruh alamat menjadi huruf kecil. Domain tidak peka huruf besar-kecil, tetapi mengubah bagian lokal akan mengubah apa yang diketik pengguna.

Langkah 2: panggil pemeriksaan keterkiriman dari server

Node.js 18 ke atas menyertakan fetch global, jadi tidak diperlukan pustaka HTTP. Panggilan harus berjalan di server: kunci API menggunakan saldo akun dan tidak boleh sampai ke kode browser.

const API_BASE = process.env.EMAILCHECK_API_BASE; // dari dokumentasi API

export async function checkDeliverability(email) {
 try {
 const res = await fetch(`${API_BASE}/api/v1/check`, {
 method: 'POST',
 headers: buildHeaders(), // header otentikasi persis seperti yang didokumentasikan
 body: buildCheckBody(email), // badan permintaan persis seperti yang didokumentasikan
 signal: AbortSignal.timeout(4000) // anggaran waktu Anda sendiri
 });
 return await toOutcome(res); // 'deliverable' | 'undeliverable' | 'undetermined'
 } catch (err) {
 return 'not_completed'; // TimeoutError, kesalahan jaringan, dll.
 }
}

buildHeaders, buildCheckBody, dan toOutcome adalah pembantu sederhana yang Anda tulis berdasarkan dokumentasi API EmailCheckPro, sehingga detail otentikasi dan kolom tetap berada di satu tempat dan mengikuti kontrak yang dipublikasikan. toOutcome harus mengembalikan kata-kata yang jelas alih-alih meneruskan objek respons mentah ke seluruh basis kode Anda.

AbortSignal.timeout() membatalkan permintaan setelah anggaran waktu yang Anda pilih dan memunculkan TimeoutError, yang mencegah jaringan lambat membekukan formulir pendaftaran. Referensi fetch Node.js mencantumkan opsi yang didukung. Pilih batas waktu dari toleransi formulir Anda sendiri; nilai di atas hanyalah contoh, bukan angka layanan.

Pemeriksaan Keterkiriman Email menerima alamat di hampir semua domain. Jika produk memerlukan avatar publik, Pemeriksaan Avatar Email terbatas pada domain Gmail, Yandex, dan Mail.ru, jadi arahkan domain lain ke produk keterkiriman.

Langkah 3: tangani dapat dikirimi, tidak dapat dikirimi, dan tidak dapat ditentukan

Modelkan hasil sebagai serangkaian status kecil dan biarkan formulir memutuskan dari sana:

export async function screenSignupEmail(raw) {
 const email = normalizeEmail(raw);
 if (!email) return { ok: false, message: 'Harap periksa format email.' };

 const outcome = await checkDeliverability(email);
 await saveCheck({ email, outcome, checkedAt: new Date() });

 switch (outcome) {
 case 'deliverable': return { ok: true, email };
 case 'undeliverable': return { ok: false, message: 'Alamat ini tidak dapat menerima email. Harap gunakan yang lain.' };
 default: return { ok: true, email, flagged: true }; // tidak dapat ditentukan atau tidak selesai
 }
}

Mengapa setiap cabang berperilaku seperti itu:

• Dapat dikirimi berarti alamat tersebut dapat menerima email pada saat pemeriksaan. Lanjutkan, dan simpan tanggal beserta hasilnya.
• Tidak dapat dikirimi berarti alamat tersebut tidak dapat menerima email. Minta alamat lain dengan bahasa yang ramah; jangan menuduh pengguna memasukkan alamat palsu.
• Tidak dapat ditentukan mencakup alamat yang tidak dapat dipastikan, seperti alamat catch-all. API waktu nyata mengembalikan kode bisnis alih-alih hasil untuk alamat ini, dan alamat ini tidak dikenakan biaya. Terima alamat tersebut dengan tanda (flag) alih-alih menebak.
• Tidak selesai mencakup batas waktu dan kesalahan jaringan. Membiarkan pengguna melanjutkan dengan tanda mencegah masalah sementara memblokir pendaftaran yang nyata.

Pekerjaan latar belakang nantinya dapat memeriksa ulang baris yang ditandai, dan email konfirmasi yang Anda kirim akan menyelesaikan banyak di antaranya.

Memeriksa lebih dari satu alamat dari Node.js

Formulir pendaftaran memeriksa satu alamat, tetapi alat admin dan impor sering kali memuat banyak alamat. Dua jalur yang didokumentasikan mencakupnya.

Hingga 100 alamat sekaligus. POST /api/v1/batch-check menerima 1–100 alamat dan mengembalikan hasil dalam respons yang sama, sesuai urutan input. Bagi array yang lebih besar menjadi potongan 100 dan gabungkan setiap respons kembali ke potongannya berdasarkan posisi. Setiap item menyatakan apakah hasil yang selesai ada; item tanpa hasil termasuk dalam cabang tidak dapat ditentukan atau tidak selesai, tidak pernah dalam tidak dapat dikirimi.

File yang disiapkan. Untuk ekspor dan migrasi, tulis file TXT atau CSV dengan satu alamat lengkap per baris dan kirimkan dengan POST /api/v1/bulk-tasks. Tugas berjalan secara asinkron, jadi periksa status dari pekerja, bukan penangan permintaan:

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function waitForTask(taskRef) {
 for (;;) {
 const status = await getTaskStatus(taskRef); // GET /api/v1/bulk-tasks/{id}
 if (status.done) return status; // sukses atau gagal
 await sleep(30_000); // jangan pernah memeriksa lebih cepat dari ini
 }
}

Tugas yang berhasil menyediakan satu CSV hasil di tautan unduhan yang bertahan selama 12 jam; menanyakan tugas yang sama lagi akan mengembalikan tautan baru. Baris yang tidak valid dan duplikat dihapus selama persiapan, jadi gabungkan hasil kembali berdasarkan alamat email alih-alih nomor baris. Batas tugas per produk tercantum dalam dokumentasi API.

Daftar periksa produksi untuk integrasi Node.js

• Rahasia: baca kunci API dari lingkungan atau manajer rahasia, dan jauhkan dari log serta laporan kesalahan.
• Caching: simpan hasil beserta tanggalnya dan gunakan kembali dalam jendela pemeriksaan ulang Anda sendiri, sehingga mengedit nama profil tidak memicu panggilan baru.
• Endpoint Anda sendiri: jika aplikasi mengekspos rute pemeriksaan alamat, tambahkan pembatasan laju (rate limiting) dan respons yang konsisten agar tidak dapat digunakan untuk menyelidiki akun mana yang ada.
• Antrean: jalankan pemeriksaan ulang baris yang ditandai dari antrean pekerjaan dengan penundaan dan batas percobaan, alih-alih mencoba lagi di dalam permintaan.
• Pengujian: lakukan pengujian unit pada normalizeEmail dengan tag plus, subdomain, spasi tambahan, dan domain yang hilang, serta uji setiap cabang hasil dengan checkDeliverability yang disimulasikan (stubbed) agar salinan UI ditinjau sebelum peluncuran.
• Alat AI: tim yang juga bekerja melalui asisten AI dapat menggunakan endpoint MCP di https://emailcheckpro.com/mcp untuk pemeriksaan tunggal dan hingga 100 alamat, sementara tugas berbasis file tetap menggunakan REST API.

FAQ

Apakah regex cukup untuk verifikasi email di Node.js?

Regex cukup untuk menangkap input yang salah format, dan harus dijalankan terlebih dahulu karena tidak memakan biaya. Tim yang perlu mengetahui apakah suatu alamat dapat dikirimi menambahkan pemeriksaan sisi server setelah regex, dan menyimpan tautan konfirmasi untuk persetujuan dan kepemilikan.

Haruskah pemeriksaan keterkiriman berjalan di browser atau di server?

Di server. Kunci API menggunakan saldo akun bersama, jadi mengeksposnya dalam kode front-end memungkinkan siapa pun menggunakannya. Rute server juga dapat menerapkan batas lajunya sendiri, menyimpan hasil dengan tanggal, dan memutuskan cara menangani pemeriksaan yang tidak dapat ditentukan atau kehabisan waktu. Browser masih dapat menampilkan petunjuk format instan menggunakan pola WHATWG yang sama.

Bagaimana tim dapat menghindari pemblokiran pengguna nyata saat pemeriksaan tidak dapat ditentukan?

Terima alamat tersebut dengan tanda alih-alih menolaknya. Hasil yang tidak dapat ditentukan, seperti alamat catch-all, bukanlah bukti bahwa alamat tersebut buruk, dan tidak dikenakan biaya. Akun yang ditandai masih dapat menerima email konfirmasi; pekerjaan nanti dapat memeriksanya kembali, dan saluran pengiriman dapat menahan baris yang ditandai hingga hasil yang selesai atau klik konfirmasi dicatat.

Pelajari Lebih Lanjut

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

• Lihat dokumentasi produk →
• Hubungi tim →