Cara Cek Tag sp DMARC agar Email dari Subdomain cPanel Tidak Ikut Ditolak

Setelah DMARC domain utama dinaikkan ke p=reject, yang sering ikut kena justru email dari subdomain: notifikasi aplikasi dari app.example.com, newsletter dari news.example.com, atau email form kontak dari situs yang jalan di subdomain cPanel. Banyak yang mengira policy di _dmarc.example.com hanya berlaku untuk domain itu sendiri. Kenyataannya, kalau tag sp tidak ditulis dan subdomain tidak punya record DMARC sendiri, subdomain ikut memakai nilai p dari domain induk. Tulisan ini disusun seperti post-mortem dari pola yang umum terjadi, supaya urutan pengecekannya jelas. Ini bukan laporan dari satu kasus tertentu.

Dampak awal: domain utama aman, subdomain mulai bounce

Gejalanya biasanya membingungkan karena tidak merata. Email dari mailbox biasa seperti [email protected] tetap masuk ke Gmail atau Outlook. Yang gagal hanya email dari subdomain, dan sering kali yang dikirim oleh script, bukan oleh orang. Laporan yang masuk ke support kira-kira berbunyi email dari website tidak sampai atau form kontak tidak pernah masuk ke inbox. Karena perubahan DMARC dilakukan di domain utama, dan tidak ada yang menyentuh subdomain, tim support cenderung mencari di tempat lain dulu. Yang dicek biasanya IP server masuk blacklist atau tidak, SPF subdomain rusak atau tidak, atau kuota kirim habis. Itu semua wajar untuk dicek. Masalahnya, kalau penyebabnya DMARC, pengecekan itu tidak akan menemukan apa-apa. Petunjuk pertama biasanya ada di pesan bounce. Kalau penerima menolak karena DMARC, isi bounce umumnya menyebut DMARC atau policy domain pengirim, bukan reputasi IP. Di cPanel, status dan pesan penolakan ini bisa dilihat di Track Delivery.

Jejak investigasi: dari bounce ke record DMARC

Langkah pertama adalah memastikan penolakan memang karena DMARC. Cara paling jelas: kirim email uji dari subdomain yang bermasalah ke mailbox yang kamu kontrol. Selama policy masih reject, email uji ke penerima yang menegakkan DMARC kemungkinan ditolak juga. Jadi pakai mailbox yang tidak terlalu ketat, atau lakukan uji ini setelah mitigasi di bagian berikutnya. Lalu buka header Authentication-Results. Header ini ditulis server penerima dan berisi hasil SPF, DKIM, dan DMARC. Formatnya berbeda antar penerima, tapi polanya mirip seperti ini (contoh format output):

TEXT

Authentication-Results: mx.example.net;
       dkim=pass [email protected];
       spf=pass [email protected];
       dmarc=fail (p=REJECT) header.from=news.example.com

Bagian ini yang sering bikin bingung. SPF pass, DKIM pass, tapi DMARC tetap fail. Alasannya, DMARC tidak cukup dengan SPF atau DKIM lolos. Salah satunya harus aligned, artinya domain yang lolos harus cocok dengan domain di header From: yang dilihat penerima. Pada contoh di atas, SPF dan DKIM lolos untuk server.example.net (hostname server), sedangkan From: memakai news.example.com. Domainnya beda organisasi, jadi tidak ada yang aligned. Cara membaca header ini lebih detail ada di Reading Authentication-Results Headers to Fix DMARC Alignment. Langkah kedua adalah melihat record DMARC yang benar-benar dipublikasikan. Di cPanel, buka Zone Editor, pilih Manage pada domain utama, lalu filter record TXT. Cari nama _dmarc.example.com. dan cek juga apakah ada _dmarc.news.example.com.. Pastikan dulu DNS domain itu memang dikelola di cPanel. Kalau nameserver mengarah ke layanan lain, isi Zone Editor tidak berpengaruh apa-apa. Dari terminal, pengecekan yang sama bisa dilakukan dengan dig:

BASH

# Pastikan DNS memang dikelola di server ini, bukan di layanan lain
dig +short NS example.com

# Record DMARC domain induk
dig +short TXT _dmarc.example.com

# Record DMARC khusus subdomain (sering kosong)
dig +short TXT _dmarc.news.example.com

# SPF subdomain: SPF tidak diwarisi dari domain induk
dig +short TXT news.example.com

Pola yang sering muncul: record domain induk berisi sesuatu seperti "v=DMARC1; p=reject; rua=mailto:[email protected]" tanpa sp, dan query untuk _dmarc.news.example.com tidak mengembalikan apa-apa.

Titik temuan: subdomain mewarisi p=reject karena sp tidak ada

Begini urutan yang dilakukan penerima. Saat menerima email dengan From: [email protected], penerima mencari record di _dmarc.news.example.com. Kalau tidak ketemu, penerima naik ke domain organisasinya, yaitu _dmarc.example.com. Kalau record di sana punya sp, nilai sp itulah yang dipakai untuk subdomain. Kalau tidak ada sp, nilai p yang dipakai. Jadi p=reject tanpa sp artinya semua subdomain tanpa record sendiri juga diperlakukan reject. Ada dua detail yang perlu diingat. Pertama, sp hanya dibaca dari record domain organisasi. Kalau subdomain punya record DMARC sendiri, yang berlaku adalah p di record subdomain itu. Kedua, masalahnya bukan karena pengirimnya subdomain. Dengan alignment mode relaxed (default kalau adkim dan aspf tidak diset), tanda tangan DKIM dengan d=example.com tetap dianggap aligned untuk From: news.example.com. Yang bikin gagal adalah domain yang menandatangani atau domain envelope-nya sama sekali di luar example.com. Di cPanel, ini sering terjadi pada email yang dikirim lewat fungsi mail() PHP, karena envelope sender-nya bisa berupa akun cPanel di hostname server, bukan mailbox di domain tersebut. Lalu kenapa masalah ini tidak kelihatan sebelumnya? Selama policy masih p=none, email yang gagal DMARC tetap dikirim seperti biasa. Kegagalannya hanya tercatat di laporan agregat rua, yaitu file XML yang dikirim mailbox provider besar. Kalau laporan itu tidak pernah diproses dengan parser atau tool analitik DMARC, kegagalan dari subdomain tidak ada yang lihat sampai policy dinaikkan.

Mitigasi sementara tanpa melemahkan domain utama

Godaan pertama biasanya menurunkan domain utama kembali ke p=none. Cara ini memang menghentikan penolakan, tapi juga membuka lagi celah spoofing untuk domain utama yang sebenarnya sudah beres. Ada dua opsi yang lebih terarah. Opsi pertama, publikasikan record DMARC khusus untuk subdomain yang bermasalah dengan p=none. Hanya subdomain itu yang longgar, sementara domain utama dan subdomain lain tetap ketat. Ini biasanya pilihan paling aman sebagai langkah sementara. Opsi kedua, tambahkan sp=none atau sp=quarantine di record domain induk. Efeknya ke semua subdomain, termasuk subdomain yang tidak pernah dipakai. Penyerang bisa memalsukan email dari subdomain itu. Pakai opsi ini hanya kalau banyak subdomain bermasalah sekaligus dan belum sempat dipetakan satu per satu. Contoh record untuk opsi pertama, dengan nama domain yang perlu disesuaikan:

TEXT

; Contoh record sementara, hanya subdomain news yang dilonggarkan
_dmarc.news.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

; Record domain induk tetap ketat, sp ditulis eksplisit supaya niatnya jelas
_dmarc.example.com.       TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

Saat menambah record di Zone Editor, perhatikan nama lengkap yang tersimpan. Tergantung versi, Zone Editor bisa menambahkan nama domain secara otomatis, jadi pastikan hasil akhirnya _dmarc.news.example.com. dan bukan nama yang dobel. Setelah itu, cek ulang dengan dig. Perubahan baru terasa di sisi penerima setelah TTL record lama habis di cache resolver mereka.

Perbaikan permanen: alignment per subdomain dulu, baru policy diperketat

Record p=none di subdomain hanya menunda masalah. Perbaikan yang sebenarnya adalah membuat setiap pengirim di subdomain itu lolos alignment. Mulai dari inventaris. Siapa saja yang mengirim atas nama subdomain itu? Bisa script PHP di hosting, mailbox di cPanel, aplikasi di server lain, atau layanan newsletter pihak ketiga. Laporan rua adalah sumber data terbaik untuk ini, asalkan dibaca lewat parser, bukan dibuka manual satu per satu. Untuk setiap pengirim, pastikan minimal satu jalur aligned:

DKIM: tanda tangan harus memakai d= yang berada di bawah example.com. Di cPanel, cek Email Deliverability untuk melihat apakah subdomain itu punya DKIM sendiri dan record-nya sudah valid. Apakah subdomain otomatis mendapat key tergantung versi dan cara subdomain itu dibuat.
SPF: SPF dievaluasi terhadap domain envelope, dan tidak diwarisi dari domain induk. Kalau envelope memakai news.example.com, subdomain itu butuh record SPF sendiri.
Script PHP: kirim lewat SMTP terautentikasi ke mailbox yang benar-benar ada di domain itu, bukan lewat mail() dengan envelope bawaan server. Dengan begitu envelope dan DKIM ikut domain yang benar.
Layanan pihak ketiga: aktifkan custom domain atau DKIM sesuai dokumentasi layanan tersebut, lalu tambahkan record yang diminta.

Setelah semua pengirim siap, kirim ulang email uji dan pastikan Authentication-Results menunjukkan dmarc=pass. Baru setelah itu record p=none di subdomain dinaikkan ke quarantine, lalu ke reject, atau dihapus supaya subdomain kembali mengikuti sp di domain induk. Daftar hal yang perlu diaudit sebelum menaikkan policy ada di What to Audit Before Switching DMARC Policy from None to Reject. Intinya, p=reject di domain utama adalah keputusan untuk seluruh pohon domain, bukan hanya untuk domain itu saja. Sebelum menaikkan policy, cek _dmarc untuk setiap subdomain pengirim dengan dig. Tulis sp secara eksplisit supaya niatnya jelas. Kalau ada yang telanjur ditolak, longgarkan subdomain itu saja, bukan seluruh domain, sambil membereskan alignment-nya.