Mengira Subdomain Bebas dari Aturan Bulk Sender Gmail, Padahal Volumenya Digabung

Pola ini sering muncul. Newsletter dikirim dari promo.example.com, notifikasi order dari notif.example.com, dan email kantor tetap di example.com. Masing-masing kira-kira 2.000 sampai 3.000 email per hari ke Gmail, jadi pemilik domain merasa aman karena tidak ada satu pun yang menyentuh angka sekitar 5.000. Masalahnya, Gmail dan Yahoo tidak menghitung per subdomain. Volume dari semua stream dan semua subdomain dijumlahkan ke domain utama. Pemisahan subdomain itu sendiri tidak salah. Hanya saja, tujuannya sering keliru. Supaya jelas kenapa penghitungannya digabung, kita perlu melihat dulu domain apa saja yang sebenarnya dibawa oleh satu email.

Satu email membawa beberapa identitas domain

Dari sisi server penerima, satu pesan tidak hanya punya satu domain. Setidaknya ada tiga identitas yang dicatat dan dievaluasi:

Envelope sender (MAIL FROM di sesi SMTP, yang nanti muncul sebagai Return-Path). Domain ini dipakai untuk cek SPF.
Header From:, yaitu alamat yang dilihat penerima di aplikasi email. Domain ini jadi patokan DMARC.
Nilai d= di signature DKIM, yaitu domain yang menyatakan dirinya menandatangani pesan.

Ketiganya bisa berbeda. Newsletter dari ESP (email service provider) misalnya bisa punya From: [email protected], Return-Path di domain bounce milik ESP, dan DKIM d=promo.example.com. Notifikasi dari server aplikasi bisa memakai notif.example.com di ketiganya. Di atas semua identitas itu ada konsep yang dipakai DMARC: organizational domain, atau domain organisasi. Ini adalah domain yang benar-benar didaftarkan di registrar, ditentukan berdasarkan Public Suffix List (daftar akhiran publik seperti .com, .co.id, .web.id). Untuk promo.example.com, notif.example.com, dan example.com, domain organisasinya sama, yaitu example.com. Karena itu DMARC dengan mode relaxed alignment menganggap From: promo.example.com selaras dengan DKIM d=example.com. Keduanya dianggap satu keluarga.

Bagaimana pesan dari subdomain akhirnya kembali ke domain utama

Google tidak mempublikasikan algoritma persis tentang cara mereka menjumlahkan volume. Yang dinyatakan jelas adalah hasilnya: volume dihitung di level domain utama, dan semua stream (marketing, transaksional, email kantor, subdomain) ikut dihitung. Cara paling mudah memahaminya adalah lewat alur evaluasi yang memang terjadi saat email masuk:

Server pengirim membuka koneksi SMTP ke MX Gmail, lalu mengirim EHLO, MAIL FROM, RCPT TO, dan DATA.
Server penerima mengecek SPF untuk domain envelope sender dengan membaca record TXT di DNS domain tersebut.
Setelah header dan body diterima, signature DKIM diverifikasi dengan mengambil public key dari selector._domainkey.<domain d=>.
Untuk DMARC, penerima mengambil domain di header From: dan mencari record di _dmarc.<domain From>. Kalau di subdomain tidak ada record, pencarian turun ke _dmarc.<domain organisasi>.
Hasilnya dicatat bersama sinyal lain seperti keluhan spam dan engagement, lalu diakumulasi sebagai reputasi.

Langkah keempat adalah kuncinya. Bahkan di level protokol, subdomain tanpa kebijakan sendiri mewarisi kebijakan domain organisasinya. Penerima memang dirancang untuk melihat subdomain sebagai bagian dari domain induk. Jadi masuk akal kalau penghitungan volume bulk sender juga digabung ke domain utama, bukan dipecah per label DNS. Konsekuensinya: dalam contoh tadi, 2.500 dari promo, 2.000 dari notif, dan 1.000 dari email kantor (angka ilustrasi) berarti sekitar 5.500 per hari untuk example.com. Domain itu sudah masuk wilayah bulk sender. Ada satu detail lagi yang sering terlewat. Menurut aturan yang berlaku, begitu domain melewati ambang, status bulk sender tidak kedaluwarsa. Kalau volume turun lagi bulan depan, domain tetap diharapkan memenuhi semua persyaratan bulk sender. Satu kampanye besar saat promo akhir tahun sudah cukup untuk mengubah status domain secara permanen.

Lalu apa gunanya memisah stream ke subdomain

Pemisahan tetap berguna, hanya bukan untuk menghindari ambang. Manfaat yang biasanya didapat: Sinyal lebih mudah dibaca. Kalau newsletter memicu banyak laporan spam, kita bisa melihatnya per subdomain di laporan DMARC aggregate dan alat seperti Postmaster Tools, tanpa tercampur dengan notifikasi order. Konfigurasi lebih rapi. Tiap subdomain bisa punya selector DKIM dan record SPF sendiri sesuai platform pengirimnya, sehingga perubahan di ESP marketing tidak menyentuh server transaksional. Risiko lebih terkendali. Reputasi tetap terhubung ke domain induk, tapi masalah di satu stream biasanya lebih cepat terlokalisasi dan diperbaiki. Orang kadang terpikir memakai domain terdaftar yang benar-benar terpisah, misalnya example-mail.com. Secara teknis itu memang domain organisasi yang berbeda. Tapi definisi bulk sender juga menyebut organisasi, bukan hanya domain. Ditambah lagi, domain baru tanpa riwayat biasanya punya reputasi nol dan penerima akan lebih curiga. Kalau tujuannya cuma menghindari aturan, hasilnya cenderung lebih buruk daripada sekadar memenuhi persyaratan. Soal kebijakan DMARC di domain induk yang ikut berlaku ke subdomain, ada efek samping lain yang dibahas di artikel tentang root DMARC yang memblokir mail subdomain.

Memperkirakan volume harian ke Gmail dari log

Bagian ini yang paling sering membingungkan pelanggan. Mereka tahu jumlah subscriber, tapi tidak tahu berapa email yang benar-benar dikirim ke Gmail per hari dari semua sumber. Cara menghitungnya: jumlahkan semua jalur pengiriman, yaitu server hosting sendiri, ESP marketing, layanan email transaksional, dan aplikasi lain seperti CRM atau helpdesk yang mengirim atas nama domain kamu. Untuk server sendiri, log MTA bisa memberi perkiraan. Di Exim, setiap pengiriman sukses ditandai =>. Perintah di bawah ini read-only dan menghitung pengiriman ke gmail.com dan googlemail.com per tanggal. Path log tergantung setup: /var/log/exim_mainlog umum di cPanel, sedangkan Debian/Ubuntu biasanya memakai /var/log/exim4/mainlog.

BASH

grep -E ' => [^ ]*@(gmail|googlemail)[.]com' /var/log/exim_mainlog | awk '{print $1}' | sort | uniq -c

Untuk Postfix, yang dicari adalah baris status=sent dengan penerima Gmail. Lokasi log umumnya /var/log/mail.log atau /var/log/maillog, tergantung distro. Kolom tanggal di format syslog klasik terdiri dari dua kolom (bulan dan tanggal), jadi awk-nya sedikit berbeda.

BASH

grep 'status=sent' /var/log/mail.log | grep -E 'to=<[^>]*@(gmail|googlemail)[.]com>' | awk '{print 1,2}' | sort | uniq -c

Anggap hasilnya sebagai perkiraan. Format log bisa berbeda per versi dan konfigurasi, log yang sudah dirotasi tidak ikut terbaca, dan email yang dikirim lewat ESP tidak tercatat di server sama sekali. Angka dari ESP perlu diambil dari dashboard masing-masing, lalu dijumlahkan manual per hari. Kalau satu server melayani banyak domain, filter juga berdasarkan domain pengirim supaya hitungannya tidak tercampur akun lain. Yahoo dihitung dengan logika yang sama, jadi lakukan juga untuk domain penerima milik Yahoo. Hitung per hari, bukan rata-rata bulanan. Satu hari kampanye yang melewati ambang sudah cukup.

Kalau ternyata sudah bulk sender

Persyaratannya berlaku untuk seluruh domain, bukan hanya stream yang volumenya paling besar. Minimal yang harus dipastikan: SPF lolos, DKIM aktif dan menandatangani semua email keluar, record DMARC terpasang di domain utama (apex) dengan kebijakan minimal p=none, dan domain di From: selaras dengan domain SPF atau DKIM. Record DMARC di apex bisa dicek seperti ini:

BASH

dig +short TXT _dmarc.example.com

Selain itu, Google dan Yahoo juga mengatur hal di luar autentikasi untuk bulk sender, seperti unsubscribe sekali klik di email marketing dan batas tingkat laporan spam. Detail dan angkanya sebaiknya dicek langsung di dokumentasi resmi masing-masing, karena bisa diperbarui. Kalau persyaratan ini tidak terpenuhi, konsekuensinya biasanya bertahap tapi nyata. Email bisa ditolak dengan kode SMTP 5xx, dialihkan ke folder spam, atau dikirim dengan throttling sehingga notifikasi yang sensitif waktu, seperti reset password atau OTP, datang terlambat. Yang sering terjadi, stream transaksional yang konfigurasinya paling rapi ikut terdampak karena stream lain di domain yang sama belum memenuhi syarat. Kalau newsletter masih dikirim dari server cPanel bersama, pertimbangan memakai Exim lokal atau relay eksternal dibahas di artikel tentang Exim cPanel dan relay eksternal untuk aturan bulk Gmail. Jadi sebelum menyimpulkan domain aman karena tiap subdomain kecil volumenya, jumlahkan dulu semua sumber pengiriman per hari ke Gmail dan Yahoo. Kalau totalnya mendekati 5.000 atau pernah melewatinya, perlakukan seluruh domain sebagai bulk sender: rapikan SPF, DKIM, dan alignment di setiap subdomain, pasang DMARC di apex, lalu pakai pemisahan subdomain untuk memantau masing-masing stream, bukan untuk menghindari aturan.