Cara Memastikan DKIM Selector Lama Aman Dihapus Setelah Ganti Provider Email

Setelah pindah provider email, biasanya ada satu atau dua record DKIM lama yang tertinggal di zona DNS, misalnya selector1._domainkey atau default._domainkey. Hampir tidak ada yang berani menghapusnya, karena takut masih ada email yang ditandatangani dengan kunci lama dan nanti gagal verifikasi. Rasa ragu itu masuk akal. Tapi membiarkan record itu selamanya juga bukan jawaban. Yang kita butuhkan adalah bukti bahwa selector lama memang sudah tidak dipakai, dan bukti itu bisa dicari sendiri lewat command line. Di meja support, pertanyaan ini sering muncul dalam bentuk "boleh nggak record yang ini dihapus?" dari pelanggan yang baru selesai migrasi. Jawaban jujurnya: tergantung siapa saja yang masih mengirim email atas nama domain itu. Di bawah ini cara mengeceknya, dari yang paling cepat sampai yang paling bisa dipercaya.

Kenapa selector lama masih bisa terpakai

DKIM (DomainKeys Identified Mail) bekerja dengan tanda tangan digital di header DKIM-Signature. Di header itu ada dua tag yang penting untuk kasus ini. d= adalah domain penanda tangan dan s= adalah selector. Saat email diterima, server penerima menggabungkan keduanya menjadi nama DNS s._domainkey.d, mengambil public key dari situ, lalu mencocokkannya dengan tanda tangan. Artinya, selector lama hanya dibutuhkan oleh email yang masih ditandatangani dengan private key lama. Masalahnya, sumber email di satu domain jarang cuma satu. Selain mailbox utama, sering ada form kontak di website yang mengirim lewat server hosting lama, sistem tiket, aplikasi invoice, atau layanan newsletter yang dikonfigurasi bertahun-tahun lalu. Kalau salah satunya masih menandatangani dengan selector lama, menghapus record berarti DKIM email tersebut akan gagal. Ada juga alasan keamanan untuk tidak membiarkan record itu terlalu lama. Private key pasangannya disimpan di provider lama. Selama public key-nya masih ada di DNS kamu, email yang ditandatangani dengan key itu tetap lolos sebagai email sah dari domain kamu. Jadi selector yang benar-benar sudah tidak dipakai sebaiknya memang dibersihkan.

Inventaris dulu record yang ada

DNS tidak punya cara untuk menampilkan semua selector di sebuah domain. Kita harus tahu nama selectornya lebih dulu, entah dari panel DNS, dokumentasi provider lama, atau dari header email (dibahas di bagian berikutnya). Setelah nama-namanya terkumpul, cek isinya langsung ke nameserver authoritative supaya hasilnya tidak tertutup cache resolver:

BASH

# Cari nameserver authoritative domain
dig +short NS contoh.com

# Cek selector lama dan baru langsung ke salah satu nameserver tersebut
dig @ns1.contoh-dns.net +short TXT selectorlama._domainkey.contoh.com
dig @ns1.contoh-dns.net +short TXT selectorbaru._domainkey.contoh.com

# Sebagian provider memakai CNAME untuk DKIM, cek juga
dig @ns1.contoh-dns.net +short CNAME selectorlama._domainkey.contoh.com

Ganti ns1.contoh-dns.net dengan hasil query NS kamu. Kalau selector lama berupa CNAME yang mengarah ke host milik provider lama, catat juga targetnya. Kadang provider lama menghapus key di sisi mereka setelah akun ditutup, sehingga CNAME itu sebenarnya sudah tidak menghasilkan public key apa pun. Simpan nilai lengkap record lama di catatan migrasi sebelum melakukan apa-apa. Nanti nilai ini jadi jalan pulang kalau ternyata masih dibutuhkan.

Cek header dari setiap sumber pengiriman

Langkah kedua adalah melihat langsung email yang keluar. Kirim email uji dari setiap sumber yang kamu tahu: mailbox utama, form kontak website, aplikasi invoice, sistem tiket, dan layanan lain yang mengirim atas nama domain. Tujuannya mailbox yang kamu kontrol. Lalu buka pesan aslinya (fitur seperti "show original" atau "view source" di webmail) dan simpan sebagai file .eml.

BASH

# Tampilkan header DKIM-Signature beserta baris lanjutannya
grep -i -A5 '^DKIM-Signature:' pesan.eml

# Tampilkan hasil verifikasi dari server penerima
grep -i -A5 '^Authentication-Results:' pesan.eml

Di output pertama, cari tag s= dan d=. Kalau s= masih berisi selector lama, sumber itu belum pindah. Di output kedua, banyak penerima menulis hasil seperti dkim=pass disertai header.d= dan kadang header.s=. Formatnya berbeda-beda antar layanan, jadi anggap DKIM-Signature sebagai sumber utama dan Authentication-Results sebagai konfirmasi. Perhatikan juga bahwa satu email bisa membawa lebih dari satu DKIM-Signature. Layanan pihak ketiga sering menandatangani dengan domain mereka sendiri dan juga dengan domain kamu. Yang relevan untuk keputusan ini hanya tanda tangan dengan d= domain kamu (atau subdomainnya) dan s= selector lama. Kelemahan cara ini jelas: kita hanya bisa menguji sumber yang kita ingat. Sumber yang terlupa justru yang paling berbahaya, dan untuk itulah laporan DMARC dibutuhkan.

Membaca laporan DMARC aggregate

Kalau record DMARC domain kamu punya tag rua=, penerima besar akan mengirim laporan aggregate. Laporan ini berupa file XML, biasanya dikompres sebagai .zip atau .gz, dan umumnya dikirim harian. Isinya ringkasan email yang mereka terima atas nama domain kamu, termasuk IP pengirim dan hasil DKIM. Di bagian auth_results, setiap hasil DKIM bisa memuat elemen <domain>, <selector>, dan <result>. Kumpulkan file laporan dari mailbox penerima rua ke satu folder, lalu hitung selector yang muncul:

BASH

# Ekstrak laporan (nama dan format file tergantung pengirim laporan)
unzip -o '*.zip'
gzip -dk *.xml.gz

# Hitung berapa kali setiap selector muncul di semua laporan
grep -ho '<selector>[^<]*</selector>' *.xml | sort | uniq -c

# Lihat konteks baris di sekitar selector lama, termasuk hasil verifikasinya
grep -h -B3 -A2 '<selector>selectorlama</selector>' *.xml

Kalau selector lama sama sekali tidak muncul di laporan dari periode yang cukup panjang, itu bukti yang kuat. Kalau masih muncul, buka file XML yang mengandungnya dan cari <row> yang sama. Di situ ada <source_ip> yang menunjukkan server mana yang masih mengirim. Untuk laporan yang banyak, parser XML atau tool analisis DMARC akan lebih nyaman dibanding grep, tapi untuk pertanyaan ya atau tidak, grep biasanya sudah cukup. Ada dua batasan yang perlu diingat. Pertama, elemen <selector> bersifat opsional, jadi sebagian pengirim laporan mungkin tidak menyertakannya. Kalau hasil grep kosong, pastikan dulu laporannya memang punya elemen itu, jangan langsung menyimpulkan selector sudah tidak dipakai. Kedua, laporan hanya datang dari penerima yang mendukung DMARC reporting. Email ke server kecil yang tidak mengirim laporan tidak akan terlihat. Karena itu, laporan DMARC dan uji header saling melengkapi, bukan saling menggantikan.

Berapa lama harus mengamati

Tidak ada angka baku. Patokan yang masuk akal adalah siklus pengiriman terpanjang di bisnis itu. Email harian akan terlihat dalam beberapa hari. Tapi invoice bulanan, pengingat perpanjangan tahunan, atau newsletter yang jarang dikirim bisa luput kalau kita hanya mengamati seminggu. Tanyakan ke pemilik domain apa saja yang dikirim otomatis dan seberapa sering, lalu pastikan jendela pengamatan mencakup minimal satu siklus dari pengiriman yang paling jarang. Selama masa itu, pastikan juga selector baru sudah benar-benar menggantikan. Di laporan DMARC, email dari IP provider baru seharusnya menunjukkan <result>pass</result> dengan selector baru dan domain yang selaras (aligned) dengan domain di header From. Kalau selector baru belum stabil, jangan buru-buru menghapus yang lama.

Menghapus dan memantau sesudahnya

Kalau header dari semua sumber yang diketahui sudah memakai selector baru dan laporan DMARC tidak lagi menunjukkan selector lama selama jendela pengamatan, record lama bisa dihapus. Urutannya:

Pastikan nilai lengkap record lama sudah tersimpan di catatan migrasi.
Hapus record di panel DNS, lalu cek ulang dengan dig ke nameserver authoritative sampai hasilnya kosong.
Ingat bahwa resolver yang sudah menyimpan record di cache masih bisa memakainya sampai TTL habis. Jadi efek penghapusan tidak langsung terasa.
Pantau laporan DMARC beberapa siklus setelahnya. Cari selector lama dengan hasil fail, permerror, atau temperror. Kalau muncul, artinya ada sumber yang terlewat. Pulihkan record dari catatan, cari sumbernya lewat <source_ip>, perbaiki konfigurasinya, lalu ulangi pengamatan.

Email yang sudah diterima sebelum penghapusan biasanya tidak diverifikasi ulang. Pengecualiannya email yang diteruskan ke alamat lain, karena server tujuan berikutnya bisa melakukan verifikasi sendiri. Ini jarang jadi masalah besar, tapi perlu diketahui kalau domain banyak dipakai untuk forwarding. Jadi, jangan hapus selector lama berdasarkan perasaan, dan jangan juga membiarkannya selamanya. Kumpulkan nama selector, cek header dari setiap sumber yang kamu tahu, lalu biarkan laporan DMARC menunjukkan sumber yang kamu lupa. Setelah satu siklus pengiriman penuh bersih dari selector lama, hapus record-nya dengan cadangan nilai di tangan dan tetap pantau laporan sesudahnya.