Alamat Email Uji untuk Developer dan QA: Menemukan yang Disembunyikan Staging dalam Email Transaksional

Katakanlah tim Anda merilis email reset kata sandi yang baru. QA menyetujuinya di staging: pesan muncul, tautan berfungsi, templatnya tampak benar. Dua hari setelah rilis, dukungan pelanggan punya antrean tiket. Orang dengan alamat Gmail mengatakan emailnya tak pernah datang. Orang di beberapa perusahaan besar mengatakan emailnya datang, tetapi tautannya sudah "dipakai" pada klik pertama. Tak seorang pun mengubah kode antara staging dan produksi, dan setiap pengujian tetap lulus.

Jadi alamat email uji untuk developer mana yang akan menangkap ini? Tidak ada satu pun. Penangkap SMTP lokal cocok untuk pengembangan sehari-hari, sandbox penyedia Anda atau domain uji yang Anda kendalikan cocok untuk pengujian otomatis, dan kotak masuk eksternal sungguhan cocok untuk pemeriksaan manual bahwa surat keluar dari lingkungan mirip produksi Anda dan sampai ke domain orang asing. Kotak masuk sementara seperti VookMail mencakup kasus terakhir itu tanpa penyiapan, karena alamat siap saat halaman dimuat. Akun contoh di penyedia kotak surat besar kemudian mencakup bagian yang tidak bisa dilihat oleh semuanya itu. Sisa panduan ini membahas memilih di antara opsi-opsi itu, membaca kegagalan setelah terjadi, dan pemeriksaan yang seharusnya ada dalam sebuah rilis.

Mengapa reset itu lolos di staging

Staging dan produksi jarang semirip yang disiratkan diagram penerapan, dan email menyingkap perbedaannya lebih dari kebanyakan fitur. Sebuah pesan melewati aplikasi Anda, antrean, penyedia, DNS, server penerima, dan klien penerima. Staging mungkin memakai versi berbeda untuk hampir semuanya.

Ambil tiket pertama, para pengguna Gmail yang tidak menerima apa-apa. Misalkan staging mengirim lewat subdomain penyedia yang diautentikasi berbulan-bulan lalu, sedangkan produksi mengirim dari domain From baru yang diperkenalkan bersama rebranding. Pedoman pengirim Google mewajibkan semua pengirim mengautentikasi dengan SPF atau DKIM, dan tabel galat Gmail mencantumkan 5.7.26 untuk surat yang tidak terautentikasi. Kotak surat QA internal di domain Anda sendiri mungkin meloloskan pesan yang sama, karena server Anda sendiri bisa memercayai relay Anda sendiri. Pengujiannya tidak mungkin gagal.

Tiket kedua, tautan "sudah dipakai", punya penyebab berbeda. Gateway keamanan korporat biasanya membuka tautan di surat masuk untuk memindainya sebelum orangnya melihat. Jika tautan Anda menebus token lewat permintaan GET biasa, pemindai menghabiskannya, dan karyawan mengklik tautan yang mati. Tidak ada kotak surat staging Anda yang menjalankan pemindai itu, kecuali perusahaan Anda sendiri kebetulan memakainya.

Kedua bug ini tidak bisa dilihat dari tempat yang sama. Yang satu membutuhkan pengiriman nyata ke sistem penerima yang tidak Anda jalankan. Yang lain membutuhkan perubahan cara tautan berperilaku, yang lebih mudah ditangkap tinjauan daripada pengujian. Itulah alasan untuk pengujian berlapis: tiap jenis alamat menjawab satu pertanyaan dan diam tentang yang lain.

Sering berbeda antara staging dan produksi	Apa yang bisa disembunyikannya
Domain pengirim dan alamat From	SPF dan DKIM yang hilang atau tidak selaras
Akun atau subakun penyedia	Mode sandbox, batas pengiriman, reputasi IP yang berbeda
Penerima	Domain internal yang memercayai Anda, dan daftar izin yang menyembunyikan alamat buruk
Pelacakan klik	Tautan yang ditulis ulang lalu rusak, atau domain pelacakan tanpa sertifikat yang valid
Volume	Antrean dan batas laju yang baru terasa saat beban tinggi
Daftar penekanan	Alamat produksi yang pernah mental dan kini diam-diam dilewati
Pengaturan URL dasar	Tautan yang menuju host yang salah

Alamat mana menjawab pertanyaan mana

Berikut opsi-opsinya, masing-masing dengan pertanyaan yang benar-benar bisa dijawabnya.

Penangkap lokal: "apa yang dihasilkan aplikasi saya?"

Penangkap SMTP menerima semua yang dikirim aplikasi Anda dan menampilkannya di halaman web tanpa mengantarkan apa pun. Mailpit adalah pilihan sumber terbuka yang populer. Secara bawaan ia mendengarkan SMTP di port 1025 dan menyajikan antarmuka webnya di port 8025, jadi Anda mengarahkan pengaturan pengembangan ke localhost:1025 dan membuka http://localhost:8025. Ethereal milik Nodemailer adalah gagasan serupa dengan layanan SMTP palsu yang di-hosting. Penangkap itu cepat dan privat, dan memungkinkan Anda mengirim ke alamat mana pun tanpa risiko menjangkau orang sungguhan. Ia juga tidak mengatakan apa pun tentang DNS, autentikasi, atau penyaringan, karena tidak ada yang melintasi internet.

Pembantu uji framework: "apakah kode saya meminta surat yang tepat?"

Kebanyakan framework dapat merekam surat keluar di memori selama pengujian berjalan. Laravel punya Mail::fake(), Django mengumpulkan pesan di django.core.mail.outbox, dan Rails punya ActionMailer::Base.deliveries. Pakai ini untuk memastikan sebuah job berjalan sekali dengan penerima dan token yang benar. Ini umpan balik tercepat yang bisa Anda dapat, dan menguji dunia luar bahkan lebih sedikit daripada penangkap.

Mode uji penyedia: "apakah integrasi saya berfungsi?"

Penyedia menawarkan bantuan yang berbeda-beda di sini, dan perbedaannya penting. Amazon SES punya simulator kotak surat dengan alamat seperti success@simulator.amazonses.com, bounce@simulator.amazonses.com, dan complaint@simulator.amazonses.com, yang menghasilkan hasil-hasil tersebut tanpa merusak reputasi Anda. Akun SES baru juga dimulai di sandbox yang hanya bisa mengirim ke alamat terverifikasi. Mode sandbox SendGrid, yang diatur lewat mail_settings.sandbox_mode.enable, memvalidasi permintaan Anda tanpa mengantarkan. Postmark menerima token POSTMARK_API_TEST untuk tujuan yang sama. Ini bagus untuk galat API dan webhook bounce serta keluhan, dan tidak membuktikan bahwa surat sampai ke siapa pun. Periksa dokumentasi terbaru penyedia Anda sendiri, karena fitur-fitur ini berubah.

Domain uji milik Anda: "apakah seluruh alur berfungsi, berulang kali?"

Untuk pengujian end-to-end otomatis, siapkan domain atau subdomain yang Anda kendalikan, dengan kotak surat catch-all atau webhook masuk, agar kode uji Anda bisa membaca surat lewat API. Penyiapannya butuh usaha, tetapi privat dan stabil, dan tidak bergantung pada situs web siapa pun. Jangan mengarang alamat di domain yang bukan milik Anda. Seseorang mungkin memiliki testuser@gmail.com, dan mereka akan menerima apa yang Anda kirim. RFC 2606 mencadangkan example.com serta nama tingkat atas .test dan .example agar dokumentasi dan data uji punya tempat yang aman untuk dituju. Nama-nama itu tidak dapat menerima surat, sehingga cocok untuk fixture dan tidak berguna untuk uji pengiriman.

Kotak masuk sementara eksternal sungguhan: "apakah domain orang asing akan menerima ini?"

Di sinilah kotak masuk sementara membuktikan nilainya. Ia adalah kotak surat nyata di domain yang tidak Anda kendalikan dan tidak punya daftar izin untuknya. Pesan Anda harus menemukan catatan MX, membuat koneksi SMTP, dan diterima. Di VookMail, catatan MX domain-domainnya menunjuk ke penyedia pengiriman surat yang menerima pesan lalu meneruskannya lewat HTTPS. Alamat baru juga berarti tanpa riwayat: tanpa pesan lama, tanpa mental sebelumnya di daftar penekanan Anda, tanpa filter. Itu menjadikannya cara cepat mereproduksi "saya mendaftar dengan alamat baru dan tidak menerima apa-apa". Ini juga berguna bagi non-developer. Seorang desainer atau manajer produk bisa membaca apa yang diterima pengguna baru tanpa akses apa pun ke alat Anda.

Akun contoh di penyedia kotak surat besar: "mendarat di mana?"

Pesan yang terkirim di satu domain tidak memberi tahu apa pun tentang folder spam di domain lain. Simpan sejumlah kecil akun sungguhan di penyedia yang benar-benar dipakai pengguna Anda, dan periksa penempatan sebelum perubahan templat atau domain yang signifikan. Lalu pantau angka bounce dan keluhan setelah rilis. Jika surat Anda tampak seperti masalah spam, akun-akun ini adalah tempat Anda melihatnya lebih dulu.

Pendekatan	Melintasi internet	Penyiapan	Otomatisasi	Privasi konten	Tahap terbaik
Pembantu uji framework	Tidak	Tidak ada	Sangat baik	Tetap di dalam proses	Uji unit dan fitur
Penangkap SMTP lokal	Tidak	Rendah	Baik	Tetap lokal	Pengembangan
Mode uji penyedia	Biasanya tidak	Rendah	Baik	Tetap pada penyedia	Uji integrasi
Domain uji milik Anda	Ya	Sedang hingga tinggi	Baik	Anda yang mengendalikan	End-to-end CI, staging
Kotak masuk sementara	Ya	Tidak ada	Tidak disarankan	Anggap publik	QA manual dan pemeriksaan sebelum rilis
Akun contoh	Ya	Sedang	Terbatas	Sedang	Pemeriksaan penempatan

Uji manual dengan kotak masuk sementara

Berikut langkah yang bisa diulang melalui alur pendaftaran di staging atau lingkungan pra-produksi. Seharusnya memakan sekitar sepuluh menit setelah Anda hafal.

1. Pastikan lingkungan itu memakai konfigurasi penyedia yang sama dengan produksi, selain kredensialnya, dan hanya berisi data karangan. Jika tidak, tuliskan, karena itu membatasi kesimpulan yang bisa Anda tarik.
2. Buka VookMail dan tekan Baru. Ketik nama pengguna yang mengodekan pengujian, seperti email-signup-03-x7, pilih salah satu dari lebih dari 30 domain, dan tekan panahnya. Pakai tombol Acak berwarna kuning bila ada yang sensitif di dalam surat, karena siapa pun yang tahu atau menebak sebuah alamat bisa membuka kotak masuk itu.
3. Tekan Salin dan daftar sebagai pengguna baru dengan data profil karangan.
4. Catat waktu Anda mengirim dan waktu pesan muncul. Kotak masuk memeriksa setiap beberapa detik, jadi selisih beberapa menit menunjuk ke antrean atau penyedia Anda. Tekan Segarkan bila ingin memastikan.
5. Baca pesan seperti pengguna baru: nama pengirim, subjek, teks pratinjau, isi, tombol, tautan biasa, footer. VookMail menampilkan kode dan tautan konfirmasi yang terdeteksi di atas pesan, yang merupakan pemeriksaan kasar bahwa kode dan tautan Anda mudah dikenali.
6. Lihat dengan gambar dimatikan. VookMail menjaga gambar tetap mati sampai Anda mengizinkan dan menghapus piksel pelacak tersembunyi. Jika pesan tidak masuk akal dalam keadaan itu, sebagian pengguna Anda melihat hal yang sama. Jangan pakai kotak masuk ini untuk menilai pelacakan pembukaan Anda, karena piksel tidak akan terpicu.
7. Tekan tombol QR, pindai alamat dengan ponsel uji dan buka kotak masuk yang sama di sana untuk mengetuk tautan sungguhan di perangkat sungguhan, terutama bila Anda memakai universal link atau app link.
8. Selesaikan verifikasi dan pastikan status akun berubah sebagaimana mestinya.
9. Jalankan kasus negatif dari daftar periksa di bawah: pakai ulang tautan, tunggu sampai kedaluwarsa, minta kirim ulang.
10. Simpan bukti Anda: tangkapan layar, stempel waktu, dan alamat yang dipakai. Pesan dihapus setelah sekitar sehari, jadi laporan bug yang ditulis minggu depan tidak akan punya apa pun untuk ditunjuk.
11. Tekan Hapus dan hapus akun uji bila proses Anda mengharuskannya.

Beberapa alamat bisa disimpan di satu peramban, jadi pengundang dan yang diundang, atau alamat lama dan baru dalam pergantian email, bisa terbuka sekaligus. Jika Anda melampirkan berkas dalam pengujian, ingat bahwa VookMail menolak berkas program umum seperti .exe dan menampilkan peringatan pada arsip, jadi lampiran yang ditolak di sana mungkin bukan bug di sisi Anda.

Membaca sebuah kegagalan

"Emailnya tidak sampai" menggambarkan gejala di salah satu dari sekitar enam tempat, dan tim kehilangan berjam-jam karena memulai dari tempat yang salah. Bergeraklah sepanjang jalur dari kode Anda ke luar, dan berhenti di tempat pertama yang sudah tidak bisa lagi Anda lihat pesannya.

1. Apakah aplikasi mencoba? Cari di log aplikasi untuk upaya pengiriman dan pengecualian apa pun. Cari job yang tidak pernah dibuat, sering karena suatu kondisi atau feature flag bernilai salah.
2. Apakah worker berjalan? Periksa job yang macet, gagal, atau diulang. Worker antrean yang tidak dimulai ulang setelah deploy bisa menjalankan kode lama, dan kebijakan percobaan ulang bisa mengirim duplikat.
3. Apakah penyedia menerimanya? Cari penerima atau Message-ID di log aktivitas penyedia Anda. Diterima, ditunda, mental, dan dibuang adalah empat cerita yang berbeda.
4. Apakah ditekan? Jika alamat itu pernah mental atau mengeluh, banyak penyedia diam-diam melewati pengiriman berikutnya. Ini sering menjebak penguji yang memakai ulang alamat lama.
5. Apa kata server penerima? Log penyedia umumnya menampilkan balasan SMTP, dan teks itu adalah baris paling berguna dalam seluruh penyelidikan.
6. Apakah DNS benar? Periksa SPF, DKIM, dan DMARC untuk domain pengirim yang sebenarnya.
7. Apakah ada tetapi tersembunyi? Folder spam, tab, dan filter klien datang terakhir, setelah akun contoh bisa menunjukkannya kepada Anda.

Apa yang dikatakan balasan SMTP kepada Anda

Menurut RFC 5321, balasan yang diawali 4 adalah kegagalan sementara, dan pengirim harus mencoba lagi nanti. Balasan yang diawali 5 bersifat permanen. Kode status yang disempurnakan dari RFC 3463 menambahkan rincian sesudahnya. Baris log rekaan mungkin tampak seperti ini, murni sebagai contoh format:

Hanya contoh: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"

Bacalah dari kiri ke kanan. Angka 5 berarti percobaan ulang tidak akan membantu. Keluarga 5.7 menyangkut keamanan atau kebijakan, yang mengarahkan Anda ke DNS dan penandatanganan, dan menjauhkan dari alamat penerima. Tabel di bawah memberi titik awal untuk pola-pola umum.

Yang Anda lihat	Lapisan yang paling mungkin	Tempat pertama untuk dilihat
Tidak ada apa pun di log penyedia	Aplikasi atau antrean	Log aplikasi dan job yang gagal
Penyedia menyatakan "dropped" atau "suppressed"	Daftar penekanan penyedia	Hapus alamat uji, atau pakai yang baru
API mengembalikan sukses, tetapi tidak pernah tercatat terkirim	Mode sandbox masih aktif	Pengaturan penyedia untuk lingkungan itu
5.1.1 atau sejenisnya	Alamat penerima	Salah ketik, dan validasi formulir yang mengubah alamat
5.7.26 di Gmail	Autentikasi	SPF, DKIM, dan keselarasan dengan domain From
Penundaan 4xx yang hilang setelah beberapa lama	Penerima memperlambat Anda	Volume, reputasi, atau IP pengirim baru
Terkirim di kotak masuk eksternal, hilang di Gmail	Kebijakan atau penyaringan penerima	Akun contoh dan pedoman pengirim Google
Tiba, tetapi tautan menyatakan "sudah dipakai"	Pemindai mengambil tautan lebih dulu	Tebus token dengan POST, bukan GET
Tautan mengarah ke peringatan keamanan	Domain pelacakan klik	Sertifikat pada subdomain pelacakan
Tiba dua kali	Logika percobaan ulang	Idempotensi job dan batas waktu yang memicu percobaan ulang
Tiba sangat terlambat	Antrean	Kapasitas worker, dan apakah surat reset berbagi antrean dengan surat massal

Baris terakhir itu adalah poin rancangan yang layak satu kalimat tambahan. Jika reset kata sandi berbagi antrean dengan pengiriman buletin, mereka menunggu di belakangnya. Beri surat transaksional antreannya sendiri, dan idealnya subdomain serta aliran pengiriman sendiri, agar masalah pemasaran tidak menunda login.

Perintah yang mempersingkat pencarian

Anda bisa memeriksa sebagian besar ini tanpa meninggalkan terminal. Dalam contoh ini, ganti nama contoh dengan nama Anda sendiri.

• dig +short MX example.com menunjukkan ke mana sebuah domain menerima surat. Jawaban kosong perlu dilihat lebih dekat, karena RFC 5321 membolehkan pengirim kembali ke catatan alamat, sedangkan jawaban 0 . adalah MX null menurut RFC 7505, yang berarti domain itu sama sekali tidak menerima surat.
• dig +short TXT example.com menunjukkan catatan SPF di antara catatan teks lainnya.
• dig +short TXT selector._domainkey.example.com menunjukkan kunci DKIM. Ambil selector sebenarnya dari nilai s= pada header DKIM-Signature pesan.
• dig +short TXT _dmarc.example.com menunjukkan kebijakan DMARC.
• openssl s_client -starttls smtp -connect smtp.example.com:587 memeriksa bahwa Anda bisa menjangkau relay dan menampilkan sertifikatnya. Kegagalan di sini berarti masalah firewall atau TLS, jauh sebelum urusan konten.
• swaks --to qa@example.test --from app@example.test --server localhost:1025 mengirim pesan sederhana secara manual. Ia melewati aplikasi Anda, jadi Anda bisa tahu apakah masalahnya milik kode atau milik jalurnya.

Untuk bukti tingkat header, tampilan yang paling bisa diandalkan adalah kotak surat yang Anda kendalikan di penyedia besar. Di Gmail, buka pesan, gunakan menu tiga titik dan pilih Tampilkan pesan asli, yang mencantumkan hasil SPF, DKIM, dan DMARC di bagian atas. Ingat bahwa "lulus" di satu penerima tidak menjamin penerima lain.

Apa yang diperiksa di setiap alur

"Apakah sampai?" adalah pertanyaan pertama, dan biasanya yang paling tidak menarik. Setiap alur punya cara sendiri untuk salah sesudahnya.

Reset kata sandi

OWASP Forgot Password Cheat Sheet adalah rujukan untuk dijadikan dasar di sini. Ia meminta pesan yang konsisten baik akun ada maupun tidak, respons dengan waktu yang seragam, token yang acak, panjang, tersimpan aman, dan sekali pakai, serta Referrer-Policy: no-referrer pada halaman reset.

• Halaman permintaan menampilkan pesan yang sama untuk alamat terdaftar dan tidak terdaftar, dan memakan waktu yang kurang lebih sama. Balasan instan untuk alamat yang tidak dikenal membocorkan sebanyak yang bisa dibocorkan redaksinya.
• Tautan berfungsi sekali. Buka untuk kedua kalinya dan Anda mendapat penjelasan yang jelas dengan cara untuk meminta yang lain.
• Meminta reset baru membatalkan tautan lama, atau rancangan Anda menyatakan lain dengan sengaja.
• Kedaluwarsa ditegakkan oleh server dan telah diuji dengan menunggu, atau dengan mengubah waktu di lingkungan uji.
• Reset yang berhasil mengirim email konfirmasi, dan sesi lain ditangani sesuai kebijakan Anda.
• Membuka tautan tidak mengubah apa pun dengan sendirinya. Token ditebus saat formulir dikirim.
• Halaman reset tidak mengirim URL-nya ke analitik pihak ketiga atau pelacakan galat.
• Batas laju berlaku per akun maupun per IP, agar tak seorang pun membanjiri kotak masuk orang asing.
• Alamat dengan huruf besar-kecil campuran atau tanda plus bekerja sama seperti alamat sederhana.

Verifikasi pendaftaran

• Satu pendaftaran mengirim satu pesan, termasuk saat job diulang.
• Tautan atau kode berfungsi sekali, dan halaman tautan kedaluwarsa menawarkan jalan ke depan.
• Kirim ulang membatalkan token sebelumnya atau berdampingan dengannya sesuai rancangan, dan dibatasi lajunya.
• Akun yang belum terverifikasi memiliki pembatasan persis seperti yang Anda maksudkan.
• Mendaftar lagi dengan alamat terdaftar tidak memberi tahu pengunjung anonim bahwa akun itu ada, bila produk Anda menganggap itu sensitif. Pola yang umum adalah mengirim email kepada pemilik yang ada.
• Tautan mengarah ke lingkungan yang benar. Pesan staging yang menaut ke produksi cepat atau lambat akan mengubah data produksi.

Kode login dan magic link

• Kode cukup panjang, kedaluwarsa cepat, dan punya batas percobaan.
• Magic link menampilkan halaman pendaratan dengan sebuah tombol, dan menebus pada POST itu, sehingga GET dari pemindai tidak berbahaya.
• Membuka tautan di perangkat lain melakukan apa yang dinyatakan rancangan Anda, dan pengguna dapat mengetahui apa yang terjadi.
• Baris subjek memuat kode hanya bila Anda sudah memutuskan itu dapat diterima, karena notifikasi menampilkannya di layar kunci.

Pergantian alamat email

• Konfirmasi dikirim ke alamat baru, dan tidak ada yang berubah sampai dikonfirmasi.
• Pemberitahuan dikirim ke alamat lama, agar pemilik sebenarnya dapat bereaksi terhadap perubahan tanpa izin.
• Token reset yang masih berlaku berhenti berfungsi setelah perubahan.
• Dua kotak masuk sementara membuat yang satu ini cepat dijalankan secara manual.

Undangan, tanda terima, dan notifikasi

• Undangan kepada orang yang belum punya akun mengarah ke pendaftaran dengan alamat terisi atau terkunci, sesuai rancangan. Undangan yang kedaluwarsa atau dicabut menyatakannya.
• Undangan tidak bisa diterima oleh akun lain kecuali rancangan Anda mengizinkannya.
• Tanda terima menampilkan jumlah, mata uang, tanggal, dan zona waktu yang benar untuk lokal pengguna, dan lampiran memiliki nama yang masuk akal serta terbuka dengan benar.
• Perubahan preferensi berlaku pada pengiriman berikutnya.
• Surat yang tidak esensial punya fitur berhenti berlangganan yang berfungsi, dan surat akun serta keamanan jelas terpisah. Artikel kami tentang kelebihan buletin menunjukkan seperti apa hal itu dari sisi pembaca.
• Templat terjemahan tersedia untuk setiap bahasa yang didukung, dengan tata letak kanan-ke-kiri yang benar bila relevan, dan tanpa fragmen yang belum diterjemahkan di subjek.

Meninjau kode token

Menguji lewat kotak masuk menunjukkan perilaku. Tinjauan kode singkat menangkap cacat rancangan yang tidak akan ditunjukkan kotak masuk mana pun. Saat Anda membaca kode di balik reset, verifikasi, dan magic link, carilah hal-hal ini.

• Sumber acak. Harus berupa generator yang aman secara kriptografis, seperti secrets.token_urlsafe(32) di Python, crypto.randomBytes(32) di Node, atau random_bytes(32) di PHP. Stempel waktu, ID yang bertambah, atau hash dari email tidak dapat diterima.
• Panjang. Token tautan biasanya membawa setidaknya 128 bit keacakan. Kode enam digit hanya layak dengan kedaluwarsa yang ketat dan batas percobaan.
• Penyimpanan. Simpan hash dari token, agar kebocoran basis data tidak membagikan tautan reset yang berfungsi.
• Perbandingan. Gunakan fungsi waktu-konstan seperti hmac.compare_digest, hash_equals, atau crypto.timingSafeEqual di tempat Anda membandingkan nilai rahasia secara langsung.
• Tujuan. Token verifikasi tidak boleh berfungsi sebagai token reset, dan token untuk satu akun tidak boleh berfungsi untuk akun lain.
• Kedaluwarsa. Server menyimpan waktu kedaluwarsa, sehingga tidak dapat diubah dengan mengedit tautan.
• Pembatalan. Pemakaian token, perubahan kata sandi lewat jalur lain, atau pergantian email semuanya harus membatalkan token yang masih berlaku.
• Pencatatan. URL lengkap berisi token tidak boleh sampai ke log aplikasi, peristiwa analitik, atau pelacak galat. Periksa log akses HTTP Anda juga.

Header dan autentikasi

Buka sumber mentah di penangkap untuk melihat apa yang dihasilkan aplikasi Anda, dan di kotak surat yang Anda kendalikan di penyedia besar untuk melihat apa yang ditambahkan penyedia dan jaringan.

Header atau elemen	Yang diverifikasi
From	Nama merek yang benar, pada domain yang Anda miliki dan autentikasi
Reply-To	Kotak surat yang dipantau, atau dihilangkan dengan sengaja
Return-Path	Domain bounce, selaras dengan domain Anda bila Anda mengandalkan SPF untuk DMARC
DKIM-Signature	Ada, dengan domain d= yang selaras dengan domain From
Message-ID	Ada dan unik, karena itu kunci Anda untuk menelusuri di log penyedia
Content-Type	multipart/alternative dengan bagian HTML dan teks biasa
List-Unsubscribe, List-Unsubscribe-Post	Ada pada surat massal dan pemasaran, mendukung berhenti berlangganan satu klik menurut RFC 8058
Auto-Submitted	auto-generated pada surat otomatis, sebagaimana didefinisikan RFC 3834, untuk membantu mencegah perulangan balasan

Beberapa aturan untuk diperiksa sebelum Anda merilis domain pengirim baru. Evaluasi SPF tidak boleh melebihi sepuluh pencarian DNS (RFC 7208), dan melampaui batas itu adalah cara mudah untuk gagal setelah menambahkan satu vendor lagi ke catatan Anda. DKIM membutuhkan catatan selector penyedia yang diterbitkan dan terverifikasi. DMARC membutuhkan catatan pada domain From Anda, biasanya dimulai dari p=none dengan laporan diaktifkan lalu diperketat setelah keselarasan terkonfirmasi.

Volume juga mengubah aturan. Pedoman Google menganggap pengirim sebagai massal pada sekitar 5.000 pesan ke akun Gmail pribadi dalam sehari, dan pengirim massal membutuhkan SPF, DKIM, dan DMARC, berhenti berlangganan satu klik pada surat promosi, serta tingkat spam yang dilaporkan pengguna dijaga di bawah 0,3%, dengan 0,1% sebagai target yang disarankan. Penyedia lain punya aturan sendiri. Amazon SES, misalnya, menempatkan akun dalam peninjauan pada tingkat bounce 5% atau tingkat keluhan 0,1%. Baca angka terkini dari dokumentasi penyedia Anda sebelum merencanakan berdasarkan angka itu, karena memang berubah.

Penanganan dan validasi alamat

Formulir menolak alamat yang valid lebih sering daripada yang disadari orang, dan bug validasi di hulu bisa tampak persis seperti kegagalan pengiriman. Uji milik Anda dengan ini.

Masukan	Penanganan yang diharapkan	Bug yang umum
user+tag@example.com	Terima	Ekspresi reguler menolak tanda plus
User@Example.COM	Terima, dan perlakukan domain tanpa membedakan huruf besar-kecil	Akun ganda yang hanya berbeda huruf besar-kecil
o'brien@example.com	Terima	Ditolak, atau merusak kueri atau templat bila tidak di-escape
first.last@sub.example.co.uk	Terima	Validasi mengasumsikan satu titik di domain
Spasi di awal atau akhir	Pangkas dulu	"Email tidak valid" pada tempelan yang benar
Alamat yang sangat panjang	Terapkan 64 karakter untuk bagian lokal dan 254 secara keseluruhan	Kolom basis data yang pendek memotongnya secara diam-diam
Domain dan alamat internasional	Terima atau tolak secara konsisten, dengan pesan yang jelas	Crash pada penyandian atau pencatatan
Domain tanpa rute surat	Beri peringatan atau tolak	Akun yang tidak pernah bisa terverifikasi

Validasi secara longgar di formulir, lalu biarkan email konfirmasi membuktikan bahwa alamat itu berfungsi. Ekspresi reguler yang ketat membuat Anda kehilangan pengguna sungguhan dan memberi tahu Anda sangat sedikit tentang apakah sebuah kotak surat ada.

Jika produk Anda menolak domain sekali pakai di produksi, proses QA Anda tetap butuh jalan lewat di staging. Opsinya mencakup daftar izin domain uji di luar produksi, flag yang mematikan pemeriksaan di lingkungan uji, atau domain uji milik Anda sendiri. Jangan melemahkan aturan produksi demi mempermudah pengujian. Dan jika Anda sedang memutuskan perlu tidaknya aturan itu sama sekali, tulisan kami tentang mengapa situs web memblokir email sekali pakai menguraikan biaya dan manfaatnya dari sudut pandang pemilik.

Bagaimana tampilannya

Tampilan adalah tempat tinjauan desainer paling membantu, dan membutuhkan pesan sungguhan di klien sungguhan.

• Bagian teks biasa enak dibaca dan memuat tautan lengkap. "Klik tombol di bawah" tidak berguna di sana.
• Mode gelap menjaga logo tetap terlihat dan kontras terjaga. VookMail punya mode gelap, yang merupakan awal, dan klien yang disukai pengguna Anda adalah ujian sebenarnya.
• Dengan gambar diblokir, ajakan bertindak tetap berupa tautan teks sungguhan atau tombol HTML.
• Tombol cukup besar untuk diketuk, dan URL panjang tidak merusak tata letak ponsel.
• Teks pratinjau ditulis dengan sengaja, tanpa sisa kata-kata templat.
• Judul bersifat semantik, kontras cukup, teks tautan deskriptif, dan HTML punya atribut bahasa.
• Data yang hilang tidak menghasilkan "Halo {first_name}" atau "Halo ,".
• Ukuran pesan tetap jauh di bawah sekitar 102 KB, titik ketika Gmail banyak dilaporkan memotong pesan panjang. Pemotongan bisa menyembunyikan footer Anda dan tautan berhenti berlangganan di dalam isi.

Pagar pengaman terhadap kecelakaan

Insiden email yang memalukan sebagian besar adalah kesalahan konfigurasi: surat staging sampai ke pelanggan sungguhan, produksi memakai kunci uji, tautan ke localhost. Beberapa pengaturan mencegah sebagian besarnya.

Simpan kredensial terpisah per lingkungan, di variabel lingkungan atau pengelola rahasia. Di luar produksi, pakai daftar izin penerima agar pengirim surat hanya mengantarkan ke domain uji yang disetujui dan mengalihkan atau membuang yang lain. Bangun setiap tautan dari satu pengaturan, seperti APP_URL, sehingga templat tidak mengandung host yang ditulis langsung. Beri awalan pada subjek non-produksi dengan sesuatu seperti [STAGING] agar pesan yang salah alamat jelas bagi siapa pun yang menerimanya.

Jika Anda menyalin data produksi ke staging, ganti setiap alamat asli dengan alamat sintetis sebelum worker surat mana pun dimulai. Urutannya penting, karena worker yang mulai lebih dulu bisa langsung memproses surat terjadwal. Dan lacak mode sandbox secara sengaja untuk setiap lingkungan. Meluncur dengan produksi yang masih di sandbox adalah kasus klasik: API mengembalikan sukses, log tampak bersih, dan tak ada surat yang keluar.

Rangkaian otomatis sebaiknya tetap di infrastruktur yang Anda kendalikan

Kotak masuk sementara publik adalah ketergantungan yang salah untuk CI. Mengikis halaman web milik orang lain itu rapuh, dan build Anda akan gagal karena alasan yang tak berkaitan dengan kode Anda. Ia juga menaruh lalu lintas uji Anda pada layanan yang tidak Anda jalankan. Pesan di sana bisa dibaca siapa pun yang punya alamatnya, jadi tidak ada yang otomatis boleh bergantung padanya.

Susunan yang masuk akal tampak seperti ini. Pembantu framework memastikan surat yang tepat diminta. Kontainer Mailpit di tumpukan uji Anda menerima pesan sungguhan, dan pengujian Anda membacanya lewat API HTTP Mailpit (GET /api/v1/messages), mengekstrak tautan, dan mengikutinya. Mode uji penyedia melatih webhook dan penanganan galat. Job malam di domain uji Anda sendiri mengirim lewat penyedia sungguhan dan membaca hasilnya lewat webhook masuk, sehingga Anda mendapat sinyal harian bahwa pengiriman nyata masih berfungsi.

Surat sementara termasuk dalam bagian pengujian yang dikerjakan manusia: sesi eksploratori ketika Anda cepat butuh identitas baru, uji asap sebelum rilis, mereproduksi laporan pengguna, tinjauan salinan dan desain, serta pengujian di ponsel. Untuk yang terakhir, tombol QR atau aplikasi dari Google Play atau Huawei AppGallery membawa kotak masuk ke perangkat uji. Periksa bahwa tautan membuka aplikasi Anda bila terpasang dan beralih ke halaman web yang berfungsi bila tidak, dan bahwa aplikasi mengenali status terverifikasi tanpa meminta login baru.

Kasus uji yang selamat dari serah terima

Kasus uji yang konsisten lebih mudah diulang tiap rilis dan dioper antarpenguji. Contoh ini memuat kolom-kolom yang cenderung penting.

Kolom	Contoh
ID uji	EMAIL-RESET-03
Alur	Reset kata sandi, pemakaian ulang token
Prasyarat	Akun uji terverifikasi di staging, dengan alamat sementara yang baru
Langkah	Minta reset, buka tautan, setel kata sandi baru, buka tautan yang sama lagi
Hasil yang diharapkan	Pemakaian kedua menjelaskan bahwa tautan tidak lagi valid dan menawarkan permintaan baru
Bukti	Tangkapan layar, Message-ID bila ada, stempel waktu, alamat yang dipakai
Lingkungan	Nomor build staging dan konfigurasi surat

Menaruh ID uji di nama pengguna, seperti email-reset-03-x7, mengikat setiap kotak masuk pada kasusnya dan mencegah dua penguji bertabrakan pada satu alamat. Akhiran acak yang pendek ada karena siapa pun dapat membuka kotak masuk bila menebak namanya.

Apa yang tidak boleh dikirim ke kotak masuk publik

Anggap kotak masuk sementara mana pun dapat dibaca siapa saja yang tahu alamatnya, dan uji sesuai itu.

• Kirim hanya data sintetis: nama palsu, pesanan palsu, alamat palsu. Data pelanggan sungguhan tidak pantas ada di sana, dan bergantung pada tempat Anda beroperasi, mengirimkannya juga bisa menimbulkan masalah hukum bagi Anda.
• Jangan pernah mengirim kunci API, kredensial basis data, atau undangan admin untuk sistem sungguhan.
• Hapus akun uji secara teratur, terutama yang berhak istimewa. Pengguna uji admin yang terikat pada kotak masuk publik adalah jalan masuk bila orang lain membuka kotak masuk itu dan meminta reset. Karena alamat itu tidak dicadangkan untuk Anda setelah dibersihkan, risiko ini bertahan sesudah pengujian.
• Jangan pernah memakai alamat sementara sebagai pemilik akun produksi sungguhan atau layanan pihak ketiga yang diandalkan perusahaan Anda.
• Ketahui masa penyimpanannya. Pesan dan lampiran hilang setelah sekitar sehari, dan kebijakan privasi memuat rinciannya.

Menguji produk Anda sendiri adalah salah satu penggunaan sah yang paling jelas dari email sekali pakai. Pertahankan begitu: ujilah sistem yang Anda miliki atau berwenang untuk diuji. Jangan memakai kotak masuk sementara untuk membuat akun di layanan perusahaan lain yang melanggar ketentuan mereka, untuk mengumpulkan uji coba, atau untuk menguji beban formulir pendaftaran milik orang lain. Syarat dan ketentuan mencakup penggunaan yang dapat diterima, dan halaman metodologi menjelaskan cara kerja layanan ini. VookMail adalah bagian dari jaringan alat gratis PAYATE.

Sebelum Anda merilis

1. SPF, DKIM, dan DMARC terverifikasi untuk domain pengirim produksi yang sebenarnya, dengan domain From yang selaras.
2. Pengirim surat produksi memakai kredensial produksi, dengan mode sandbox mati, dikonfirmasi oleh pesan sungguhan.
3. Verifikasi pendaftaran diterima di alamat eksternal yang baru, tautan dipakai sekali, kedaluwarsa diuji.
4. Reset kata sandi diuji dari ujung ke ujung, termasuk respons identik untuk alamat yang tidak dikenal dan pesan konfirmasi.
5. Token reset dan magic link ditebus lewat pengiriman formulir, sehingga GET dari pemindai tidak menghabiskannya.
6. Pergantian email mengirim ke alamat baru maupun lama.
7. Semua tautan mengarah ke host produksi lewat HTTPS, termasuk yang ditulis ulang oleh pelacakan klik.
8. Surat transaksional dipisahkan dari surat massal, setidaknya pada antreannya.
9. HTML dan teks biasa sama-sama ada dan terbaca, dengan mode gelap dan gambar yang diblokir sudah diperiksa.
10. Pemeriksaan penempatan di akun contoh bila domain atau templat berubah signifikan.
11. Berhenti berlangganan berfungsi pada surat yang tidak esensial, dan templat terjemahan telah ditinjau.
12. Bukti dilampirkan pada tiket rilis, dan angka bounce serta keluhan ada di dasbor yang akan dipantau seseorang setelah peluncuran.

Pertanyaan developer tentang ini

Kotak masuk sungguhan menerima surat saya. Apakah saya aman di Gmail?

Tidak. Pengiriman ke satu domain menunjukkan bahwa pesan Anda keluar, menemukan rute, dan diterima di sana. Gmail menerapkan aturan autentikasi dan penyaringannya sendiri, begitu pula setiap penyedia besar lainnya. Pakai akun contoh dan Postmaster Tools milik Google untuk pertanyaan itu.

Bisakah saya memakai ulang alamat uji yang sama?

Bisa dalam satu sesi, tetapi alamat baru memberi pengujian yang lebih bersih. Alamat lama mengumpulkan entri penekanan dan pesan lama, dan pada layanan sementara kotak masuk dibersihkan setelah sekitar sehari.

Surat tiba di penangkap saya tetapi tidak secara eksternal. Dari mana harus mulai?

Penangkap hanya menunjukkan bahwa aplikasi Anda menghasilkan pesan dan tidak lebih dari itu, jadi mulailah dari log aktivitas penyedia. Sering kali jawabannya adalah pengaturan sandbox, entri penekanan, kredensial yang salah, atau penolakan SMTP yang menyebut autentikasi.

Berapa lama tautan reset sebaiknya berlaku?

Cukup singkat untuk membatasi kerusakan dan cukup lama agar surat yang lambat sempat tiba. Banyak tim memutuskan antara 15 menit dan satu jam, tetapi itu bergantung pada risiko Anda dan seberapa cepat surat Anda terkirim, dan surat pengguna Anda bisa tertunda di luar kendali Anda. Apa pun yang Anda pilih, uji keadaan kedaluwarsa dan beri tahu orang apa yang harus dilakukan selanjutnya.