Domain Anda Tidak Bisa Dibiarkan Menjadi Pengirim yang Tidak Terverifikasi: Keputusan DMARC Praktis untuk Usaha Kecil

Pelanggan melihat nama yang dikenal di kolom From, domain yang terasa akrab, lalu sebuah tanda terima pembayaran, pengingat janji, penawaran, atau tautan pengaturan ulang kata sandi. Yang tidak mereka lihat adalah pemeriksaan yang berlangsung sebelum pesan masuk ke kotak masuk. Mereka tidak melihat apakah sistem penagihan pihak ketiga benar-benar diberi wewenang mengirim atas nama bisnis, apakah alamat pengirim yang tampak selaras dengan identitas yang diautentikasi, atau apakah pihak lain mencoba memakai domain yang sama.

Ketidakterlihatan itu menjelaskan mengapa autentikasi email mudah ditunda. Situs sudah aktif, kotak surat berfungsi, kampanye tetap terkirim, dan platform pembayaran terus mengirim invoice. Tidak ada yang tampak rusak sampai pesan sah masuk spam, vendor mengubah konfigurasi pengiriman, atau pesan palsu memakai nama bisnis dan sampai ke pelanggan. Saat itu, masalahnya bukan sekadar DNS. Masalahnya adalah siapa yang boleh memakai identitas domain di hadapan penerima.

DMARC adalah singkatan dari Domain-based Message Authentication, Reporting, and Conformance. DMARC memberi pemilik domain cara untuk menerbitkan instruksi tentang email yang mengaku berasal dari domain tersebut. Mekanisme ini menggunakan dua sistem yang sudah ada, SPF dan DKIM, lalu menambahkan pemeriksaan keselarasan. Domain yang berhasil diautentikasi harus selaras dengan domain yang dilihat penerima pada header From. Kebijakan DMARC juga menyampaikan perlakuan yang diminta pemilik domain ketika pesan gagal pemeriksaan, serta alamat untuk menerima laporan.

Bagi usaha kecil, targetnya bukan membuat setiap pesan sempurna dalam satu sore. Targetnya adalah memiliki orang yang bertanggung jawab atas domain, daftar pengirim yang sah, dan jalan kerja dari pengamatan menuju penegakan kebijakan. Domain tanpa catatan DMARC belum menerbitkan jalan itu. Domain dengan catatan yang berhenti selamanya pada tahap pengamatan memang mengirim sinyal, tetapi belum menyelesaikan pengendalian identitasnya.

Persoalan ini sangat praktis. Google menyatakan bahwa semua pengirim ke akun Gmail pribadi harus memenuhi persyaratan dasar, termasuk persyaratan autentikasi. Google menerapkan persyaratan tambahan bagi pengirim massal, yaitu pengirim yang mengirim hampir 5.000 atau lebih pesan ke akun Gmail dalam sehari. Yahoo juga membedakan pengirim umum dan pengirim massal, serta memasukkan DMARC dalam praktik autentikasi emailnya. Artinya, verifikasi pengirim adalah urusan operasional, termasuk bagi bisnis yang tidak menganggap dirinya perusahaan pemasaran email.

Email juga tersebar di banyak sistem. Satu domain dapat dipakai oleh Microsoft 365 atau Google Workspace, formulir situs, perangkat lunak akuntansi, CRM, toko daring, meja bantuan, platform reservasi, dan layanan newsletter. Semuanya dapat sah. Semuanya dapat memiliki cara autentikasi berbeda. Namun, identitas yang dilihat pelanggan tetap satu domain. Pelanggan tidak akan membedah kerumitan itu untuk bisnis Anda.

Keputusan awalnya sederhana: perlakukan domain pengirim sebagai aset yang memerlukan kebijakan autentikasi yang dipublikasikan, bukan sebagai label yang dapat dipakai setiap layanan terhubung tanpa pemeriksaan berkelanjutan.

Google dan Yahoo tidak memperlakukan DMARC sebagai latihan keamanan yang berdiri sendiri. Panduan mereka menghubungkan autentikasi dengan pengiriman email dan perilaku pengirim. Rinciannya penting karena bisnis kecil sering mendapat saran yang setengah jadi, misalnya hanya diminta menambahkan SPF tanpa memahami syarat mana yang berlaku untuk jenis lalu lintas tertentu.

Panduan pengirim email Google memisahkan persyaratan dasar dari persyaratan tambahan untuk pengirim massal. Pengirim ke akun Gmail pribadi perlu menggunakan SPF atau DKIM untuk domainnya, memiliki catatan DNS maju dan balik yang valid, memakai TLS untuk transmisi email, dan menjaga tingkat spam tetap rendah. Untuk pengirim massal, Google mensyaratkan SPF, DKIM, dan DMARC. Kebijakan DMARC minimum yang diminta Google untuk pengirim massal adalah p=none. Google juga meminta keselarasan antara domain pada header From yang terlihat dan domain yang diautentikasi oleh SPF atau DKIM.

Yahoo menyampaikan arah serupa. Semua pengirim sebaiknya mengautentikasi email dengan SPF atau DKIM. Pengirim massal sebaiknya memakai SPF, DKIM, dan DMARC. Yahoo mendefinisikan pengirim massal sebagai pihak yang mengirim lebih dari 5.000 pesan per hari ke akun Yahoo Mail. Panduannya turut membahas penanganan berhenti berlangganan untuk email pemasaran dan pengirim massal, tingkat keluhan, serta konfigurasi DNS yang valid.

Dua kumpulan panduan itu bukan daftar yang boleh disalin tanpa memeriksa alur email sendiri. Keduanya menunjukkan bahwa domain bukan hanya nama kotak surat. Keduanya juga membantu membedakan autentikasi dari kebijakan. SPF membantu memeriksa apakah infrastruktur pengiriman diizinkan untuk identitas envelope sender yang relevan. DKIM membantu memeriksa tanda tangan kriptografis yang terkait dengan suatu domain. DMARC menilai apakah SPF atau DKIM berhasil dan selaras dengan domain From, kemudian menerapkan kebijakan yang diminta pemilik domain serta instruksi pelaporan.

Perbedaannya penting. SPF dapat berhasil untuk domain yang berbeda dari domain yang dilihat pelanggan pada kolom pengirim. DKIM juga dapat berhasil untuk domain yang berbeda. DMARC bertanya apakah setidaknya satu domain yang berhasil diautentikasi itu selaras dengan domain From menurut aturan keselarasannya. Hasil autentikasi saja belum cukup untuk menghasilkan DMARC pass.

Karena itu, pertanyaan seperti “apakah platform newsletter kami punya SPF?” terlalu sempit. Pertanyaan operasional yang tepat ialah: “ketika platform ini mengirim email dengan domain kami pada From, apakah SPF atau DKIM akan berhasil dan selaras dengan domain tersebut?” Pertanyaan yang sama berlaku untuk invoice, balasan bantuan pelanggan, notifikasi formulir, email akun, dan pesan transaksi.

Panduan Google juga menegaskan bahwa ketentuan mengikuti kategori pengirim dan volume terhadap penerima, bukan cara perusahaan menggambarkan dirinya. Perusahaan kecil dapat mengirim kampanye besar pada hari tertentu. Bisnis yang biasanya mengirim sedikit email dapat memakai layanan yang mengubah konfigurasi pengirimannya. Sikap yang lebih aman adalah membangun pengiriman yang terautentikasi sebelum kegagalan pengiriman memaksa pekerjaan itu dilakukan dalam keadaan mendesak.

Yahoo memberi alasan tambahan untuk tidak berhenti pada catatan DNS. Autentikasi berjalan berdampingan dengan tingkat keluhan spam yang rendah dan mekanisme berhenti berlangganan yang mudah digunakan apabila berlaku. DMARC tidak memperbaiki email yang tidak diinginkan, persetujuan pemasaran yang buruk, atau daftar penerima yang dikelola sembarangan. DMARC membangun batas identitas yang lebih jelas untuk pesan yang membawa nama domain.

Ringkasnya, SPF dan DKIM mengautentikasi bagian berbeda dari alur email. DMARC memeriksa apakah setidaknya satu hasil yang lolos selaras dengan identitas From yang terlihat. Google dan Yahoo menempatkan DMARC sebagai syarat tambahan bagi pengirim massal. Kebijakan p=none adalah tahap pengamatan, bukan akhir perlindungan domain. Praktik pengiriman, keluhan, dan berhenti berlangganan tetap menjadi tanggung jawab terpisah.

DMARC sering disebut sebagai autentikasi email. Sebutan itu benar, tetapi belum lengkap. DMARC tidak membuat tanda tangan ketiga yang berdiri sendiri. RFC 7489 mendefinisikan proses yang menilai hasil SPF dan DKIM, menguji keselarasan dengan domain RFC 5322.From, menerapkan kebijakan yang diterbitkan pemilik domain, dan menyediakan instruksi pelaporan.

Header From penting karena itulah alamat yang dipakai pelanggan untuk menilai siapa pengirimnya. Dalam istilah RFC, RFC 5322.From adalah header From. Bila sebuah pesan menampilkan [email protected], DMARC mengevaluasi keselarasan terhadap contoh.com. Bukan terhadap nama tampilan saja, bukan terhadap domain lain yang kebetulan berhubungan dengan penyedia email.

Keselarasan SPF membandingkan domain yang digunakan SPF, yang umumnya terkait identitas SMTP MAIL FROM, dengan domain dalam header From. Keselarasan DKIM membandingkan domain d= pada tanda tangan DKIM yang valid dengan domain From yang terlihat. Agar DMARC lulus, setidaknya satu mekanisme harus sekaligus lulus autentikasi dan selaras.

Frasa “setidaknya satu” perlu dipahami. Sebuah email tidak wajib membuat SPF dan DKIM sama-sama lulus DMARC. Satu hasil yang lulus dan selaras sudah cukup. Namun, mempertahankan SPF dan DKIM tetap masuk akal karena keduanya memeriksa bagian alur email yang berbeda dan dapat gagal dalam kondisi yang berbeda. Google dan Yahoo meminta keduanya untuk kategori pengirim massal mereka.

RFC 7489 mendeskripsikan dua mode keselarasan. Keselarasan longgar memperbolehkan kecocokan pada organisational domain. Keselarasan ketat mengharuskan domain yang tepat sama. Pemilik domain dapat menerbitkan pilihan itu melalui tag adkim dan aspf. Dampaknya terasa pada penggunaan subdomain dan perlu disesuaikan dengan desain pengiriman yang benar-benar digunakan organisasi.

Misalnya, sebuah bisnis memakai contoh.com sebagai domain yang dikenal pelanggan. Platform pemasarannya mungkin menandatangani email dengan d=mail.contoh.com, sedangkan alamat From adalah [email protected]. Dalam keselarasan DKIM longgar, keduanya dapat selaras karena berbagi organisational domain. Dalam keselarasan ketat, keduanya tidak selaras karena tidak identik. Tidak ada satu pengaturan yang tepat untuk semua domain. Pengaturan harus mengikuti sistem pengiriman yang sudah dipetakan, bukan perkiraan.

DMARC juga menerbitkan disposisi yang diminta melalui tag p. Nilai umum adalah p=none, p=quarantine, dan p=reject. p=none meminta agar tidak ada tindakan penegakan khusus berdasarkan kegagalan DMARC, sehingga pemilik domain dapat mengamati dan menerima laporan. p=quarantine meminta penerima memperlakukan email yang gagal sebagai mencurigakan. p=reject meminta penerima menolak email yang gagal.

Penerima tetap membuat keputusan akhir. RFC 7489 menggambarkan kebijakan DMARC sebagai permintaan dari pemilik domain dan mengakui bahwa penerima dapat menerapkan kebijakan lokalnya sendiri. Karena itu, bisnis tidak boleh menyatakan bahwa DMARC membuat peniruan mustahil atau menjamin email selalu masuk inbox. DMARC tidak melakukan keduanya. Ia membuat preferensi pemilik domain terhadap email yang tidak diautentikasi atau tidak selaras menjadi jelas bagi penerima yang menjalankan evaluasi DMARC.

Model mental yang berguna adalah urutan pertanyaan. Apakah SPF lulus? Apakah DKIM lulus? Apakah setidaknya salah satu hasil yang lulus selaras dengan domain From? Jika tidak, kebijakan apa yang diterbitkan pemilik domain? Lalu, bagaimana sistem penerima mengambil keputusan berdasarkan implementasi dan kebijakan lokalnya?

Urutan itu menjelaskan mengapa satu email uji dapat menyesatkan. Satu layanan mungkin menandatangani email dengan benar, sementara layanan sah lain belum dikenali. Pesan dapat lulus SPF tetapi gagal selaras. Jalur penerusan dapat mengubah keadaan ketika SPF dinilai. Peluncuran berbasis laporan memperlihatkan perbedaan itu sebelum bisnis meminta penerima mengarantina atau menolak kegagalan.

Catatan DMARC diterbitkan di DNS pada _dmarc.contoh.com dalam bentuk TXT record dan biasanya dimulai dengan v=DMARC1. RFC 7489 mendefinisikan tag untuk kebijakan, alamat laporan agregat, alamat laporan kegagalan, penemuan catatan, otorisasi tujuan laporan eksternal, serta penanganan catatan yang rusak atau lebih dari satu. Detail ini bukan urusan teknis kecil. DNS adalah tempat bisnis menyatakan kebijakannya. Jika tidak ada orang yang tahu siapa yang dapat mengubahnya, tidak ada kepemilikan yang jelas atas identitas pengirim.

Menerbitkan DMARC dengan p=none adalah langkah awal yang sah. Itu bukan strategi yang selesai. Kebijakan pengamatan memberi pemilik domain kemampuan melihat email yang mengaku memakai domainnya tanpa meminta karantina atau penolakan bagi email yang gagal. Nilainya besar, terutama ketika bisnis menemukan pengirim sah yang tidak pernah dicatat sebelumnya: layanan formulir, aplikasi lama, platform keuangan, alat dukungan pelanggan, atau penyedia yang pernah dikonfigurasi mantan staf maupun agensi.

CISA melalui Binding Operational Directive 18-01 mewajibkan lembaga Federal Civilian Executive Branch menerapkan DMARC untuk domain email mereka dan bergerak menuju kebijakan p=reject. Lingkup arahan itu adalah lembaga pemerintah federal tertentu, bukan kewajiban langsung bagi setiap usaha kecil. Namun, arah kebijakannya menegaskan perbedaan antara pemantauan dan perlindungan: pengamatan diperlukan untuk memahami sumber pengiriman, sedangkan penegakan kebijakan adalah tahap ketika domain meminta penerima bertindak terhadap kegagalan.

Posisi pengamatan dapat menjadi permanen karena alasan yang mudah dimengerti. Laporan tampak teknis. Orang yang mengelola DNS belum tentu mengelola platform email. Penyedia kampanye mungkin dikelola agensi. Pemilik bisnis dapat khawatir kebijakan ketat mengganggu invoice atau balasan dukungan pelanggan. Semua itu adalah alasan untuk menyelidiki dengan cermat. Bukan alasan untuk berhenti menyelidiki.

Risiko p=none yang dibiarkan tanpa arah juga sederhana. Pemilik domain meminta penerima untuk tidak mengambil tindakan penegakan DMARC tertentu ketika email gagal. Pemilik mungkin melihat kegagalan dalam laporan, tetapi kebijakannya tidak meminta penerima mengarantina atau menolak email tersebut atas namanya. Ada perbedaan penting antara melihat penggunaan yang tidak diautentikasi dan bertindak terhadapnya. Yang pertama adalah telemetri. Yang kedua adalah pengendalian.

Ini bukan argumen agar setiap domain langsung memakai p=reject. Kebijakan ketat yang diterapkan sebelum pengirim sah dikonfigurasi dengan benar dapat mengganggu pesan nyata. Pendekatan yang tepat bersifat bertahap, berbasis bukti, dan dipimpin orang yang mampu memperbaiki konfigurasi pengiriman.

Tahap pertama adalah menemukan semua sumber yang sah sambil memakai p=none. Tahap kedua adalah memperbaiki setiap sumber agar SPF dan atau DKIM yang relevan lulus dan selaras, lalu memeriksa alur email yang diharapkan. Tahap berikutnya dapat memakai p=quarantine setelah kegagalan sah diselesaikan atau dipisahkan secara sengaja. Tahap penegakan dapat memakai p=reject ketika penggunaan domain yang diizinkan sudah dipahami dan pemantauan tetap berjalan.

Urutan itu adalah urutan tata kelola sekaligus urutan teknis. Bisnis perlu mencatat sistem mana yang boleh mengirim atas nama domain, siapa pemilik hubungan dengan setiap layanan, subdomain mana yang dipakai bila ada, dan bagaimana layanan itu mengautentikasi email. Catatan tersebut mencegah kegagalan yang sering terjadi: alat baru dihubungkan, pesan mulai dikirim, tetapi tidak seorang pun memeriksa apakah pengiriman itu selaras dengan domain yang terlihat pelanggan.

Subdomain juga perlu diperhatikan. RFC 7489 menyediakan tag sp untuk kebijakan subdomain ketika tidak ada catatan DMARC subdomain yang eksplisit. Perusahaan dapat memisahkan lalu lintas, misalnya berita.contoh.com untuk newsletter dan resi.contoh.com untuk pesan transaksi. Pemisahan seperti ini dapat membantu atribusi, tetapi tidak menghapus kewajiban memahami setiap pengirim. Ia justru membuat batas bagi tiap tujuan pengiriman lebih jelas.

Alasan utama untuk tidak tinggal selamanya pada p=none bukan ketakutan. Alasannya adalah kejelasan. Bisnis yang sudah mengenali dan mengautentikasi seluruh pengirim sah berada pada posisi untuk meminta penerima memperlakukan kegagalan secara berbeda. Bisnis yang belum bisa melakukannya akan mengetahui pekerjaan yang tersisa. Keduanya lebih baik daripada menganggap satu TXT record sudah menyelesaikan persoalan.

Catatannya memang singkat. Persiapan di belakangnya tidak singkat. Konfigurasi yang tahan perubahan dimulai dari inventaris, lalu diterjemahkan ke pengaturan DNS dan pemeriksaan yang dapat diulang.

SPF diterbitkan sebagai TXT record DNS. Dalam konteks DMARC, poin operasional utamanya adalah bahwa SPF yang lulus harus selaras dengan domain From agar dapat menyumbang pada kelulusan DMARC. Penyedia dapat memberi petunjuk untuk menambahkan mekanisme include atau menggunakan domain return-path khusus. Petunjuk itu harus diterapkan sesuai dokumentasi penyedia, lalu diuji bersama alamat From yang digunakan pelanggan.

SPF memiliki batas praktis. Evaluasi SPF melibatkan lookup DNS yang dibatasi spesifikasi SPF. Catatan yang makin kompleks dapat menghasilkan kegagalan. Jangan terus menambahkan include dari vendor lama tanpa meninjau ulang keseluruhan catatan. Hapus layanan yang tidak lagi diizinkan. Jangan membuat beberapa SPF TXT record pada domain yang sama, karena hasilnya dapat menjadi SPF permerror alih-alih gabungan izin yang teratur.

DKIM biasanya diatur lewat penyedia pengiriman. Penyedia membuat atau meminta bisnis menerbitkan selector record, lalu menandatangani email keluar. Bisnis perlu memeriksa header pesan yang diterima atau proses verifikasi penyedia untuk memastikan DKIM lulus dan mengetahui domain pada d=. Tanda tangan yang valid dari domain penyedia yang tidak terkait mungkin berguna untuk autentikasi penyedia tersebut, tetapi belum tentu memenuhi keselarasan DMARC bagi domain bisnis pada From.

DMARC adalah catatan kebijakan yang menghubungkan pekerjaan itu. Bentuk awal yang lazim dapat berupa v=DMARC1; p=none; rua=mailto:[email protected]. Ini hanya ilustrasi bentuk catatan, bukan konfigurasi yang boleh disalin lalu dilupakan. Alamat laporan harus dapat menerima dan benar-benar ditinjau oleh pihak yang bertanggung jawab.

RFC 7489 mendefinisikan alamat laporan agregat melalui tag rua. Jika laporan dikirim ke domain yang berbeda dari domain kebijakan, tujuan eksternal itu memerlukan catatan otorisasi yang relevan sebagaimana dijelaskan RFC. Catatan dapat memuat tag lain seperti pct, adkim, aspf, sp, ruf, dan fo. p menyatakan kebijakan domain. rua menentukan tujuan laporan agregat. ruf menentukan tujuan laporan kegagalan, dengan dukungan penerima dan pertimbangan privasi yang dijelaskan RFC. adkim serta aspf memilih mode keselarasan. sp dapat menetapkan kebijakan subdomain. pct dapat menerapkan kebijakan pada persentase email gagal dalam peluncuran bertahap.

Jangan menambahkan semua tag hanya karena muncul dalam contoh. Tambahkan tag karena bisnis dapat menjelaskan alasannya, tahu siapa yang memantau dampaknya, dan memiliki tindakan bila konfigurasi berubah. Catatan yang paling penting sering kali bukan TXT record, melainkan inventaris di sampingnya.

Inventaris itu sebaiknya mencantumkan setiap sumber pengiriman, tujuan emailnya, domain From yang terlihat, status SPF yang selaras, status DKIM yang selaras, pemilik teknis, dan tanggal peninjauan terakhir. Masukkan email orang-ke-orang dari layanan kantor, invoice dari penyedia penagihan, kampanye dari platform pelanggan, notifikasi formulir situs, pesan toko daring, dan aplikasi internal yang mengirim pemberitahuan.

Kolom-kolom tersebut harus berisi jawaban nyata sebelum kebijakan diperketat. “Periksa nanti” bukan jawaban untuk status keselarasan. Ketika vendor menambah wilayah pengiriman, mengganti selector DKIM, atau meminta pembaruan DNS, pemilik domain perlu dapat melihat bagian mana dari sistem email yang terpengaruh. Inventaris membuat perubahan vendor lebih aman, dan membantu membedakan pengirim baru yang sah dari pengirim yang belum pernah disetujui.

Pelaporan DMARC adalah tempat sebuah pengaturan DNS berubah menjadi kebiasaan operasional. Laporan dapat berbentuk XML yang padat. Karena itu, bisnis dapat memakai kotak surat laporan dengan pemilik yang jelas atau layanan pemrosesan laporan yang sesuai dengan kebutuhan keamanan dan privasinya. Tujuannya bukan agar setiap staf membaca XML mentah. Tujuannya adalah agar seseorang memeriksa bukti dan menindaklanjuti anomali.

RFC 7489 mendefinisikan pelaporan agregat melalui tag rua. Laporan agregat memberi informasi tentang arus pesan yang diamati penerima, termasuk alamat IP sumber, hasil autentikasi, evaluasi kebijakan, dan jumlah pesan. Laporan membantu pemilik domain melihat apakah email yang mengaku menggunakan domainnya lulus SPF dan DKIM, apakah keselarasan berhasil, dan sumber mana yang terlibat.

Rutinitas pemeriksaan harus dimulai dengan klasifikasi, bukan dengan perubahan DNS mendadak. Kategori pertama adalah sumber yang dikenal dan lulus: penyedia yang dikenali mengirim lalu lintas yang diharapkan dan SPF atau DKIM selaras. Kategori kedua adalah sumber yang dikenal tetapi gagal: penyedia sah mengirim email, tetapi konfigurasinya belum memenuhi DMARC. Kategori ketiga adalah sumber yang tidak dikenal namun mungkin sah, misalnya layanan lama, aplikasi yang terlupakan, agensi, atau perubahan infrastruktur. Kategori keempat adalah sumber yang tidak dikenal dan tidak diizinkan.

Kategori kedua paling mendesak saat peluncuran. Gagalnya pengirim sah mudah dianggap tidak berbahaya karena pelanggan mungkin masih menerima sebagian pesan selama p=none. Namun, kegagalan itu menunjukkan bisnis belum membangun identitas yang selaras untuk pengirim yang disetujui. Perbaiki sebelum kebijakan diperketat.

Kategori keempat menjelaskan mengapa laporan tetap penting setelah kebijakan diperketat. Pemilik domain dapat melihat penggunaan yang tidak sah, spoofing, atau salah konfigurasi. Laporan tidak dengan sendirinya membuktikan niat di balik tiap catatan. Laporan memberikan bukti bahwa suatu sumber mengirim email yang mengaku memakai domain dan menunjukkan bagaimana penerima mengevaluasinya. Selidiki sebelum menyimpulkan, terutama ketika pihak ketiga, infrastruktur bersama, atau penerusan dapat memperumit atribusi.

Bagi banyak usaha kecil, peninjauan bulanan dapat cukup setelah peluncuran stabil. Saat penyiapan awal, pemeriksaan perlu lebih sering, terutama sesudah perubahan DNS atau peluncuran platform baru. Pertanyaan pemeriksaannya sederhana: apakah semua pengirim yang diharapkan muncul; apakah email yang diharapkan lulus DMARC; apakah kebijakan domain sesuai tahap peluncuran saat ini; apakah seseorang memiliki akses dan tanggung jawab atas alamat laporan; dan apakah layanan yang dihentikan sudah dicabut otorisasinya.

Jika jawaban atas salah satu pertanyaan itu tidak, tindakannya harus spesifik. Sumber yang hilang atau tidak dikenal perlu diinvestigasi. Kegagalan SPF, DKIM, atau keselarasan perlu diperbaiki pada return-path, domain penandatangan DKIM, atau konfigurasi From. Kebijakan perlu diperbarui secara sengaja dengan rencana pengujian. Kotak surat laporan perlu diberi pemilik. Vendor yang sudah tidak dipakai perlu dihapus dari otorisasi dan perubahan tersebut didokumentasikan.

Laporan perlu dibaca bersama pengujian pesan nyata. Kirim email dari setiap layanan yang disetujui ke kotak surat uji di penyedia besar. Periksa hasil autentikasi pada header pesan yang diterima. Konfirmasikan domain From, hasil SPF, hasil DKIM, dan hasil DMARC. Laporan dapat menunjukkan pola umum; header pesan memberi contoh nyata tentang apa yang dinilai penerima.

Peninjauan juga memiliki batas. Laporan DMARC bukan inventaris lengkap semua masalah email bisnis. Laporan tidak mengukur apakah isi pesan berguna, apakah pelanggan memberi persetujuan pemasaran, atau apakah aturan penyaringan lokal penerima akan menaruh pesan di inbox. Panduan Google dan Yahoo menunjukkan bahwa autentikasi berjalan bersama persyaratan tingkat spam dan praktik pengiriman.

Meski demikian, laporan menjawab satu pertanyaan yang sempit dan penting: siapa yang memakai domain sebagai identitas email, dan apakah mereka melakukannya dengan autentikasi yang selaras? Itulah pertanyaan yang perlu dijawab sebelum bisnis bergerak dari p=none ke p=quarantine atau p=reject.

Pelanggan tidak membaca catatan DMARC, tetapi mereka merasakan hasil dari disiplin identitas. Mereka melihat apakah tanda terima sampai, apakah balasan dukungan menggunakan domain yang konsisten, dan apakah pesan yang membawa nama perusahaan dapat dibedakan dari tiruan yang gagal memakai domain itu secara sah.

Wajah pengirim yang dapat dipercaya dimulai dari konsistensi. Domain pada alamat From harus dipilih secara sengaja. Platform pengirim perlu dikonfigurasi untuk mengautentikasi domain itu melalui SPF atau DKIM yang selaras. Bisnis harus mengetahui alasan pengiriman, pihak yang mengoperasikan layanan, dan cara menghentikan penggunaan layanan ketika hubungan dengan vendor berakhir.

Hal ini relevan ketika bisnis memakai beberapa merek, unit usaha, atau fungsi pengiriman. Subdomain pemasaran dapat memberi identitas yang jelas pada newsletter. Subdomain transaksional dapat membedakan email pembayaran atau akun. Domain terpisah dapat sesuai untuk merek yang memang terpisah. Itu adalah pilihan desain, bukan kewajiban yang dipaksakan DMARC. Nilainya ada pada tanggung jawab pengiriman yang lebih mudah terlihat di dalam organisasi.

Hindari jalan pintas yang menyesatkan. Mengubah nama tampilan tidak mengautentikasi email. Klaim penyedia bahwa layanannya “meningkatkan deliverability” tidak membuktikan keselarasan. SPF yang disalin dari artikel bantuan tidak membuktikan identitas From yang terlihat sudah tercakup. Kepercayaan berasal dari konfigurasi gabungan dan bukti bahwa konfigurasi itu bekerja.

DMARC memberi pemilik domain cara untuk menghubungkan nama yang dilihat pelanggan pada header From dengan sistem email terautentikasi yang telah disetujui pemilik. Hubungan itu baru berguna ketika bisnis memeliharanya melalui inventaris pengirim, peninjauan laporan, dan kebijakan yang sesuai dengan tingkat kendali nyata yang dimilikinya.

Bahasa tentang kepercayaan pelanggan harus tetap hati-hati. DMARC dapat membantu penerima mengenali email yang gagal autentikasi selaras dan dapat meminta mereka mengarantina atau menolaknya. DMARC tidak dapat menjamin setiap email aman. DMARC tidak menghentikan penipu mendaftarkan domain yang tampak mirip. DMARC juga tidak mencegah kotak surat sah yang telah disusupi mengirim email berbahaya yang masih lulus autentikasi. Yang dapat dikurangi adalah satu jenis ambiguitas: penggunaan domain itu sendiri tanpa autentikasi atau tanpa keselarasan.

Batas tersebut sudah cukup untuk membenarkan pekerjaan ini. Perlindungan merek sering dibahas dengan istilah luas, tetapi bisnis kecil dapat melakukan perbaikan yang nyata dengan menentukan layanan mana yang boleh memakai domainnya dan menerbitkan kebijakan yang dapat ditegakkan terhadap penggunaan lain yang gagal DMARC.

DMARC kuat karena sifatnya spesifik. DMARC juga terbatas karena pengiriman email rumit. Pertama, DMARC tidak menggantikan SPF atau DKIM. DMARC bergantung pada hasil keduanya. SPF yang rusak, pesan yang tidak ditandatangani, atau tanda tangan DKIM yang rusak akibat perubahan pesan dapat menimbulkan kegagalan DMARC apabila tidak ada mekanisme selaras lain yang lulus. Tanggapannya bukan otomatis melonggarkan kebijakan. Tanggapannya adalah mengenali alur email dan membangun jalur autentikasi yang selaras.

Kedua, penerusan dapat menyulitkan SPF. RFC 7489 membahas alur email tidak langsung dan mengakui bahwa autentikasi SPF dapat gagal ketika penerusan mengubah jalur yang dipakai penerima untuk menilai email. DKIM dapat menyediakan jalan menuju kelulusan DMARC dalam kondisi tersebut jika tanda tangan tetap valid dan selaras. Namun, perubahan pada konten yang ditandatangani dapat membatalkan tanda tangan. Inilah alasan bisnis tidak boleh bergantung pada satu contoh pengujian atau satu mekanisme saja.

Ketiga, DMARC tidak mengendalikan semua penerima dengan cara yang sama. RFC 7489 menyebut kebijakan sebagai permintaan dan memberi ruang bagi penerima untuk menerapkan kebijakan lokal. Google dan Yahoo menerbitkan persyaratan serta praktik penegakan mereka sendiri. Penerima lain dapat mengambil keputusan berbeda. DMARC sebaiknya dijelaskan sebagai mekanisme kebijakan autentikasi domain yang digunakan luas, bukan perintah universal atas seluruh kotak masuk.

Keempat, data laporan perlu ditangani dengan hati-hati. RFC 7489 menjelaskan pertimbangan privasi dan pelaporan, terutama untuk laporan kegagalan. Pelaporan agregat biasanya menjadi titik awal untuk mendapatkan visibilitas. Bisnis perlu memutuskan siapa yang menerima laporan, berapa lama laporan disimpan, dan apakah layanan pelaporan eksternal sesuai dengan kebutuhan keamanan serta privasinya sendiri.

Kelima, kebijakan penolakan dapat menampilkan sistem yang selama ini terabaikan. Itu menjadi manfaat hanya setelah bisnis menyelesaikan pekerjaan penemuan. Jika aplikasi lama mengirim pengaturan ulang kata sandi dengan alamat From yang tidak diautentikasi, perpindahan ke p=reject dapat membuat pesan itu tidak diterima oleh penerima yang menghormati kebijakan. Jawabannya adalah memperbaiki atau mengganti pengirim, atau memisahkan alur email melalui domain yang diautentikasi dengan tepat. Jawabannya bukan membiarkan domain selamanya tidak terlindungi karena mungkin masih ada sistem yang belum dikenal.

Kompromi dapat dikelola dengan ruang lingkup dan waktu. Gunakan laporan. Verifikasi penyedia. Pertimbangkan subdomain bagi aliran pesan yang berbeda. Gunakan pct bila penerapan kebijakan bertahap sesuai kebutuhan. Simpan catatan perubahan. Uji penyedia baru sebelum peluncuran. Semua itu adalah disiplin operasional, bukan tugas DNS sekali jalan.

Bisnis juga perlu menahan diri dari klaim berlebihan kepada pelanggan dan staf. Hindari pernyataan bahwa DMARC menjamin pengiriman atau menghentikan phishing. Sumber yang digunakan tidak mendukung pernyataan mutlak tersebut. Pernyataan yang lebih tepat adalah bahwa DMARC memungkinkan pemilik domain menerbitkan kebijakan untuk pesan yang gagal pemeriksaan SPF dan DKIM yang selaras, dan kebijakan yang lebih kuat dapat membantu melindungi domain dari penggunaan yang tidak diautentikasi pada penerima yang menerapkan kebijakan itu.

Keputusannya bukan apakah bisnis harus menjadi spesialis keamanan email. Keputusannya adalah apakah bisnis akan memiliki identitas yang melekat pada email keluarnya. Mulailah dari domain yang dilihat pelanggan. Daftarkan setiap sistem yang mengirim email memakai domain tersebut, termasuk yang jelas maupun yang sering luput: formulir situs, platform akuntansi, alat dukungan, kalender, notifikasi toko daring, perangkat lunak rekrutmen, dan agensi.

Untuk setiap sistem, catat domain From yang terlihat, identitas SPF, domain penandatangan DKIM, pemilik teknis, dan tujuan bisnisnya. Verifikasi SPF serta DKIM dari header email nyata yang diterima. Lalu konfirmasikan bahwa setidaknya satu hasil yang lulus selaras dengan domain From untuk tiap pengirim. Langkah itu menghasilkan dasar bukti yang tidak dapat digantikan oleh dugaan atau satu tangkapan layar dari panel vendor.

Setelah itu, terbitkan atau tinjau catatan DMARC pada _dmarc untuk domain. Jika pengirim belum dipetakan, mulai dengan p=none dan alamat laporan agregat yang benar-benar dipantau. Google menerima p=none sebagai kebijakan minimum untuk persyaratan DMARC pengirim massal. Gunakan periode tersebut untuk memperbaiki keselarasan, bukan untuk menyatakan pekerjaan sudah selesai.

Tetapkan tanggal peninjauan sebelum catatan diterbitkan. Tanggal itu harus memicu keputusan berbasis bukti: tetap mengamati karena masalah sah yang bernama masih diperbaiki, berpindah ke p=quarantine karena pengirim yang diketahui sudah selaras, atau maju ke p=reject karena penggunaan domain yang diizinkan sudah dipahami dan bisnis siap meminta penolakan atas kegagalan. Catat alasan di balik keputusan itu.

Daftar tindakan awalnya ringkas:

• Tunjuk satu pemilik akuntabel untuk kebijakan DNS dan satu pemilik untuk peninjauan laporan, meskipun keduanya orang yang sama.
• Inventarisasi semua pengirim yang disetujui, lalu uji hasil SPF dan DKIM dari pesan nyata.
• Pastikan keselarasan DMARC untuk tiap pengirim dan publikasikan p=none bila belum ada catatan DMARC.
• Tinjau laporan dan perbaiki kegagalan yang dikenal.
• Buat jalur bertanggal menuju p=quarantine lalu p=reject apabila bukti mendukungnya.
• Jadikan pemeriksaan autentikasi bagian dari proses memilih maupun menghentikan vendor email.

Itulah keputusan DMARC yang praktis bagi usaha kecil. Jangan menunggu krisis pengiriman untuk mengetahui sistem mana yang berbicara atas nama domain. Buat daftarnya, baca buktinya, lalu bergerak dari visibilitas menuju kebijakan yang mencerminkan kendali nyata.

*Sumber: Panduan pengirim email Google; Praktik terbaik pengirim Yahoo; Ikhtisar DMARC.org; CISA Binding Operational Directive 18-01; RFC 7489 tentang DMARC.*