Email reset kata sandi harus tiba selagi tautannya masih berlaku. Tanda terima harus menjelaskan pesanan yang benar tanpa muncul kembali setelah percobaan ulang.
Persyaratan ini dimulai di aplikasi Anda dan berlanjut setelah layanan email menerima pesan.
Apa yang harus ada dalam pesan transaksional?
Berikan informasi atau tindakan yang dibutuhkan penerima untuk peristiwa yang memicu email tersebut. Tanda terima mengonfirmasi pesanan. Pesan reset menyediakan cara untuk mendapatkan kembali akses.
Gunakan nama pengirim yang mudah dikenali. Tulis subjek yang mengidentifikasi peristiwa. Arahkan balasan ke alamat yang dipantau tim Anda jika alur kerja memerlukan dukungan.
Untuk contoh tanda terima, gunakan subjek seperti Receipt for order 8472. Cantumkan referensi pesanan, item yang dibeli, dan kontak dukungan. Untuk pesan reset, tempatkan tindakan reset di bagian awal dan sebutkan kapan kedaluwarsanya.
Uji konten HTML dan teks biasa. Pastikan tindakan utama tetap dapat dipahami di layar sempit dan saat gambar dinonaktifkan.
Pisahkan promosi dari pesan akun yang diperlukan. Email transaksional versus email pemasaran menjelaskan bagaimana tujuan pesan memengaruhi kontrol penerima dan kebijakan pengiriman.
Bagaimana cara mengautentikasi dan memisahkan pengirim?
Autentikasi domain pengirim sebelum lalu lintas produksi. Persyaratan pengirim Gmail mewajibkan SPF atau DKIM untuk semua pengirim ke akun Gmail pribadi. Pengirim yang melebihi 5.000 pesan per hari memerlukan SPF, DKIM, dan DMARC.
Gunakan identitas pengirim terpisah untuk email operasional dan pemasaran. Panduan Yahoo merekomendasikan pemisahan pemasaran massal dari lalu lintas transaksional berdasarkan IP atau domain penandatanganan DKIM. Keduanya membawa sinyal reputasi, jadi alamat From yang berbeda saja tidak memisahkan infrastruktur.
Tingkatkan volume pengiriman secara bertahap. Panduan Google memperingatkan lonjakan mendadak. Periksa penangguhan dan bounce selama peningkatan agar Anda dapat mengurangi laju saat server penerima kewalahan dengan lalu lintas.
Daftar periksa keterkiriman mencakup autentikasi dan pengelolaan reputasi pengirim yang lebih luas.
Bagaimana cara menangani supresi dan preferensi?
Periksa mengapa penerima diblokir sebelum memutuskan apakah pengiriman ulang sesuai. Opt-out pemasaran dan alamat tidak terkirim memerlukan tindakan yang berbeda.
Kebijakan kategori Bird mengizinkan email transaksional setelah opt-out khusus pemasaran. Hard bounce, supresi manual, dan opt-out yang mencakup semua pesan memblokir kedua kategori.
Kategori transaksional tidak mengesampingkan semua pembatasan penerima. Saat Bird melaporkan recipient_suppressed, periksa catatan supresi dan preferensi penerima. Mengulangi pengiriman yang sama tidak memperbaiki alamat atau mengubah kebijakan tersebut.
Bagaimana seharusnya tautan dan kode reset kedaluwarsa?
Terapkan kedaluwarsa di aplikasi yang memvalidasi tautan atau kode. Teks dalam email tidak dapat mencegah kredensial yang sudah kedaluwarsa diterima.
OWASP, komunitas keamanan aplikasi, merekomendasikan token atau kode reset yang dihasilkan secara acak dengan masa kedaluwarsa yang sesuai. OWASP juga merekomendasikan penggunaan sekali pakai. Batalkan kredensial setelah berhasil digunakan agar pesan yang sama tidak dapat mengotorisasi reset lain.
Pilih masa berlaku untuk tindakan akun dan tampilkan masa berlaku tersebut dalam pesan. Perhitungkan waktu tunggu di aplikasi Anda dan waktu pengiriman. Email yang diterima setelah kedaluwarsa memerlukan jalur untuk meminta reset baru.
Sebelum mencoba ulang pekerjaan reset yang belum terkirim, periksa apakah kredensialnya masih valid. Jangan perpanjang kedaluwarsa kredensial hanya karena upaya pengiriman gagal. Jika tidak, percobaan ulang dapat membuat kredensial tetap dapat digunakan melampaui masa berlaku yang Anda pilih.
Untuk URL reset, OWASP merekomendasikan HTTPS dan domain tujuan tepercaya. OWASP juga merekomendasikan pembatasan permintaan reset per akun untuk mencegah pembanjiran kotak masuk.
Bagaimana percobaan ulang menghindari pengiriman ganda?
Simpan catatan permanen dari peristiwa bisnis dan operasi pengirimannya. Peristiwa pesanan yang terulang harus menemukan pekerjaan tanda terima yang sudah ada, bukan membuat yang baru.
Gunakan kunci idempotensi yang sama saat mencoba ulang permintaan API yang sama setelah respons yang tidak pasti. Kontrak idempotensi Bird menyimpan respons yang sudah selesai selama tiga jam. Setelah jendela tersebut, permintaan lain dengan kunci yang sama dapat membuat pesan baru.
Batasan tersebut membuat catatan peristiwa Anda sendiri diperlukan untuk percobaan ulang yang lebih lama. Simpan ID pesan yang dikembalikan terhadap peristiwa sebelum menganggap pengiriman selesai.
Penangguhan pengiriman berbeda dari respons API yang tidak pasti. Bird mencoba ulang pengiriman yang ditangguhkan secara otomatis. Membuat pengiriman baru untuk setiap penangguhan dapat menambahkan pesan duplikat sementara pengiriman asli masih berlangsung.
Apa yang harus Anda pantau dan beri peringatan?
Lacak setiap pesan yang diharapkan melalui pengiriman. Catat hasil setiap penerima. Ukur apakah pengguna menyelesaikan tindakan yang dimaksud.
Event pengiriman Bird membedakan penerimaan, pengiriman, penangguhan, bounce, dan penolakan. Pengiriman berarti server penerima menerima pesan. Ini tidak memastikan penempatan di kotak masuk atau pembacaan.
Catat waktu peristiwa bisnis bersama waktu pengiriman dan hasil penerima. Untuk pesan reset, bandingkan waktu yang berlalu dengan sisa masa berlaku kredensial. Ukur reset yang berhasil di aplikasi Anda. Event pelacakan buka tidak membuktikan bahwa seseorang membaca pesan.
Atur peringatan di sekitar batas operasi alur kerja:
- Pekerjaan yang belum terkirim mendekati kedaluwarsanya.
- Kegagalan meningkat di atas rentang normal Anda.
- Pemrosesan webhook tertinggal.
Tetapkan pemilik yang dapat bertindak atas setiap peringatan.
| Kegagalan | Bukti yang perlu diperiksa | Pemilik dan tindakan selanjutnya |
|---|---|---|
| Tidak ada pengiriman setelah peristiwa pesanan | Pekerjaan aplikasi dan catatan peristiwa | Tim aplikasi: pulihkan pekerjaan yang hilang tanpa menduplikasi pengiriman yang sudah ada |
| Penerima disupresi | Alasan penolakan, supresi, dan preferensi | Tim dukungan atau pengiriman: selidiki pemblokiran sebelum percobaan ulang |
| Penangguhan pengiriman meningkat | Event penerima dan volume pengiriman | Tim pengiriman: periksa respons penerima dan kurangi lonjakan lalu lintas |
| Reset kedaluwarsa saat tiba | Kedaluwarsa kredensial dan stempel waktu peristiwa | Tim aplikasi: selidiki keterlambatan dan sediakan jalur permintaan baru |
| Pengiriman webhook berulang | Identifikasi webhook dan catatan pemrosesan | Tim aplikasi: lewati pekerjaan yang sudah selesai untuk peristiwa tersebut |
Verifikasi tanda tangan webhook sebelum menerima event. Panduan webhook Bird menggunakan webhook-id untuk deduplikasi, sehingga notifikasi yang dicoba ulang tidak mengulang pekerjaan aplikasi Anda.
Apa yang harus Anda periksa sebelum mengirim melalui Bird?
Uji alur kerja melalui pengiriman, hasil penerima, dan pemulihan aplikasi sebelum menggunakannya untuk pesan akun langsung.
- Verifikasi domain pengirim. Pastikan lalu lintas operasional menggunakan identitas dan pool yang dimaksud.
- Publikasikan template. Uji detail tanda terima atau tindakan reset dengan parameter representatif.
- Atur
category: "transactional"untuk konten operasional. Terapkan kebijakan supresi dan preferensi yang didokumentasikan. - Pertahankan catatan peristiwa bisnis dan kunci idempotensi. Simpan ID pesan yang dikembalikan oleh endpoint pengiriman.
- Uji penanganan kegagalan dengan sandbox email. Hasil simulasinya melewati jalur event dan webhook normal tanpa mencapai kotak masuk asli.
- Periksa linimasa per penerima di log email. Pastikan aplikasi Anda menangani hasil yang sama dan mengarahkan peringatan ke pemiliknya.