DMARC p=none: pasang tanpa memblokir email sah

Untuk domain email aktif, panduan peluncuran Google Workspace menganjurkan agar SPF dan DKIM disiapkan setidaknya 48 jam sebelum DMARC diterbitkan dengan p=none. Siapkan pula alamat penerima laporan, lalu pantau hasilnya sebelum meminta server penerima mengarantina atau menolak pesan yang gagal DMARC.

Dengan p=none, kegagalan autentikasi dapat muncul dalam laporan tanpa instruksi pemblokiran dari kebijakan DMARC domain Anda. Filter spam dan aturan lain di pihak penerima tetap dapat memengaruhi pengiriman. Karena itu, gunakan masa pemantauan untuk menemukan semua layanan yang mengirim email sah atas nama domain Anda dan membenahi jalur yang belum lulus.

Periksa pengirim serta penyelarasan SPF dan DKIM

Header email menunjukkan domain From, MAIL FROM, dan tanda tangan DKIM untuk memeriksa penyelarasan DMARC.

Catat jalur pengiriman yang memakai alamat From domain Anda: kotak surat utama, aplikasi transaksi, layanan newsletter, dan sistem yang mengirim pesan berkala. Periksa autentikasi setiap jalur, termasuk layanan yang volumenya kecil. Pesan uji ke penerima di luar sistem Anda membantu memperlihatkan hasil SPF, DKIM, dan DMARC pada header yang benar-benar diterima.

Penjelasan DMARC Microsoft menyebutkan bahwa pesan lulus jika SPF atau DKIM lulus sekaligus domainnya selaras dengan domain pada From. Untuk SPF, bandingkan domain MAIL FROM atau smtp.mailfrom dengan From; untuk DKIM, bandingkan domain penanda tangan d= dengan From. Hasil SPF atau DKIM yang tampak pass secara terpisah belum cukup bila keduanya memakai domain milik penyedia layanan yang tidak selaras.

Jika penyedia pihak ketiga memakai domainnya sendiri untuk MAIL FROM dan tanda tangan DKIM, minta dukungan penandatanganan DKIM dengan domain Anda atau MAIL FROM yang selaras. Penyelarasan longgar berlaku secara bawaan dan dapat mencakup subdomain dari domain organisasi yang sama. Mode ketat menuntut kecocokan yang lebih persis, sehingga periksa dahulu seluruh jalur subdomain sebelum mengaktifkannya.

Terbitkan record TXT awal di DNS domain

Buat kotak surat atau grup khusus untuk laporan agregat. Untuk domain ilustratif example.com, host record ialah _dmarc.example.com dan nilai TXT awalnya v=DMARC1; p=none; rua=mailto:[email protected]. Ganti example.com dan alamat laporan dengan milik Anda; alamat pada contoh bukan kotak surat yang siap dipakai.

Petunjuk penyiapan Google menempatkan record TXT tersebut pada host DNS domain dan mengingatkan bahwa sebagian panel menambahkan nama domain secara otomatis. Jika panel Anda bekerja demikian, isikan _dmarc sebagai nama host agar hasil akhirnya tidak menjadi _dmarc.example.com.example.com. Untuk domain khusus yang digunakan di Microsoft 365, record DMARC juga dikelola melalui penyedia DNS atau registrar domain.

Setelah menyimpan, cari TXT pada _dmarc.example.com dan pastikan nilainya tampil utuh serta tidak ada record DMARC lain pada host yang sama. Tag v menyatakan versi, p menetapkan tindakan yang diminta untuk kegagalan DMARC, dan rua menunjuk alamat laporan agregat. Pastikan kotak surat rua menerima pesan; bila alamatnya berada di domain lain, domain penerima laporan perlu menerbitkan otorisasi DNS tambahan agar laporan dapat dikirim.

Baca laporan dan cari pengirim sah yang gagal

Laporan agregat menunjukkan sumber pengiriman, jumlah pesan, hasil autentikasi, dan tindakan penerima. Mulailah dari sumber yang cocok dengan daftar layanan Anda. Perhatikan perbedaan antara autentikasi mentah dan penyelarasan: SPF dapat lulus untuk domain penyedia, tetapi hasil SPF untuk DMARC gagal karena domain itu tidak selaras dengan From.

Jika suatu sumber dikenal tetapi gagal DMARC, cocokkan alamat IP dan domain pada laporan dengan header pesan uji. Periksa smtp.mailfrom dan header.d untuk mengetahui jalur mana yang perlu diperbaiki. Bila MAIL FROM tidak dapat diselaraskan, tanda tangan DKIM dengan domain Anda dapat menjadi jalur kelulusan; bila tanda tangan DKIM gagal setelah pesan diteruskan atau diubah, telusuri perubahan tersebut sebelum menyimpulkan bahwa pengirim aslinya salah konfigurasi.

Laporan agregat merangkum kelompok pesan dan tidak selalu memberi rincian setiap email. Tidak semua penerima mengirim laporan, sementara layanan yang hanya mengirim sesekali mungkin belum muncul pada hari-hari awal. Cocokkan laporan dengan inventaris pengirim dan pesan uji; volume kegagalan yang kecil tetap perlu diperiksa bila berasal dari sistem sah yang mengirim pesan penting.

Mulai karantina pada sebagian pesan yang gagal

Kebijakan DMARC p=quarantine dengan pct=5 membatasi tahap awal karantina bagi pesan yang gagal.

Google menyarankan pemantauan p=none selama setidaknya satu minggu sebelum beralih ke karantina, dengan syarat tidak terlihat masalah pada email keluar yang sah. Untuk domain ilustratif tadi, record tahap berikutnya dapat berupa v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected]. Dalam contoh ini, pct=5 membatasi penerapan kebijakan pada sebagian pesan yang gagal DMARC, bukan pada lima persen dari seluruh email domain.

Setelah perubahan, periksa laporan dan pengiriman uji dari setiap layanan yang tercatat. Pesan yang terkena kebijakan karantina dapat masuk ke folder spam atau ditangani menurut sistem penerima. Jika sumber sah gagal, perbaiki SPF atau DKIM beserta penyelarasan domainnya sebelum menaikkan pct. Naikkan cakupan secara bertahap hingga pct=100 hanya setelah jalur sah yang diketahui tetap lulus dalam pemantauan.

Beralih ke reject setelah cakupan karantina stabil

Reject layak dipilih setelah karantina mencakup seluruh pesan yang gagal dan pemeriksaan ulang tidak menemukan pengirim sah yang masih bermasalah. Nilai untuk domain ilustratif dapat menjadi v=DMARC1; p=reject; rua=mailto:[email protected]. Tanpa tag pct, kebijakan berlaku untuk seluruh pesan yang gagal DMARC menurut penerima yang mengikuti record tersebut; pesan sah yang belum diperbaiki dapat ikut ditolak.

Sebelum perubahan, kirim ulang pesan dari layanan utama, layanan berjumlah kecil, dan sistem berkala yang sudah masuk inventaris. Sesudahnya, lanjutkan pemantauan ketika organisasi menambah penyedia atau mengubah cara pengiriman. Jika pengirim sah mulai gagal, telusuri hasil autentikasi dan penyelarasan pada sumbernya sebelum memutuskan perubahan kebijakan berikutnya.