Kenapa Email yang Terkirim Bisa Tidak Diterima: Ini Penjelasan per Layernya

Log Anda mencatat "delivered." User Anda tidak menerima apa pun.

Keduanya bisa benar dalam waktu bersamaan. Dan justru di situlah masalahnya.

Yang Sistem Anda Lihat

Dari sisi sistem, semua terlihat beres.

Aplikasi mengirim request ke email API. API merespons 200 OK. Email masuk queue, diproses, dikirim ke mail server tujuan. Status di log: delivered. Tidak ada error, tidak ada alert, dashboard hijau.

Secara teknis, sistem pengirim sudah melakukan tugasnya dengan benar.

Tidak ada yang bisa dipersalahkan dari sisi ini.

Yang User Anda Lihat

Dari sisi user, ceritanya berbeda.

OTP tidak masuk. Pengguna menunggu, mencoba lagi, menunggu lagi.

Validity window habis sebelum kode sempat dipakai. Email konfirmasi pembayaran tidak kunjung masuk, pengguna tidak yakin apakah transaksinya berhasil. Notifikasi penting tidak diterima, ada sesuatu yang harusnya ditindaklanjuti tapi terlewat begitu saja.

Bagi pengguna, satu kesimpulannya: sistem ini tidak bisa diandalkan.

Kenapa Dua Cerita Ini Sama-sama Benar

Sistem pengirim mengukur satu hal: apakah request berhasil diterima dan diproses. User mengukur hal lain: apakah email sampai ke inbox mereka.

Di antara dua titik ukur itu, ada beberapa layer yang bekerja di luar kendali langsung sistem pengirim.

Queue processing. Email yang masuk queue tidak selalu diproses dalam waktu yang sama. Kalau ada lonjakan volume, email bisa antre lebih lama dari biasanya. Untuk OTP dengan validity window 5 menit, delay 6 menit di queue sudah cukup untuk membuat kode kedaluwarsa sebelum email sampai ke penerima.

SMTP relay. Setelah keluar dari queue, email perlu di-relay ke mail server tujuan. Relay bisa gagal atau tertunda karena berbagai alasan, dan tidak semua kegagalan di tahap ini menghasilkan sinyal yang jelas ke sistem pengirim.

Keputusan mail server tujuan. ISP, corporate mail server, dan spam filter punya logika evaluasi sendiri yang tidak selalu bisa diprediksi. Email bisa diterima oleh mail server tujuan dan langsung difilter ke folder spam, atau bahkan dibuang tanpa pemberitahuan balik ke pengirim. Status di sisi pengirim tetap terlihat delivered karena email memang berhasil diterima, hanya saja tidak sampai ke inbox.

Reputasi IP dan autentikasi. Konfigurasi SPF, DKIM, dan DMARC yang tidak lengkap, atau reputasi IP yang turun perlahan, meningkatkan kemungkinan email difilter. Prosesnya gradual, jarang memicu alert yang jelas sampai dampaknya sudah cukup besar untuk dirasakan.

Masalah Sebenarnya: Monitoring di Layer yang Salah

Kebanyakan tim engineering punya monitoring yang cukup baik di application layer. Server uptime dipantau. API error rate dipantau. Request latency dipantau.

Tapi semua itu beroperasi di sisi pengirim, memantau apakah sistem berjalan baik saat mengirim request. Tidak ada yang memantau apa yang terjadi pada email setelah meninggalkan sistem pengirim.

Kegagalan yang menciptakan gap antara "sistem bilang delivered" dan "user tidak menerima" terjadi di delivery layer, bukan di application layer. Dan delivery layer hampir tidak pernah masuk ke dalam observability stack standar tim engineering.

Hasilnya, anomali bisa berjalan berjam-jam atau bahkan berhari-hari tanpa ada yang mendeteksinya, sementara semua dashboard tetap hijau.

Baca juga Apakah Email Monitoring Itu Penting? Apa Manfaatnya?

Tiga Skenario yang Paling Sering Terjadi

OTP terkirim tapi sudah kedaluwarsa. Email OTP berhasil dikirim dan diterima oleh mail server tujuan. Tapi ada delay di queue sebelumnya yang membuat email baru tiba 7 menit setelah diminta. Kode sudah tidak berlaku. Dari sisi sistem: sukses. Dari sisi user: gagal.

Notifikasi difilter sebagai spam. Email notifikasi berhasil melewati seluruh pipeline dan diterima mail server tujuan. Tapi mail server mengklasifikasikannya sebagai spam karena pola pengiriman yang dianggap mencurigakan. Email masuk ke folder spam yang tidak pernah dibuka pengguna. Dari sisi sistem: delivered. Dari sisi user: tidak ada.

Soft bounce dengan retry yang terlambat. Mail server tujuan menolak email sementara. Sistem pengirim mencoba ulang secara otomatis, tapi dengan interval yang tidak disesuaikan untuk use case OTP. Email akhirnya terkirim 12 menit kemudian, saat kode sudah expired. Dari sisi sistem: eventual delivery. Dari sisi user: kegagalan.

Baca juga: Kenapa Tim Baru Tahu Ada Masalah Delivery Setelah User Complain

Yang Dibutuhkan untuk Melihat Kedua Sisi

Menutup gap ini butuh lebih dari sekadar monitoring yang lebih baik di application layer. Yang dibutuhkan adalah visibility di delivery layer itu sendiri.

Status per tahap, bukan hanya status akhir. Log yang hanya mencatat "sent" atau "delivered" tidak cukup untuk mendiagnosis masalah. Anda butuh tahu kapan email masuk queue, kapan keluar, kapan relay ke mail server tujuan berhasil, dan apa yang terjadi di sisi penerima.

Bedakan delivery ke mail server dan delivery ke inbox. Dua hal ini sering diperlakukan sama, padahal berbeda. Email yang diterima mail server tujuan belum tentu sampai ke inbox pengguna.

Klasifikasi bounce yang tepat. Hard bounce dan soft bounce punya implikasi yang berbeda, terutama untuk use case time-sensitive seperti OTP. Retry logic harus disesuaikan, bukan dibiarkan pada setting default yang dirancang untuk email biasa.

Alerting berbasis anomali delivery, bukan hanya error rate. Kalau delivery rate untuk OTP tiba-tiba turun tapi tidak ada error yang tercatat, itu sinyal yang perlu ditindaklanjuti. Sinyal itu hanya bisa ditangkap kalau ada baseline yang terdefinisi dan monitoring yang melihat ke layer yang tepat.

Pertanyaan yang Layak Dicek Sekarang

Apa definisi "email berhasil dikirim" yang dipakai tim Anda saat ini? Apakah definisi itu sama dengan "email diterima di inbox pengguna"? Kalau ada gap antara keduanya, dari mana tim Anda akan mengetahuinya?

Kalau jawabannya tidak jelas, kemungkinan besar tim Anda sedang memantau sisi yang salah.

Lihat Delivery Pipeline Anda dari Sisi User

Kalau tim Anda ingin memahami di mana gap antara sisi sistem dan sisi user paling mungkin terjadi di infrastruktur email Anda, kami siap membantu.

FAQ