Bounce Rate Email: Cara Mengukur dan Memperbaikinya
Summary
Bounce rate email adalah bagian dari pesan terkirim yang ditolak oleh server penerima. Jaga hard bounce di bawah 1% pada daftar yang sehat, selidiki di 2%, dan anggap 5% sebagai insiden, karena Amazon SES menempatkan akun pada level itu dalam peninjauan. Pisahkan rate per aliran, sumber, dan jenis bounce, lalu simpan kode status SMTP agar Anda bisa membedakan daftar yang kotor dari masalah reputasi.
Bounce rate email adalah jumlah pesan yang ditolak oleh server penerima, dibagi dengan jumlah pesan yang Anda kirim, lalu dikali 100. Untuk daftar yang sehat, jaga hard bounce di bawah 1%, anggap 2% sebagai titik untuk mulai menyelidiki, dan perlakukan 5% sebagai insiden. Kebanyakan tim membaca satu angka gabungan dari dashboard dan melewatkan fakta bahwa penyebut, jenis bounce, dan jendela waktu masing-masing mengubah hasilnya.
Sisa artikel ini membahas cara mendapatkan angka itu dengan benar lebih dulu, baru memutuskan apa yang harus dilakukan terhadapnya.
Rumusnya sederhana. Penyebutlah yang membuat tim berbeda pendapat.
Bounce rate sama dengan pesan yang bounce dibagi pesan terkirim, dikali 100. Beberapa ESP membagi dengan pesan yang terkirim (delivered), bukan pesan yang dikirim, sehingga angkanya terlihat lebih besar karena delivered sudah tidak mencakup bounce. Periksa dulu penyebut yang dilaporkan provider Anda sebelum membandingkannya dengan benchmark apa pun.
Amazon SES, misalnya, menghitung bounce rate hanya dari hard bounce, diukur terhadap apa yang dikirim melalui akun tersebut. Detail ini penting, karena dashboard yang mencampur soft bounce dan hard bounce akan menampilkan angka yang lebih tinggi daripada angka yang dipakai provider untuk menilai akun Anda.
Tentukan satu definisi dan catat di samping metrik itu, di judul dashboard jika perlu. Kami memakai hard bounce dibagi pesan terkirim, per domain pengirim, per 24 jam dan per 7 hari. Jika dua orang di tim Anda menyebut angka berbeda untuk minggu yang sama, penyebut adalah hal pertama yang harus dibandingkan.
Hard bounce, soft bounce, dan block adalah tiga sinyal yang berbeda
Hard bounce adalah kegagalan permanen. Alamatnya tidak ada, domainnya tidak bisa di-resolve, atau kotak suratnya sudah ditutup. SMTP melaporkannya dengan kode status enhanced 5.x.x, yang didefinisikan dalam RFC 3463.
Soft bounce adalah kegagalan sementara: kotak surat penuh, server sedang mati, atau pesan terlalu besar. Kode yang kembali berawalan 4.x.x, dan pengirim yang baik akan mencoba lagi. Jika Anda ingin klasifikasi lengkapnya, kami sudah membahas pemetaan kode SMTP itu di panduan kami sebelumnya tentang soft bounce vs hard bounce.
Kategori ketiga adalah yang paling sering disembunyikan dashboard. Block adalah penolakan 5.x.x yang tidak berbicara tentang alamatnya, melainkan tentang Anda: IP yang masuk daftar blokir, pemeriksaan autentikasi yang gagal, atau filter konten dan reputasi. Menghitung block sebagai hard bounce membuat daftar Anda terlihat kotor, padahal masalahnya ada pada pengaturan pengiriman.
Hindari laporan yang hanya menampilkan satu baris "bounce". Pisahkan menjadi tiga seri, atau Anda akan membersihkan daftar yang sebenarnya bukan sumber masalahnya.
Berapa bounce rate yang baik di 2026?
Tidak ada angka tunggal yang dipublikasikan, dan itu perlu diketahui sebelum Anda mengutipnya. Gmail dan Yahoo mempublikasikan ambang untuk spam complaint, bukan untuk bounce. Google meminta pengirim massal menjaga spam rate yang dilaporkan di Postmaster Tools di bawah 0.10% dan tidak pernah mencapai 0.30%, sesuai panduan pengirim FAQ mereka.
Untuk bounce, angka kerja berasal dari ESP dan dari praktik. Berikut ambang yang kami pakai sebagai level peringatan, bukan jaminan dari penyedia kotak surat mana pun.
Hard bounce rate per domain dalam 24 jam, dan cara kami menanganinya:
Di bawah 0.5%: normal untuk daftar yang terverifikasi dan aktif.
0.5% sampai 1%: pantau, dan periksa sumber alamat baru.
1% sampai 2%: selidiki, dan jeda segmen dengan angka tertinggi.
2% sampai 5%: hentikan kirim massal dari aliran itu dan cari impor atau formulir di baliknya.
Di atas 5%: insiden. Amazon SES menempatkan akun pada level ini dalam peninjauan.
Baris terakhir adalah batas yang terdokumentasi. Dalam dokumentasi dashboard reputasinya, Amazon SES menyatakan bahwa akun dengan bounce rate 5% atau lebih akan ditempatkan dalam peninjauan, dan pengiriman mungkin dijeda jika angkanya tetap di atas 10%. Penyedia lain memakai angka dan istilah yang berbeda, jadi baca kontrak Anda sendiri.
Segmentasikan dulu: angka gabungan menyembunyikan aliran yang gagal
Bounce rate akun sebesar 0.8% bisa menyimpan aliran transaksional di 0.1% dan impor re-engagement di 6%. Angka gabungan terlihat bisa diterima, sementara aliran kedua diam-diam merusak domain pengirim.
Hitung rate per aliran, per sumber, dan per domain penerima. Empat pemisahan ini menangkap sebagian besar masalah:
Per aliran. Transaksional, lifecycle, dan kampanye massal tidak boleh berbagi satu angka.
Per sumber pendaftaran. Formulir, pendaftaran lewat API, impor CSV, dan daftar mitra memiliki kualitas alamat yang sangat berbeda.
Per domain penerima. Lonjakan di satu penyedia biasanya berarti kebijakan penolakan, bukan daftar yang kotor.
Per usia alamat. Alamat yang dikumpulkan lebih dari 12 bulan lalu memantul lebih sering daripada alamat yang baru.
Ini bukan sekadar kerapian laporan. Ini perbedaan antara memperbaiki bug validasi formulir dalam satu jam dan membersihkan daftar yang sehat dalam keadaan panik.
Pemisahan kelima yang layak ditambahkan setelah yang lain berjalan: per IP atau domain pengirim. Jika Anda menjalankan dedicated IP untuk email transaksional dan pool bersama untuk kampanye, lonjakan di salah satunya memberi tahu Anda ke mana harus melihat sebelum membuka satu baris log pun.
Membaca event bounce dari provider tanpa kehilangan data
Setiap ESP yang serius mengekspos bounce sebagai event: webhook, topik notifikasi, atau API event. Perlakukan feed itu sebagai sumber kebenaran dan tulis ke penyimpanan Anda sendiri, karena dashboard mengagregasi data dan menghilangkan detail yang Anda butuhkan nanti.
Simpan field berikut untuk setiap event: message id, penerima, jenis bounce, kode status enhanced, teks diagnostik, dan timestamp. Dengan enam field ini, Anda bisa menjawab hampir semua pertanyaan yang muncul dalam postmortem.
{
"event": "bounce",
"message_id": "msg_01H9",
"recipient": "user@example.com",
"bounce_type": "permanent",
"status": "5.1.1",
"diagnostic": "550 5.1.1 user unknown",
"stream": "lifecycle",
"ts": "2026-11-02T09:14:03Z"
}Buat handler-nya idempotent, dengan kunci berupa event id dari provider ditambah message id. Provider mengulang webhook, dan event hard bounce yang terhitung dua kali akan mendistorsi rate Anda serta bisa menekan alamat yang sebenarnya baik.
Postmark dan Resend keduanya memisahkan jenis bounce dalam event mereka dan memungkinkan Anda mengambilnya per message stream, sehingga pemisahan per aliran di atas murah untuk dibangun.
Aturan suppression yang paling banyak bekerja
Kontrol dengan daya ungkit tertinggi adalah suppression otomatis. Setelah satu hard bounce, berhenti mengirim ke alamat itu secara permanen di application layer, jangan hanya mengandalkan daftar provider.
Kebanyakan ESP sudah men-suppress hard bounce untuk Anda. Celahnya muncul ketika Anda berpindah provider, menjalankan dua provider sekaligus, atau mengirim dari sistem yang tidak pernah membaca daftar suppression. Tabel Anda sendiri yang diindeks dengan alamat ternormalisasi menutup celah itu.
Untuk soft bounce, gunakan penghitung, bukan satu event saja. Default kami adalah men-suppress setelah tiga soft bounce berturut-turut dalam setidaknya tujuh hari. Kotak surat yang penuh selama seminggu, untuk keperluan lifecycle, sudah dianggap hilang.
Jangan menghapus alamat yang bounce dari tabel pengguna. Tandai dengan kode status dan tanggalnya. Baris yang dihapus tidak bisa memberi tahu Anda bahwa alamat yang sama bounce dua kali kuartal lalu. Anda membutuhkan catatan itu agar tidak mengimpor ulang alamat yang sama dari CSV berikutnya, dan itulah cara paling umum daftar yang sudah "dibersihkan" kembali menjadi kotor.
Kenapa angkanya tiba-tiba naik: penyebab umum, diurutkan
Ketika rate berubah, cari penyebabnya dengan urutan ini. Tiga yang pertama menjelaskan sebagian besar lonjakan.
Impor baru. CSV dari event, mitra, atau ekspor CRM lama. Periksa bounce rate per sumber sebelum hal lainnya.
Formulir pendaftaran tanpa validasi. Salah ketik seperti gmial.com dan domain sekali pakai. Pemeriksaan sintaks dan MX saat submit menghapus sebagian besar masalah ini, dan email konfirmasi menyaring sisanya sebelum sempat terhitung sebagai pengiriman dalam alur lifecycle.
Perubahan pengiriman. IP baru, domain baru, atau warmup yang naik terlalu cepat, yang berujung pada block alih-alih hard bounce.
Kegagalan autentikasi. Alignment SPF, DKIM, atau DMARC yang gagal setelah perubahan DNS.
Kebijakan penolakan dari sisi provider. Satu domain penerima memperketat filternya. Rate Anda naik hanya di domain itu.
Diagnosisnya adalah distribusi kode status, dikelompokkan per aliran dan per domain penerima dalam jendela waktu yang sama dengan lonjakan. Kenaikan 5.1.1 (user unknown) menunjuk ke daftar. Kenaikan 5.7.x menunjuk ke kebijakan, autentikasi, atau reputasi. Kedua kasus membutuhkan perbaikan yang berlawanan, itulah sebabnya Anda perlu menyimpan kodenya.
Apa yang akan kami beri peringatan
Peringatan berbasis rata-rata harian terlalu lambat. Impor yang buruk bisa mengirim 40,000 pesan dalam satu jam. Gunakan jendela bergulir sebagai gantinya:
Hard bounce rate di atas 1% dalam 1,000 pengiriman terakhir pada aliran mana pun.
Domain penerima mana pun di atas 5% dengan setidaknya 200 pengiriman dalam satu jam.
Jumlah block 5.7.x yang melampaui baseline normal Anda dengan selisih yang jelas.
Hubungkan dua yang pertama ke jeda pada aliran yang bermasalah, bukan ke halaman untuk manusia. Manusia bisa menyelidiki setelahnya. Jedalah yang melindungi reputasi Anda dalam sepuluh menit berikutnya.
Ekspor rate ke sistem monitoring yang sudah Anda jalankan, apakah itu Grafana, Datadog, atau sesuatu yang dibuat sendiri, dan pertahankan label aliran pada setiap seri agar pemisahan tetap ada setelah ekspor.
Untuk pelaporan ke atas, gunakan hard bounce rate per aliran dalam jendela 7 hari, ditambah jumlah block. Biarkan soft bounce di tampilan engineering, di mana itu berguna, dan jauhkan dari tampilan eksekutif, di mana itu menimbulkan kebingungan. Jangan pernah melaporkan angka gabungan akun saja, karena angka itu bergerak karena alasan yang tidak bisa dijelaskan siapa pun di ruangan.
Jika seorang stakeholder meminta satu angka, berikan hard bounce rate aliran transaksional. Itu aliran di mana kegagalan berarti reset password atau invoice yang tidak sampai, dan itulah pembacaan paling bersih atas kesehatan infrastruktur Anda.
Langkah berikutnya yang konkret itu kecil: tarik event bounce 30 hari terakhir, kelompokkan per aliran dan kode status, lalu lihat baris mana yang tidak Anda duga.