Apakah gratis untuk digunakan?

Ya, sepenuhnya gratis. Tidak ada paket berbayar, tidak ada batas penggunaan, dan tidak memerlukan akun. Anda membuka halaman, dan kotak masuk Anda siap — itu saja. Kami tidak pernah meminta nama, nomor telepon, atau kartu pembayaran.

Berapa lama kotak masuk saya aktif?

Kotak masuk Anda aktif selama satu jam sejak dibuat. Penghitung waktu di bagian atas halaman menunjukkan persis berapa banyak waktu yang tersisa. Ketika satu jam berakhir, alamat email dan semua pesan di dalamnya dihapus secara permanen. Jika Anda perlu kembali sebelum satu jam berakhir, tandai URL halaman ini.

Bisakah saya memilih alamat email saya sendiri?

Belum untuk saat ini. Setiap alamat dibuat secara acak saat Anda membuka halaman. Kami memilih pendekatan ini agar tidak memerlukan pendaftaran dan agar tidak ada yang bisa menebak atau mengklaim alamat Anda. Alamat khusus adalah sesuatu yang sedang kami kerjakan untuk versi mendatang.

Mengapa saya tidak menerima email yang saya tunggu?

Beberapa hal dapat menyebabkan ini. Pertama, beberapa layanan menolak alamat yang termasuk dalam domain email sekali pakai yang dikenal. Kedua, beberapa email mungkin membutuhkan beberapa menit tergantung pada server email pengirim. Ketiga, periksa bahwa Anda menyalin alamat dengan tepat — bahkan satu karakter yang salah berarti email berakhir di tempat lain.

Bisakah saya menggunakan ini di ponsel saya?

Ya. Halaman ini sepenuhnya responsif dan berfungsi di semua peramban seluler. Buka, salin alamat, dan tempel di mana Anda membutuhkannya. Email baru tiba secara real-time di seluler, sama seperti di komputer.

Apakah kotak masuk saya bersifat pribadi?

Tidak ada kata sandi — siapa pun yang memiliki URL persis dapat membukanya. Alamat dibuat secara acak dan cukup panjang sehingga tidak ada yang secara tidak sengaja menemukan alamat Anda. Meski begitu, jangan gunakan untuk hal yang benar-benar sensitif. Alat email terenkripsi seperti ProtonMail lebih cocok untuk tujuan itu.

Apa yang terjadi pada email saya saat satu jam berakhir?

Semuanya dihapus secara permanen. Alamat ditandai kedaluwarsa, semua pesan dihapus dari basis data kami, dan tidak ada yang bisa dipulihkan. Kami tidak mengarsipkan, membaca, atau menjual data. Jika ada sesuatu di kotak masuk yang penting, simpan sebelum penghitung waktu berakhir.

Bisakah saya memiliki lebih dari satu kotak masuk sekaligus?

Ya. Setiap tab peramban mendapatkan kotak masuk independennya sendiri. Buka tab baru, kunjungi halaman, dan Anda mendapatkan alamat yang sepenuhnya terpisah.

Apakah berfungsi untuk tautan verifikasi email?

Ya, dalam sebagian besar kasus. Ketika sebuah layanan mengirim email verifikasi dengan tautan konfirmasi, email tersebut sampai di sini, dan Anda dapat mengkliknya untuk menyelesaikan pendaftaran. Pastikan saja Anda melakukannya sebelum satu jam berakhir.

Cara Menguji Verifikasi Email sebagai Developer

Saya sudah merilis lebih banyak alur pendaftaran daripada yang bisa saya hitung. Dan setiap kali, fase pengujian untuk verifikasi email adalah cerita yang sama: kotak masuk saya penuh dengan pesan uji, saya mulai kehilangan jejak uji mana yang mana, dan di suatu titik sekitar pendaftaran uji keempat puluh saya mulai mengabaikan email sepenuhnya. Saya bilang pada diri sendiri akan membersihkannya nanti. Saya tidak melakukannya. Enam bulan setelah peluncuran masih ada 200 email verifikasi uji tergeletak di kotak masuk saya tanpa melakukan apa-apa.

Itu benar-benar kebiasaan buruk — bukan hanya soal kerapian, tetapi soal kualitas pengujian itu sendiri. Ketika kotak masuk Anda penuh dengan email uji sebelumnya, jauh lebih sulit untuk memverifikasi bahwa uji tertentu baru saja memicu pengiriman tertentu. Anda mulai membuat asumsi alih-alih benar-benar memeriksa. Anda melewatkan bug yang halus. Dan seluruh hal ini sepenuhnya tidak perlu, karena ada pendekatan yang jauh lebih baik.

Artikel ini membahas penggunaan email sementara sebagai bagian inti dari alur kerja pengembangan Anda saat membangun dan menguji verifikasi email. Ini membuat prosesnya lebih cepat, lebih bersih, lebih menyeluruh, dan sejujurnya jauh lebih menyenangkan.

Apa yang Sebenarnya Terlibat dalam Verifikasi Email

Sebelum kita bicara tentang pengujian, ada baiknya kita tepat tentang apa yang sebenarnya kita uji. Verifikasi email bukan hanya "kirim tautan". Ini adalah proses multi-langkah dengan beberapa komponen yang dapat diuji secara independen, dan masing-masing bisa gagal dengan cara yang berbeda dan terkadang halus.

Langkah satu: menghasilkan token yang aman secara kriptografis. OWASP Authentication Cheat Sheet jelas soal ini: token verifikasi harus dihasilkan menggunakan generator angka acak yang aman secara kriptografis, harus setidaknya sepanjang 32 byte, dan harus disimpan dengan cara yang memungkinkan validasi di sisi server tanpa dapat dibalik. Bukan bilangan bulat berurutan. Bukan hash yang dapat diprediksi dari ID pengguna. Token acak yang benar.

Langkah dua: menyimpan token dengan metadata yang sesuai — milik pengguna mana, kapan dibuat, kapan kedaluwarsa, dan apakah sudah pernah digunakan. Langkah tiga: menyusun email. Ini berarti baris subjek, nama pengirim, isi, URL verifikasi, dan memastikan URL itu mengarah ke lingkungan yang benar (bukan produksi dari server dev Anda). Langkah empat: mengirimkan email melalui SMTP. RFC 5321 mendefinisikan spesifikasi Simple Mail Transfer Protocol — memahami bahkan dasar-dasar cara kerja SMTP membantu Anda mendiagnosis masalah pengiriman saat terjadi.

Langkah lima: pengguna mengklik tautan. Server Anda memvalidasi token: apakah ada? Apakah kedaluwarsa? Apakah sudah pernah digunakan sebelumnya? Jika semua pemeriksaan lolos, akun ditandai terverifikasi dan token dibatalkan. Jika ada pemeriksaan yang gagal, pengguna mendapat pesan kesalahan yang jelas. Masing-masing langkah ini adalah kasus uji. Masing-masing bisa salah dengan cara yang berbeda. Alur kerja pengujian yang menyeluruh mencakup semuanya.

Mengapa Menguji dengan Email Asli Anda adalah Ide Buruk

Menggunakan alamat email asli Anda untuk pengujian pengembangan punya beberapa masalah konkret yang menumpuk sepanjang proyek. Yang paling jelas adalah kekacauan — setelah seratus pendaftaran uji, kotak masuk Anda penuh dengan email verifikasi yang kini tak berguna. Menemukan hasil uji tertentu di tengah kebisingan itu benar-benar sulit. Anda mungkin mulai menyaring email-email ini secara otomatis, yang berarti Anda berhenti benar-benar membacanya, yang berarti Anda berhenti menangkap bug rendering dan kesalahan konten di template Anda.

Ada juga masalah yang lebih mendasar: Anda tidak dapat mensimulasikan "pengguna baru yang belum pernah terlihat sebelumnya" dengan alamat email asli Anda. Alamat Anda sudah ada di basis data Anda. Untuk menguji pendaftaran baru, Anda harus menghapus akun Anda dan mendaftar ulang — yang merepotkan dan berarti Anda tidak dapat mempertahankan status uji sebelumnya. Dengan alamat sementara, setiap uji benar-benar pengguna baru dengan kotak masuk yang benar-benar baru.

Selain itu, beberapa penyedia email mulai menyaring pesan serupa yang berulang sebagai spam ketika berasal dari domain pengirim yang sama dalam periode singkat. Pengiriman uji Anda mungkin berhenti sampai ke kotak masuk sama sekali, yang akan membuat Anda mengira alur pengiriman Anda rusak padahal tidak. Dan Anda sama sekali tidak dapat menguji pendaftaran bersamaan — jika Anda perlu memverifikasi apa yang terjadi ketika tiga pengguna mendaftar secara bersamaan, Anda tidak dapat melakukannya dengan satu alamat email asli.

Solusi Email Sementara — Langkah demi Langkah

Inilah persisnya bagaimana saya menggunakan temp-email.ai dalam alur kerja pengembangan saya. Buka temp mail di tab peramban di samping lingkungan pengembangan Anda. Alamat unik menunggu Anda seketika — tanpa pengaturan, tanpa pembuatan akun. Salin dengan satu klik.

Beralih ke aplikasi Anda. Buka halaman pendaftaran atau daftar. Tempel alamat sementara ke kolom email dan isi sisa formulirnya. Kirim. Beralih kembali ke tab temp-email.ai. Jika pengiriman email Anda dikonfigurasi dengan benar, email verifikasi akan tiba dalam 2 hingga 5 detik. Anda akan melihat baris subjek, nama pengirim, dan seluruh isi email yang dirender persis seperti akan muncul di klien email asli mana pun.

Klik tautan verifikasi langsung dari kotak masuk sementara. Aplikasi Anda seharusnya menanganinya dengan benar — mengalihkan ke halaman yang tepat, menampilkan status berhasil, dan menandai akun sebagai terverifikasi. Anda baru saja menyelesaikan uji menyeluruh (end-to-end) penuh dari alur verifikasi Anda. Sekarang buka tab kedua dan lakukan lagi dengan alamat baru untuk menguji pendaftaran bersamaan. Seluruh proses dari "perlu diuji" hingga "uji selesai" memakan waktu sekitar dua menit.

Apa yang Harus Diuji dalam Alur Verifikasi Anda

Ini adalah daftar periksa komprehensif yang saya jalani saat menguji implementasi verifikasi email:

Pengiriman dasar: Apakah emailnya tiba? Uji ini dengan berbagai skenario pengiriman — apa yang terjadi ketika Anda mendaftar di lingkungan lokal baru vs staging vs produksi? Masalah pengiriman sering kali spesifik lingkungan.
Ketepatan tautan: Apakah URL verifikasi dalam email mengarah ke lingkungan yang benar? Sangat mudah untuk keliru menyematkan (hard-code) URL produksi dalam template yang lalu digunakan dalam pengembangan. Tautan harus disusun secara dinamis dari konfigurasi URL dasar Anda.
Keamanan token: Apakah token setidaknya 32 karakter dan benar-benar acak? Periksa token di URL — seharusnya terlihat seperti untaian huruf dan angka acak, bukan pola yang dapat diprediksi. Rujuk OWASP Authentication Cheat Sheet untuk panduan spesifik tentang pembuatan token.
Kedaluwarsa token: Apa yang terjadi ketika Anda membiarkan tautan verifikasi lebih lama dari jendela kedaluwarsa Anda lalu mengkliknya? Aplikasi Anda seharusnya menanganinya dengan mulus — pesan jelas yang memberi tahu pengguna bahwa tautan sudah kedaluwarsa dan ajakan untuk meminta yang baru. Bukan kesalahan 500 yang generik.
Penegakan penggunaan sekali pakai: Bisakah tautan verifikasi yang sama digunakan dua kali? Setelah Anda memverifikasi sekali, mengklik tautan lagi seharusnya tidak berhasil. Seharusnya memberi tahu pengguna bahwa akun mereka sudah terverifikasi, atau bahwa tautan tidak valid. Uji ini secara eksplisit.
Pendaftaran ulang sebelum verifikasi: Apa yang terjadi jika pengguna mendaftar, tidak memverifikasi emailnya, lalu mencoba mendaftar lagi dengan alamat yang sama? Apakah aplikasi Anda menanganinya dengan benar — entah mengirim ulang verifikasi atau menyuruh mereka memeriksa kotak masuk?
Fungsi kirim ulang: Apakah tombol "kirim ulang email verifikasi" berfungsi? Apakah mengkliknya membatalkan token sebelumnya dan mengirim yang baru? Uji dengan mengkliknya beberapa kali dengan cepat — apa yang terjadi jika seseorang mengklik kirim ulang sepuluh kali?
Rendering HTML: Apakah template email Anda dirender dengan benar di kotak masuk asli? Di penampil temp-email.ai, periksa: apakah tombol benar-benar dapat diklik? Apakah gambar dimuat? Apakah tata letak utuh di pratinjau desktop maupun seluler? Apakah teks meluap di suatu tempat?
Baris subjek dan nama pengirim: Apakah baris subjek jelas, profesional, dan tidak rawan memicu spam? Apakah nama pengirim adalah nama merek Anda, bukan nama penyedia layanan generik? Ini penting untuk keterkiriman dan kepercayaan pengguna.
Personalisasi: Apakah nama atau nama pengguna terisi dengan benar di tempat yang seharusnya muncul di isi email? Ini bug template yang umum — substitusi variabel gagal secara diam-diam dan Anda akhirnya mengirim "Hai {{firstName}}" alih-alih "Hai Sarah".

Menguji di Berbagai Skenario

Pendaftaran standar bukanlah satu-satunya alur yang mengirim pesan bergaya verifikasi email. Jika aplikasi Anda mendukung masuk sosial — "Daftar dengan Google" atau OAuth melalui penyedia serupa — sebagian besar implementasi tetap mengirim email sambutan atau konfirmasi pembuatan akun. Uji alur itu juga. Buka kotak masuk sementara, gunakan sebagai email yang terkait untuk uji OAuth Anda, dan verifikasi bahwa email sambutan tiba dan terlihat benar.

Alur reset kata sandi secara struktural hampir identik dengan verifikasi email: hasilkan token yang aman, kirim tautan lewat email, validasi saat diklik, batalkan setelah digunakan. Setiap butir dalam daftar periksa pengujian di atas berlaku sama untuk reset kata sandi. Begitu pula verifikasi perubahan alamat email — ketika pengguna memperbarui emailnya di pengaturan, Anda perlu memverifikasi alamat baru sebelum melakukan pergantian. Itu adalah alur email lengkap lain untuk diuji secara independen.

Email undangan — di mana pengguna mengundang rekan untuk bergabung — menambahkan dimensi lain: kotak masuk pihak yang diundang. Dengan alamat email sementara, Anda dapat menguji kedua sisi alur undangan dalam sesi peramban yang sama. Kirim dari akun uji utama Anda, terima di alamat sementara, terima undangan, dan verifikasi status setelah penerimaan. Bersih, lengkap, dan cepat.

Banyak Pengguna Bersamaan

Ini adalah salah satu keunggulan terbesar alamat email sementara untuk pengujian pengembangan, dan ini adalah sesuatu yang mustahil dilakukan dengan satu akun email asli. Setiap tab peramban di temp-email.ai adalah kotak masuk yang sepenuhnya independen. Anda dapat membuka lima tab sekaligus, masing-masing dengan alamat berbeda, mendaftarkan lima akun di aplikasi Anda pada saat yang sama, dan menyaksikan lima email verifikasi independen tiba secara waktu nyata di lima kotak masuk terpisah.

Pengujian bersamaan semacam ini menangkap seluruh kelas bug yang tidak akan pernah ditangkap oleh pengujian berurutan satu pengguna: kondisi balapan (race condition) dalam pembuatan token, kebuntuan basis data (deadlock) pada pemeriksaan batasan unik, penundaan pemrosesan antrean yang menyebabkan beberapa email verifikasi tiba jauh lebih lambat dari yang lain, dan interaksi tak terduga antara sesi bersamaan. Jika Anda membangun produk yang mengharapkan lebih dari segelintir pengguna, menguji pendaftaran bersamaan bukanlah pilihan — itu esensial. Alamat sementara membuatnya sangat mudah.

Di Luar Verifikasi — Email Transaksional Lain untuk Diuji

Selagi Anda menjalankan alur kerja email sementara, terapkan pada setiap email transaksional yang dikirim aplikasi Anda. Masing-masing berhak atas putaran pengujiannya sendiri yang khusus:

Email reset kata sandi: Pertimbangan keamanan token dan kedaluwarsa yang sama dengan verifikasi. Uji skenario tautan kedaluwarsa dan sudah digunakan secara eksplisit.
Email undangan: Pihak yang diundang menerima ini, bukan pengguna yang sudah ada — kasus penggunaan sempurna untuk kotak masuk sementara yang baru.
Email konfirmasi dan tanda terima pesanan: Periksa bahwa semua detail item, harga, dan tautan benar. Konfirmasi pesanan yang rusak adalah mimpi buruk layanan pelanggan.
Email notifikasi aktivitas: Ringkasan digest, notifikasi sebutan, umpan aktivitas. Uji bahwa mereka hanya dikirim ketika aktivitas relevan benar-benar terjadi.
Email konfirmasi berhenti berlangganan: Ketika pengguna berhenti berlangganan dari pemasaran, apakah mereka menerima konfirmasi? Apakah header berhenti berlangganan satu klik (wajib bagi pengirim massal) ada?
Konfirmasi penghapusan akun: Jika aplikasi Anda mengirim konfirmasi akhir ketika pengguna menghapus akunnya, verifikasi bahwa ini berfungsi dan bahwa Anda benar-benar dapat membaca email di kotak masuk sementara sebelum akun hilang.

Apa yang Harus Dicari di Email Uji Anda

Ketika Anda menerima email uji di kotak masuk sementara Anda, jangan hanya mengklik tautan dan beranjak. Luangkan lima belas detik untuk benar-benar melihat email itu dengan saksama. Periksa header jika kotak masuk sementara Anda menampilkannya — apakah SPF dan DKIM lolos? Itu penting untuk keterkiriman kepada penerima asli. Jika domain pengirim Anda tidak dikonfigurasi dengan benar untuk DKIM, email Anda mungkin berakhir di spam bagi pengguna asli meskipun berfungsi baik di lingkungan uji.

Perhatikan rendering HTML. Sebuah template bisa terlihat sempurna di alat pratinjau email lokal Anda lalu rusak di kotak masuk sungguhan karena klien email yang berbeda menangani CSS dengan cara yang sangat berbeda. Melihatnya di kotak masuk asli — bahkan yang sementara — menangkap masalah yang terlewat oleh alat pratinjau. Periksa tombol, periksa pemuatan gambar, periksa bahwa tidak ada teks yang terpotong atau meluap dari wadahnya. Jika Anda juga dapat melihat rendering seluler, lakukan — porsi email yang tidak proporsional dibuka di seluler.

Periksa waktu pengiriman. Untuk pengaturan email transaksional yang dikonfigurasi dengan benar, pengiriman ke kotak masuk sementara seharusnya memakan waktu tidak lebih dari 2 hingga 5 detik sejak saat Anda memicu pengiriman. Keterlambatan yang konsisten lebih lama dari itu — katakanlah 20 hingga 30 detik — menandakan masalah pemrosesan antrean atau penundaan resolusi DNS dalam konfigurasi pengiriman Anda yang perlu diselidiki sebelum pengguna asli Anda mengalaminya.

Biarkan tab email sementara tetap terbuka selagi Anda mengembangkan. Kotak masuk tetap aktif selama satu jam penuh, yang biasanya lebih dari cukup untuk sesi pengembangan dan pengujian yang lengkap. Bookmark URL tab untuk kembali ke kotak masuk yang sama jika Anda tak sengaja menutupnya.

Menjadikan Ini Kebiasaan

Perubahan alur kerjanya benar-benar kecil. Alih-alih mengetik alamat email asli Anda ke formulir pendaftaran uji, Anda meluangkan lima detik untuk membuka temp mail di tab baru dan menyalin alamat dari sana. Itulah seluruh perubahannya. Tetapi efek hilir pada kualitas pengujian sangat signifikan.

Anda menguji lebih menyeluruh karena memeriksanya tanpa hambatan. Anda menangkap lebih banyak bug rendering karena Anda melihat rendering kotak masuk asli setiap kali. Anda dapat menguji skenario bersamaan yang sebelumnya tidak praktis. Kotak masuk asli Anda tetap bersih. Dan Anda membangun kebiasaan memperlakukan email sebagai permukaan uji kelas satu alih-alih hal yang dipikirkan belakangan — yang merupakan model mental yang tepat untuk membangun produk yang benar-benar dipercaya orang.

Blog

Bagaimana Developer Menguji Alur Verifikasi Email Tanpa Mengacaukan Kotak Masuk Asli Mereka