Email Deliverability: SPF, DKIM, DMARC, dan Transactional Email yang Tidak Masuk Spam

Email transactional sering dianggap selesai ketika fungsi `send_email()` mengembalikan sukses. Padahal sukses dari aplikasi hanya berarti email diterima oleh mail server pengirim. Belum tentu email sampai ke inbox, belum tentu tidak masuk spam, dan belum tentu user melihatnya tepat waktu.

Untuk aplikasi web, email deliverability adalah bagian dari produk. Verifikasi email, reset password, invoice deposit, notifikasi keamanan, dan update transaksi semuanya bergantung pada email yang benar-benar sampai. Kalau email gagal, user merasa aplikasi yang rusak.

SPF: siapa yang boleh mengirim email untuk domain

SPF adalah DNS record yang memberi tahu server penerima IP atau layanan mana yang boleh mengirim email atas nama domain. Jika aplikasi memakai mail server berbeda dari hosting utama, SPF harus mencakup pengirim tersebut. SPF yang salah bisa membuat email terlihat mencurigakan.

Jangan menumpuk terlalu banyak include SPF tanpa memahami limit DNS lookup. Record yang terlalu kompleks bisa gagal dievaluasi. Simpan konfigurasi sederhana dan dokumentasikan siapa saja yang berhak mengirim.

DKIM: tanda tangan digital untuk email

DKIM menandatangani email agar penerima bisa memverifikasi bahwa isi email tidak berubah dan benar dikirim oleh domain yang sesuai. Untuk transactional email, DKIM sangat penting. Tanpa DKIM, domain baru atau volume email yang naik mendadak lebih mudah dicurigai.

DMARC: aturan ketika SPF atau DKIM gagal

DMARC memberi kebijakan kepada penerima: apa yang harus dilakukan jika email gagal autentikasi. Mulailah dari mode monitoring, lalu naikkan kebijakan secara bertahap. Jangan langsung memakai policy paling ketat kalau belum yakin semua sumber email sudah benar.

Reverse DNS dan reputasi IP

Jika mengirim dari server sendiri, reverse DNS harus sesuai. Banyak provider email melihat reputasi IP, domain, histori bounce, dan pola volume. Mengirim email banyak dari IP baru tanpa pemanasan bisa menurunkan deliverability.

Konten email juga berpengaruh

Subject yang terlalu agresif, terlalu banyak link, HTML berantakan, atau attachment tidak perlu bisa membuat email masuk spam. Untuk email transactional, gunakan subject jelas, isi singkat, dan link yang relevan. Jangan memakai bahasa marketing berlebihan pada email reset password atau verifikasi.

Bounce dan complaint handling

Jika email hard bounce, jangan terus mengirim ke alamat yang sama. Jika user menandai spam, reputasi domain ikut turun. Aplikasi perlu mencatat bounce, complaint, dan kegagalan pengiriman. Untuk email penting, tampilkan juga fallback di dashboard agar user tahu statusnya.

Email OTP dan inbox testing

Banyak produk memakai email OTP atau magic link. Saat membangun fitur ini, tim QA perlu mengetes apakah subject benar, kode masuk, expired code bekerja, dan resend tidak membuat duplikasi. OTPZap mendukung kebutuhan verifikasi dan inbox sehingga proses testing bisa dipisahkan dari email pribadi.

Checklist deliverability

• Pastikan SPF mencakup semua pengirim resmi.
• Aktifkan DKIM untuk domain pengirim.
• Gunakan DMARC monitoring sebelum policy ketat.
• Cek reverse DNS jika mengirim dari server sendiri.
• Catat bounce dan complaint.
• Monitoring email penting seperti reset password dan verifikasi.