# Keterkiriman email (deliverability): diagnosis jalur ke kotak masuk URL kanonis: https://brew.new/id/blog/email-deliverability Penulis: Brew Team Dipublikasikan: 2026-08-23 Diperbarui: 2026-09-29 Penerimaan email dan penempatan di kotak masuk adalah dua hal yang berbeda. Server penerima bisa menerima sebuah pesan lalu menaruhnya di folder spam. Dasbor kampanye yang menampilkan status “diterima” tidak membuktikan bahwa pembaca sudah melihatnya. Saat masalah muncul, kumpulkan bukti sebelum mengubah teks atau berganti penyedia. Bagian yang bermasalah bisa jadi autentikasi, reputasi, audiens, atau pesan itu sendiri. ## Mulai dari respons server penerima Untuk pesan yang ditolak atau ditunda, periksa respons SMTP yang sebenarnya beserta kode status yang diperluas (enhanced status code). Kegagalan sementara dan penolakan permanen memerlukan penanganan yang berbeda. [FAQ pengirim](https://support.google.com/mail/answer/14229414) dari Google menjelaskan keduanya; FAQ itu tidak menyatakan bahwa setiap ketidakpatuhan kini menghasilkan error permanen. Jika pesan diterima tetapi masuk spam, periksa hasil autentikasi di header pesan yang diterima, data reputasi dari penyedia jika tersedia, serta perubahan terbaru pada audiens atau volume. Beberapa kotak masuk pengujian membantu mendiagnosis masalah, tetapi tidak mengukur penempatan di seluruh daftar kontak. ### Baca kode status yang diperluas Kode status yang diperluas terdiri atas tiga angka yang dipisahkan titik, sebagaimana didefinisikan dalam [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html). Angka pertama menunjukkan kelasnya. Kode yang diawali 4 berarti kegagalan sementara, dan server pengirim sebaiknya mencoba lagi nanti. Kode yang diawali 5 berarti kegagalan permanen, sehingga mengirim ulang pesan yang sama tanpa perubahan tidak akan membantu. Angka kedua mempersempit pokok masalahnya. Kode dalam rentang X.1.X berkaitan dengan pengalamatan, dan 5.1.1 biasanya berarti kotak surat tujuan tidak ada. Kecualikan alamat tersebut. Kode dalam rentang X.7.X berkaitan dengan keamanan atau kebijakan, dan di situlah masalah autentikasi dan reputasi biasanya muncul. Google mencantumkan respons yang dikembalikan Gmail dalam [referensi error SMTP](https://support.google.com/a/answer/3726730) miliknya. Baca teks respons secara lengkap, bukan hanya kodenya, karena satu kode bisa mencakup beberapa alasan yang berbeda. ### Tempat menemukan data reputasi dari penyedia [Google Postmaster Tools](https://postmaster.google.com/) menunjukkan bagaimana Gmail menilai domain pengirim Anda, termasuk tingkat spam yang dilaporkan pengguna, yang menjadi acuan persyaratan Google. Anda memverifikasi domain dengan sebuah record DNS. Gmail baru menampilkan data setelah domain mengirim cukup banyak email harian ke penggunanya, jadi pengirim kecil mungkin hanya melihat dasbor kosong. Smart Network Data Services dari Microsoft, yang dikenal sebagai [SNDS](https://substrate.office.com/ip-domain-management-snds/snds), melaporkan email dari alamat IP tertentu ke kotak surat konsumen Outlook.com, termasuk tingkat keluhan dan jumlah email yang mengenai perangkap spam. Anda mendaftarkan alamat IP yang Anda kendalikan, jadi SNDS paling berguna jika Anda memakai IP pengirim khusus. Jika memakai IP bersama, tanyakan kepada penyedia pengiriman email Anda apa saja yang dipantaunya. Kedua alat itu tidak memberi tahu ke mana satu kampanye tertentu mendarat. Keduanya menampilkan tren harian, dan itulah yang Anda butuhkan saat masalah menumpuk selama beberapa kali pengiriman. ## Verifikasi identitas pada pesan yang benar-benar terkirim SPF mengotorisasi infrastruktur pengiriman untuk sebuah domain envelope. DKIM menandatangani pesan dengan identitas domain. DMARC memeriksa alignment dengan domain From yang terlihat, serta memublikasikan kebijakan dan mekanisme pelaporan. Tidak satu pun dari ketiganya menjamin email masuk ke kotak masuk. Gunakan record yang diberikan penyedia pengiriman email Anda, lalu verifikasi hasilnya pada pesan sungguhan yang sudah diterima. Jangan menambahkan record SPF yang saling bertentangan, dan jangan berasumsi bahwa adanya record DNS membuktikan setiap jalur pengiriman sudah memakainya dengan benar. Infrastruktur Anda juga memerlukan reverse DNS yang sesuai dan transport yang aman. Di Brew, ikuti alur verifikasi domain dan publikasikan record yang diminta. Tinjau alamat From yang dipakai oleh kampanye atau otomatisasi yang sebenarnya, terutama jika satu agen mengelola beberapa merek. ### Naikkan DMARC dari pemantauan ke penegakan Kebijakan DMARC adalah record TXT di host `_dmarc` milik domain pada alamat From. Mulailah dengan `p=none`. Kebijakan ini meminta server penerima untuk tidak mengambil tindakan khusus terhadap email yang gagal, dan mereka tetap mengirim laporan agregat ke alamat `rua`. ```text _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Laporan itu mencantumkan setiap sumber yang mengirim email atas nama domain Anda dan apakah masing-masing lolos SPF atau DKIM dengan alignment. Bersiaplah menemukan alat yang sudah Anda lupakan, seperti sistem penagihan atau help desk. Perbaiki atau hapus setiap sumber yang gagal. Setelah semua email yang sah lolos, naikkan ke `p=quarantine`. Kebijakan ini meminta server penerima memperlakukan email yang gagal sebagai mencurigakan, yang biasanya berarti menaruhnya di folder spam. ```text _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Kebijakan paling ketat, `p=reject`, meminta server penerima menolak email yang gagal. Naikkan ke kebijakan ini hanya setelah quarantine berjalan beberapa waktu tanpa ada email sah yang gagal. Terus baca laporannya di setiap tahap. Alat baru yang mulai mengirim atas nama domain Anda akan muncul di sana lebih dulu. Subdomain pengirim khusus, seperti `mail.example.com`, adalah pengecualian. Jika tidak ada pengirim lain yang memakainya dan penyedia Anda sudah memverifikasi SPF dan DKIM subdomain tersebut, subdomain itu bisa langsung memakai `p=reject`. Brew menyarankan `p=reject` untuk subdomain khusus yang disiapkannya, dan `p=none` untuk domain utama yang mungkin juga dipakai layanan lain untuk mengirim. ## Baca langsung persyaratan dari penyedia [Pedoman Google](https://support.google.com/mail/answer/81126) membedakan persyaratan untuk semua pengirim dari aturan yang lebih ketat bagi pengirim yang mencapai sekitar 5.000 pesan per hari ke akun Gmail pribadi. Google meminta tingkat spam di bawah 0,1% dan memperingatkan agar tidak mencapai 0,3%. Persyaratan untuk pengirim massal mencakup SPF dan DKIM, DMARC, alignment, serta berhenti berlangganan sekali klik untuk email langganan yang relevan. ### Persyaratan Google untuk semua pengirim Daftar Google untuk setiap pengirim, berapa pun volumenya, mencakup hal-hal berikut: - Siapkan SPF atau DKIM untuk domain pengirim Anda. - Beri domain atau IP pengirim record DNS forward dan reverse yang valid. - Kirim melalui koneksi TLS. - Jaga tingkat spam yang dilaporkan di Postmaster Tools di bawah batas di atas. - Format pesan sesuai RFC 5322. ### Persyaratan tambahan untuk pengirim massal Pengirim massal juga harus melakukan hal-hal berikut: - Siapkan SPF sekaligus DKIM. - Publikasikan record DMARC untuk domain pengirim. Google menerima kebijakan `p=none`. - Selaraskan domain From dengan domain SPF atau domain DKIM. - Dukung berhenti berlangganan sekali klik untuk email pemasaran dan email langganan, serta sertakan tautan berhenti berlangganan yang terlihat jelas di isi pesan. Google menghitung email dari domain utama yang sama secara gabungan saat menerapkan ambang batas, dan domain yang pernah sekali melewatinya akan tetap berlabel pengirim massal. [FAQ pengirim](https://support.google.com/mail/answer/14229414) dari Google menjelaskan cara penghitungannya. [Panduan Yahoo](https://senders.yahooinc.com/best-practices/) juga mencakup autentikasi, keluhan, dan berhenti berlangganan. Yahoo tidak memublikasikan ambang batas angka yang sama untuk pengirim massal; baca [FAQ Yahoo](https://senders.yahooinc.com/faqs/) alih-alih menerapkan angka milik Gmail ke semua penyedia. ### Microsoft Outlook.com Microsoft [mengumumkan pada 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) bahwa domain yang mengirim lebih dari 5.000 email per hari ke kotak surat konsumennya, yaitu alamat outlook.com, hotmail.com, dan live.com, wajib lolos SPF dan DKIM serta memublikasikan DMARC. Kebijakan DMARC boleh `p=none`, dan domain pada alamat From harus selaras dengan SPF atau DKIM. Panduan penyedia ditinjau pada 28 September 2026. Periksa halaman yang ditautkan saat mendiagnosis insiden baru. ## Uji cara kerja berhenti berlangganan Berhenti berlangganan sekali klik menurut [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) adalah mekanisme berbasis header dan HTTPS POST. Tautan yang terlihat di footer juga berguna dan diwajibkan oleh aturan yang relevan, tetapi halaman preferensi saja tidak menerapkan protokol tersebut. Pesan yang mendukung berhenti berlangganan sekali klik membawa dua header: ```text List-Unsubscribe: , List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` Saat pembaca mengklik berhenti berlangganan di kotak masuk, penyedia email mengirim POST ke URL HTTPS tersebut dengan isi `List-Unsubscribe=One-Click`. Alamat `mailto:` adalah alternatif untuk perangkat lunak email yang tidak mendukung sekali klik. RFC 8058 juga mewajibkan tanda tangan DKIM valid yang mencakup kedua header tersebut. Buat URL yang khusus untuk setiap penerima dan sulit ditebak. Pemindai keamanan sering membuka tautan di email masuk, jadi permintaan GET biasa ke URL itu tidak boleh membuat siapa pun berhenti berlangganan. Brew menambahkan header `List-Unsubscribe` dan `List-Unsubscribe-Post` ke pengiriman pemasaran, yang mengarah ke URL HTTPS bertanda tangan untuk setiap penerima dan menerima POST sekali klik. Pastikan permintaan berhenti berlangganan dari email pemasaran mencegah pengiriman pemasaran berikutnya melalui setiap jalur yang Anda pakai. Pertahankan daftar pengecualian saat mengimpor kontak atau berpindah platform. Pisahkan [pesan transaksional](/id/blog/transactional-emails) yang penting, baik dari sisi tujuan maupun konfigurasi pengirimannya. ## Periksa audiens sebelum menaikkan volume Tinjau dari mana alamat-alamat itu berasal dan apa yang diharapkan orang saat mendaftar. Hapus alamat yang tidak valid melalui proses pengecualian di penyedia Anda, selidiki lonjakan keluhan, dan hindari mengirim ulang ke orang-orang hanya karena data pelacakan menunjukkan mereka tidak membuka email. Tidak ada usia daftar kontak, rasio gambar dan teks, atau kata terlarang universal yang menjamin email sampai. Lonjakan volume mendadak ke daftar kontak yang kurang Anda pahami adalah masalah yang lebih serius daripada memakai kata “gratis”. Jika [kampanye dikirim oleh agen](/id/blog/agent-email-deliverability), pemeriksaan yang sama tetap berlaku. Gunakan fakta yang terverifikasi, audiens yang relevan, dan alamat balasan yang dipantau. Perbaiki penyebab yang sudah teridentifikasi, lakukan pengiriman uji yang terkendali, lalu tinjau respons penyedia sebelum memperluas pengiriman lagi.