Checklist Go-Live Email Transaksional — 12 Hal Sebelum Rilis Aplikasi Anda
Checklist Go-Live Email Transaksional — 12 Hal Sebelum Rilis Aplikasi Anda
Aplikasi sudah lolos QA, tim siap rilis. Lalu email OTP pertama masuk folder spam — atau tidak masuk sama sekali. Skenario ini terjadi berulang kali di startup Indonesia, dan hampir selalu penyebabnya bukan kode, tapi persiapan infrastruktur email yang dilewati.
Berikut checklist 12 poin yang kami gunakan sendiri sebelum fitur email transaksional dibuka ke produksi. Print, centang satu per satu.
1. Domain pengirim terpisah dari domain utama
Jangan kirim email transaksional langsung dari domainutama.com. Kalau reputasi pengirim tergelincir, seluruh domain utama ikut tercoreng — termasuk email internal tim. Pisahkan: mail.domainutama.com atau notify.domainutama.com. Satu reputasi per subdomain, kerusakan tidak menular.
2. SPF, DKIM, DMARC — ketiga-tiganya, bukan dua
SPF saja tidak cukup sejak Gmail dan Yahoo mewajibkan autentikasi penuh untuk pengirim massal (berlaku sejak Februari 2024). Urutan pemasangan:
- SPF: TXT record
v=spf1 include:... -all - DKIM: record CNAME/TXT dari provider email Anda (di MailAnvil,
POST /v1/domainslangsung menghasilkan tiga record yang siap ditempel di Cloudflare DNS) - DMARC: mulai dari
p=nonedengan laporan kerua=— pantau dulu 2–4 minggu sebelum menaikkan kequarantine
3. Verifikasi domain di provider SEBELUM hari-H
Verifikasi domain bukan instan. DNS propagation + pengecekan provider bisa makan beberapa jam. Kalau verifikasi domain dilakukan pagi hari rilis, email OTP pertama pengguna akan menunggu juga. Verifikasi minimal H-3.
4. Warmup volume, jangan langsung gas
Reputasi IP pengirim baru itu dingin. Kirim 5.000 email di hari pertama setelah verifikasi = lompatan anomali yang dicurigai filter Gmail. Ramp: mulai puluhan per hari, naik dua kali lipat tiap harinya. MailAnvil menerapkan ini otomatis — akun baru dibatasi 10 email/hari dan naik bertahap selama satu minggu. Terdengar lambat, tapi justru melindungi reputasi domain Anda dari hari pertama.
5. Halaman pendaftaran: tangkap email dengan benar
Validasi format email di sisi klien itu pemanis. Yang menentukan: cek domain terhadap daftar domain disposable, dan normalisasi (Gmail mengabaikan titik di local-part — budi.santoso dan budisantoso sama). Email salah ketik yang masuk antrian = hard bounce yang menggerus reputasi sebelum Anda sempat kirim satu pesan pun.
6. Tangani bounce sejak email pertama
Setiap hard bounce harus: dicatat, penerima masuk suppression list, dan tidak pernah dikirimi lagi. Kirim ulang ke alamat mati adalah cara tercepat menurunkan deliverability. Pastikan provider Anda otomatis memproses event bounce (di MailAnvil: SNS dari SES memperbarui status per penerima dan mengisi suppression list tanpa campur tangan Anda).
7. Kelola complaint rate di bawah 0,3%
Ambang aman: complaint rate di bawah 0,3% dari total pengiriman. Di atas itu, Gmail mulai menahan email Anda di spam secara sistemik. Pastikan setiap email transaksional punya link unsubscribe atau cara berhenti yang jelas — ya, termasuk email invoice. Email transaksional memang tidak wajib unsubscribe secara hukum, tapi tombol "berhenti terima notifikasi ini" di pengaturan akun mencegah pengguna menekan "Report spam" sebagai gantinya.
8. Template responsif + plain text fallback
Banyak email transaksional dibuka di aplikasi mail bawaan HP dengan koneksi 3G yang tidak stabil. Template HTML tanpa plain-text fallback = pengalaman rusak untuk sebagian pengguna. Simpan versi teks polos untuk setiap template, dan pastikan API kirim menerima keduanya (html + text).
9. Idempotency untuk tombol yang diklik dua kali
Pengguna klik "Kirim OTP" dua kali karena loading lambat. Tanpa idempotency key, dua email terkirim, dua kode OTP berbeda, kebingungan pun lahir. API email yang baik menerima header Idempotency-Key — kirim UUID unik per percobaan transaksi dari aplikasi Anda, dan kirim ulang dengan key yang sama akan mengembalikan hasil pertama, bukan email kedua.
10. Monitoring: jangan tunggu pengguna komplain
Metrik minimum yang harus terlihat di dashboard: delivered, bounced, complained, per penerima. Kalau Anda hanya tahu "email terkirim" dari log API tanpa status akhir, Anda buta terhadap masalah spam placement — masalah yang hanya terlihat pengguna, bukan log Anda.
11. Kuota dan rate limit diketahui tim
Hari rilis biasanya hari lonjakan pendaftaran. Ketahui batas kuota harian dan rate limit provider Anda, siapkan penanganan 429 (backoff + retry), dan pastikan antrian email di aplikasi Anda tidak meledak saat limit tercapai. Lebih baik OTP tertunda 30 detik daripada antrian menumpuk tanpa retry.
12. Uji dengan mailbox simulator, bukan email teman
Kirim ke Gmail pribadi CEO bukan tes deliverability — itu tes "tidak error". Mailbox simulator resmi (misalnya milik AWS SES) memberikan alamat yang mensimulasikan bounce, complaint, dan delivered tanpa mengotori reputasi domain sungguhan. Gunakan itu di staging, dan simpan kredensial produksi hanya untuk produksi.
Bonus: pertimbangkan biaya dalam Rupiah sejak awal
Banyak startup Indonesia memilih provider luar karena familiar, lalu kena kenaikan biaya konversi USD + biaya kartu + PPN impor di tagihan. Pricing lokal dengan pembayaran QRIS/GoPay menghilangkan satu variabel kejutan lagi di buku besar Anda. Bandingkan total biaya per 10.000 email, bukan harga plan headline-nya.
Cek sendiri checklist Anda: yang sudah tercentang berapa? Kalau poin 2, 4, dan 6 masih kosong, jangan rilis dulu — tiga poin itu menentukan apakah email Anda masuk inbox atau tidak.
Coba MailAnvil gratis di mailanvil.com — domain verification otomatis, warmup schedule bawaan, suppression list otomatis, harga mulai Rp0. Untuk developer Indonesia, oleh developer Indonesia.