Bounce email: cara membacanya dan arti tiap kode

Apa itu bounce, dan dua momen saat ia terjadi

Kata itu dipinjam dari dunia kertas, dan gambaran itu keliru. Tidak ada apa pun yang kembali. Sebuah pesan diserahkan dari server ke server, dan server terakhir yang masih memegangnya dan tidak bisa membuangnya menulis sebuah pesan baru — dialamatkan kepada Anda, tentang pesan yang lama — dan mengirimkan itu sebagai gantinya. Semua yang bisa Anda pelajari ada di laporan itu, dan laporan itu cuma sebaik mesin yang menulisnya.

Ia bisa dihasilkan pada dua momen yang sangat berbeda, dan membedakan keduanya adalah sebagian besar dari diagnosisnya. Dua hasil lain terlihat seperti kegagalan dari sudut pandang Anda, padahal bukan:

Jadi kalau orang bilang “bounce”, sebenarnya itu menyebut dua hal. Satu adalah sebuah error yang ditampilkan perangkat lunak Anda sendiri, dan satu lagi adalah sebuah surat yang ditulis oleh mesin milik orang asing, dan cuma yang kedua yang punya laporan di dalamnya untuk dibaca. Sisa panduan ini membahas laporan itu.

Di mana alasannya sebenarnya ada

Sebuah laporan pengiriman adalah sebuah pesan dalam tiga bagian, dan bentuknya sudah baku sejak RFC 3464. Bagian pertama adalah permintaan maafnya, ditulis untuk manusia oleh mesin yang terdekat dengan Anda. Bagian kedua adalah blok yang bisa dibaca mesin, satu-satunya bagian yang memuat fakta. Bagian ketiga adalah pesan asli Anda, atau cuma headernya saja, supaya Anda bisa mengetahui pesan mana yang gagal.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Baca bagian tengahnya dengan urutan berikut:

Final-Recipient:

Alamat mana yang gagal. Satu laporan bisa membawa satu blok per penerima, jadi pada sebuah pesan yang dikirim ke beberapa orang, inilah cara Anda mengetahui laporan itu tentang siapa — dan yang lain mungkin saja sudah tiba.

Action:

failed adalah sebuah bounce. delayed adalah sebuah peringatan bahwa server masih mencoba dan belum menyerah pada apa pun; Anda mungkin masih akan mendapat laporan kedua yang bilang berhasil. relayed dan delivered bukan kegagalan sama sekali dan mudah dibaca keliru sebagai kegagalan.

Status:

Kode status diperluas — tiga angka, dimaksudkan untuk dibaca oleh perangkat lunak, bukan oleh Anda. Inilah bagian yang bisa dibandingkan antara satu provider dengan provider lain, yang tidak pernah bisa dilakukan oleh kalimat-kalimatnya.

Diagnostic-Code:

Baris yang benar-benar penting. Ini adalah jawaban asli dari server ujung sana, dikutip kata demi kata, membawa kode balasannya dan kalimat apa pun yang ditulis administratornya. Semua yang di atasnya cuma penceritaan ulang; inilah yang asli.

Remote-MTA:

Host mana yang mengatakannya. Layak dilirik setiap kali kegagalannya soal perutean: sebuah hostname yang tidak Anda kenali biasanya berarti surat domain itu sedang menuju ke tempat yang tidak Anda duga, atau ke tempat yang dulu pernah dituju tapi sekarang tidak lagi.

Kalimat di paling atas laporan itu bukan bukti. Server pengiriman Anda sendiri yang menulisnya, dengan kata-kata apa pun yang kebetulan sudah tertanam di perangkat lunaknya, tentang sebuah kegagalan yang cuma sedang ia teruskan. Dua permintaan maaf yang identik bisa berada di atas dua baris Diagnostic-Code: yang sama sekali tidak berhubungan, itulah sebabnya sebuah bounce yang dibaca dari atas begitu sering dibaca keliru.

Dua angka itu, dan digit yang menentukan

Sebuah penolakan ditulis seperti ini, dan itu adalah tiga hal terpisah yang digabung dengan spasi:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

550 adalah kode balasannya: tiga digit, didefinisikan oleh SMTP sendiri dalam RFC 5321, dan bagian yang dibutuhkan protokol itu untuk memutuskan apa yang harus dilakukan selanjutnya. 5.1.1 adalah kode status diperluas dari RFC 3463, ditambahkan karena tiga digit saja tidak cukup untuk mengungkapkan banyak hal. Semua yang ada setelahnya adalah teks bebas, ditulis oleh siapa pun yang menjalankan server itu, dan tidak dibakukan oleh apa pun sama sekali.

Kedua angka itu dimulai dengan digit yang sama, dan digit itulah putusannya:

Angka kedua adalah subjeknya — jenis hal apa yang salah. Ini adalah cara tercepat untuk menempatkan sebuah kode yang belum pernah Anda lihat sebelumnya:

Bounce permanen (hard bounce)

Sebuah 5. Alamatnya salah, sudah tidak ada, atau ditolak sebagai kebijakan, dan mengirim ulang pesan yang sama tidak mengubah apa pun. Pengirim massal langsung mencoret sebuah alamat dari daftarnya begitu ini muncul pertama kali, karena terus mengirim adalah hal yang membuat sebuah domain pengirim dibatasi di mana-mana sekaligus.

Bounce sementara (soft bounce)

Sebuah 4. Sebuah kotak surat penuh, sebuah server yang sibuk, sebuah penolakan kebijakan sementara. Ini dicoba ulang tanpa bantuan siapa pun dan biasanya akhirnya tiba; Anda cuma akan mendengarnya kalau percobaan ulangnya keburu habis.

Tidak satu pun dari kedua istilah itu ada dalam spesifikasi mana pun. Keduanya adalah singkatan yang dipakai industri pengiriman surat untuk menyebut digit pertama itu — dan singkatan itu layak diketahui, karena setiap tool deliverability yang pernah Anda pegang melaporkan dengan istilah itu.

Kode-kode yang benar-benar akan Anda temui

Ada puluhan kode dalam registry yang dikelola IANA, dan sekitar selusin di kehidupan sehari-hari. Kedua belas ini mencakup hampir semua bounce yang pernah dibaca orang:

Kode-kode di luar daftar ini memang ada, dan semuanya berarti sesuatu, tapi sebuah kode yang belum pernah Anda lihat sebelumnya hampir selalu adalah sebuah .7. — kebijakan seseorang, dijelaskan dengan kata-katanya sendiri pada baris di sampingnya.

Apa yang bisa dan tidak bisa bounce di sebuah alamat sementara

Hampir tidak ada apa pun — dan itu layak dijelaskan secara rinci, karena tiga dari hal-hal yang disebut orang sebagai bounce di sini sebenarnya bukan bounce:

“User unknown” tidak mungkin terjadi

Server ini menerima semua nama di domain-domain publiknya. anything@grabmail.io adalah alamat yang valid bahkan sebelum ada yang mengetiknya, karena tidak ada daftar kotak surat untuk memeriksanya — jadi sebuah 5.1.1 dari GrabMail adalah sesuatu yang tidak pernah ada. Cara kerja temp mail di baliknya membahas mekanismenya secara lengkap.

Kedaluwarsa bukan sebuah bounce

Sebuah pesan dihapus 5 hari setelah tiba, dan pada saat itu server pengirim sudah lama diberi tahu 250 dan sudah melupakan seluruh percakapan itu. Tidak ada yang diberi tahu, karena tidak ada yang gagal: pesan itu terkirim, lalu belakangan dihapus. Berapa lama sebuah kotak masuk bertahan adalah panduan untuk separuh cerita itu.

Sebuah formulir yang menolak alamatnya bukan sebuah bounce

Tidak ada surat yang terkirim sama sekali. Situsnya membandingkan domain itu dengan sebuah daftar dan menolak formulirnya; tidak ada apa pun yang pernah sampai ke server surat, dan tidak ada apa pun untuk dibaca. Mengapa formulir pendaftaran memblokir email sekali pakai adalah masalah lain dengan seperangkat jawaban yang berbeda.

Diam juga bukan sebuah bounce

Kalau sesuatu yang Anda tunggu tidak pernah tiba dan tidak ada yang mengirimi Anda laporan apa pun, kegagalannya — kalau memang ada — terjadi di sisi pengirim, di tempat yang tidak bisa Anda lihat. Surat yang tidak kunjung muncul membahas penyebab-penyebabnya dalam urutan yang layak diperiksa.

Itu menyisakan tepat satu penolakan sungguhan, yaitu batas atas ukuran. Sebuah server pengirim yang mengumumkan ukurannya di awal langsung ditolak seketika, sebelum satu byte pun tersimpan:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Sebuah pengirim yang tidak mengumumkan ukurannya akan mendapat jawaban yang sama di akhir pesan, setelah byte-nya selesai dihitung. Bagaimanapun caranya, kodenya tetap 5.3.4, tidak ada apa pun yang tersimpan, dan orang sungguhan diberi tahu oleh sistem suratnya sendiri — itulah keseluruhan alasan untuk menolak di pintu, bukan menerima lalu membuangnya.

Tidak ada paket dan tidak ada header yang menaikkan batas atas itu, dan tidak ada bounce untuk hal lain apa pun di sini: tidak ada kuota masuk, tidak ada rate limit, tidak ada penolakan karena seseorang sudah memakai nama itu. Pada sebuah domain bersama, dua orang yang mengetik nama yang sama akan berbagi kotak surat begitu saja, itu adalah sebuah sifat privasi, bukan sifat pengiriman.

Bounce pada domain yang baru saja Anda arahkan ke sini

Mengarahkan sebuah domain ke sebuah kotak masuk catch-all cuma perlu satu record DNS, dan hampir semua bounce yang dihasilkannya adalah milik jam-jam di sekitar perubahan itu, bukan milik pengaturannya sendiri. Ada lima kasus dan masing-masing terlihat berbeda satu sama lain:

1. Sebelum recordnya ada. Sebuah domain tanpa MX dan tanpa record alamat sebagai cadangan memberi pengirim 5.4.4 atau 5.1.2: tidak ada tempat untuk mengirim dan tidak ada yang layak dicoba ulang.
2. Selagi perubahan itu menyebar. Pengirim yang sudah lebih dulu memeriksa recordnya akan tetap memakai jawaban lama sampai TTL-nya habis. Sebuah bounce dalam jendela waktu ini menyebutkan nama host yang lama pada baris Remote-MTA:, dan itulah persis cara membedakannya dari sebuah record yang memang salah Anda buat.
3. Begitu sudah menyebar sepenuhnya. Semua nama di domain itu diterima, sehingga “user unknown” juga berhenti mungkin terjadi di sana. Satu record, prioritas 10, menunjuk ke smtp.grabmail.io, dan tidak ada apa pun lagi yang perlu dipublikasikan supaya surat bisa tiba.
4. Kalau domain itu dulu mempublikasikan null MX. Domain yang diparkir sering membawa record yang artinya “domain ini tidak pernah menerima surat”. Pengirim yang sudah menyimpannya di cache akan tetap menjawab 5.1.10 sampai cache itu kedaluwarsa, apa pun yang sudah Anda publikasikan sejak itu.
5. Kalau domain itu juga mengirim surat. Sebuah 5.7.26 pada surat keluar bukan soal apa pun di atas — itu soal SPF atau DMARC Anda sendiri yang gagal mencakup apa pun yang mengirim pesan itu. Panduan khusus terima adalah kasus yang ketat; sebuah domain yang juga mengirim surat justru butuh peluncuran bertahap yang biasa.

Membaca recordnya menjawab sebagian besar dari itu sebelum siapa pun harus membaca sebuah bounce:

$ dig +short MX yourdomain.com

Jawabannya seharusnya satu baris: prioritasnya, lalu hostnya, lalu sebuah titik di akhir. Apa pun selain itu — dua baris, sebuah host yang tidak dikenal, tidak ada apa pun sama sekali — adalah bounce yang akan segera Anda terima, cuma lebih cepat tiga menit. Mengarahkan domain Anda sendiri ke sini adalah keseluruhan pengaturannya, dan tiga record yang menghentikan spoofing adalah yang harus dipublikasikan begitu surat mulai tiba.

Sebuah bounce untuk pesan yang tidak pernah Anda kirim

Ini tiba dengan tampilan persis seperti sebuah laporan kegagalan biasa, mengutip sebuah pesan yang belum pernah Anda lihat, untuk seorang penerima yang belum pernah Anda dengar namanya. Tidak ada apa pun yang dibobol. Seseorang mengirim surat dengan alamat Anda yang dituliskan ke dalam envelope sebagai pengirimnya, sebuah server penerima menerimanya sebelum menyadari tidak bisa mengirimkannya, lalu melakukan hal yang benar terhadap sebuah pesan yang gagal: menulis sebuah laporan dan mengirimkannya kepada pengirim yang tercatat baginya. Yaitu Anda.

Namanya adalah backscatter, dan apa yang dibuktikannya layak dikatakan dengan jelas: tidak ada apa-apa soal kotak surat Anda. Memalsukan sebuah pengirim envelope tidak butuh akses ke apa pun — itu cuma satu baris yang diketik ke dalam sebuah percakapan. Siapa pun yang melakukannya cuma butuh alamat Anda dan tidak ada yang lain, dan mereka bisa jadi cuma menebaknya.

Tiga hal membedakannya dari sebuah bounce sungguhan dalam waktu sekitar sepuluh detik:

• Pesan yang dikembalikan bukan milik Anda. Bagian ketiga laporan itu membawa pesan aslinya, atau setidaknya headernya. Kalau Anda belum pernah menulisnya, Anda tidak mengirimnya, dan semua yang lain dalam laporan itu adalah soal masalah orang lain.
• Rantai Received: dimulai dari suatu tempat yang belum pernah Anda pakai. Baca dari bawah ke atas: baris paling bawah adalah mesin yang benar-benar memasukkan pesan itu, dan itu bukan provider Anda. Membaca header email membahas arah bacanya dan mengapa bagian bawah adalah ujung yang jujur.
• Tanggalnya tidak cocok. Backscatter biasanya melaporkan sebuah pesan yang dikirim berjam-jam atau berhari-hari sebelum laporannya sampai ke Anda, keluar dari sebuah antrean yang sudah mencoba ulang kampanye orang lain sejak saat itu.

Tidak ada apa pun yang perlu diperbaiki dan tidak ada apa pun yang perlu dijawab. Kalau alamat itu milik sebuah domain yang Anda punya, mempublikasikan SPF dan DMARC menguranginya dengan satu-satunya cara yang benar-benar berhasil: sebuah server penerima yang memeriksa kebijakan pengirim sebelum menerima akan menolak pemalsuan itu di dalam percakapan dan tidak pernah membuat laporan untuk siapa pun. Tiga record pada sebuah domain khusus terima adalah versi paling ketat dari itu, dan jauh yang paling mudah dipublikasikan.

Sebuah nama pendek pada sebuah domain publik bersama mengumpulkan lebih banyak dari ini dibanding sebuah alamat privat, dengan alasan yang sama seperti mengapa ia mengumpulkan lebih banyak spam: nama itu mudah ditebak, dan seorang pemalsu yang memilih pengirim envelope tidak sedang menargetkan Anda secara khusus. Ini cuma noise soal orang lain, dan tidak seperti spam, tidak ada tombol yang melatih apa pun di sini — apa yang sebenarnya dilakukan kontrol-kontrol spam adalah panduan untuk tombol-tombol yang memang berfungsi.

Urutan membaca sebuah bounce

1. Tentukan jenis mana yang sedang Anda pegang. Sebuah error di aplikasi email Anda sendiri pada saat Anda menekan kirim adalah sebuah penolakan. Sebuah pesan dari MAILER-DAEMON yang tiba belakangan adalah sebuah laporan, dan cuma laporan itu yang punya sesuatu di dalamnya untuk dibaca.
2. Periksa apakah ini soal pesan yang benar-benar Anda kirim. Salinan yang dikembalikan ada di bagian ketiga. Kalau itu bukan milik Anda, ini adalah backscatter, dan Anda sudah selesai.
3. Buka sumber mentahnya. Permintaan maaf di bagian atas adalah kalimat baku dari server Anda sendiri, bukan alasannya, dan blok yang bisa dibaca mesin tidak ditampilkan secara default di mana pun.
4. Cari Status: dan baca digit pertamanya. Sebuah 4 masih sedang dicoba ulang dan mungkin masih akan berhasil sendiri; sebuah 5 sudah final dan tidak akan terjadi apa-apa lagi.
5. Baca Diagnostic-Code:. Ini adalah kalimat asli dari ujung sana, dan satu-satunya tempat aturan yang menolak Anda benar-benar disebutkan namanya.
6. Tempatkan digit keduanya. .1. adalah alamat, .2. kotak surat, .4. rute, .7. kebijakan seseorang. Itu biasanya cukup untuk mengetahui ini masalah siapa.
7. Bertindak sesuai masalah siapa itu. Kegagalan pengalamatan diperbaiki dengan memakai alamat yang benar; kegagalan perutean dengan memperbaiki DNS; kegagalan kebijakan dengan memenuhi kebijakan itu, atau dengan meminta orang di sisi lain memeriksa log mereka sendiri — tempat penolakan yang sama tertulis jauh lebih panjang daripada yang mereka kirimkan kepada Anda.

Dua hal yang tidak pernah menjadi jawabannya. Mengirim ulang pesan yang sama persis setelah sebuah 5 cuma mengulangi penolakan yang sama dan, kalau dilakukan cukup sering, merusak reputasi domain pengirim di mana-mana sekaligus. Dan membalas laporan itu tidak sampai ke siapa pun: laporan itu datang dari sebuah pengirim envelope yang kosong, dan justru itulah alasan mengapa laporan itu bisa terkirim kepada Anda sejak awal.

Pertanyaan