A DMARC Permintaan perubahan harus memungkinkan orang lain untuk menentukan dengan tepat apa yang akan berubah, layanan mana yang dapat terpengaruh, dan bagaimana keberhasilan akan ditunjukkan. Tangkapan layar yang menunjukkan kebijakan yang diinginkan saja tidak cukup. Pertahankan baseline dan usulan RRset, lalu hubungkan dengan alur bisnis yang disetujui dan keputusan pemulihan.
Tangkap garis dasar dengan tepat
Catat akun atau penyewa penyedia DNS , zona, nama pemilik, jenis rekaman, nilai lengkap, dan TTL. Cantumkan waktu dan sumber observasi. Catat penemuan kebijakan DMARC saat ini untuk domain penulis yang terpengaruh, ditambah pengirim yang disetujui dan pengecualian apa pun yang belum terselesaikan. Pertahankan pengidentifikasi autentikasi daripada mengurangi pengujian menjadi warna dasbor.
DMARC dapat melewati kesuksesan yang selaras SPF atau DKIM hasil. Oleh karena itu, domain Dari pesan yang terlihat dan pengidentifikasi yang diautentikasinya lebih penting daripada pernyataan umum yang diteruskan SPF . RFC 9989. Untuk penerbitan domain p=reject, RFC 9989 bagian 7.4 dan 8 secara terpisah memerlukan tanda tangan DKIM yang sah dan melarang ketergantungan hanya pada SPF ; keberhasilan tingkat pesan tidak mengabaikan tugas penerapan tersebut. Kartu autentikasi tidak mengesahkan permintaan bisnis atau memastikan penempatan kotak masuk.
Jelaskan perbedaan yang dimaksudkan
Sebutkan RRset sebelum dan sesudah yang tepat dan nama yang terpengaruh. Jelaskan mengapa perubahan diperlukan saat ini, layanan mana yang telah diuji, dan bukti mana yang masih belum lengkap. Simpan pengeditan DNS yang tidak terkait di luar permintaan sehingga pemberi persetujuan tidak secara tidak sengaja menyetujui operasi yang lebih luas. Identifikasi pelaksana teknis, pemberi persetujuan bisnis, dan kontak eskalasi.
Jika tujuan pelaporan atau layanan yang didelegasikan berubah, nilai aliran informasi dan ketergantungan secara terpisah. Pertahankan konfigurasi pengambilan laporan yang diperlukan untuk pemantauan yang dimaksudkan. Laporan agregat merupakan pengamatan penerima dengan batasan cakupan, sehingga tidak dapat menjadi satu-satunya sinyal penerimaan untuk aliran sah yang mempunyai waktu kritis. RFC 9990.
Tulis kriteria penerimaan yang dapat diamati
Gunakan kriteria yang bisa gagal: RRset otoritatif sama dengan nilai yang disetujui; pesan kritis yang representatif menggunakan identitas yang dimaksudkan dan diautentikasi seperti yang diharapkan; penerima bisnis mengonfirmasi hasil yang diharapkan; dan laporan asupan berlanjut. Catat waktu observasi dan bedakan tes yang segera tersedia dari tinjauan laporan selanjutnya. Laporan yang belum sampai bukan merupakan ujian yang lulus.
Tentukan pemicu pemulihan sebelum implementasi. Jika aliran kritis gagal dan diagnosis menghubungkannya dengan perubahan yang disetujui, aktifkan rencana pemulihan yang disetujui. Pertahankan keadaan lama dan jelaskan keterbatasannya. Memulihkan kebijakan tidak serta merta membalikkan cache DNS atau mengingat kembali pesan yang sudah ditolak. Rencanakan observasi di luar jangka waktu pemeliharaan nominal.
Uji apakah permintaan benar-benar dapat ditutup
Misalkan permintaan hipotetis hanya mengubah kebijakan untuk domain penggajian Dari p=none ke p=quarantine sambil tetap mempertahankan tujuan pelaporan dan TTLnya. Peninjauan tersebut masih harus mengikat baseline lengkap dan RRset yang diusulkan, akun dan domain target, cakupan penggajian yang disetujui, dan rencana pemulihan. Tidak ada payload nyata, persetujuan atau perubahan DNS yang diberikan di sini.
Asumsikan observasi pasca-perubahan yang diotorisasi cocok dengan status DNS yang disetujui dan pesan penggajian yang representatif diautentikasi seperti yang diharapkan, namun penerima bisnis belum mengonfirmasi penerimaan dan laporan agregat berikutnya belum tersedia. Catat konfigurasi dan pemeriksaan autentikasi secara terpisah dari hasil yang tertunda tersebut. Menetapkan tindak lanjut tanda terima kepada pemilik penggajian dan peninjauan penerimaan tertunda kepada pemilik pelapor; jangan menutup semua kriteria penerimaan berdasarkan kekuatan catatan yang cocok. Ini adalah temuan hipotetis, bukan pemeriksaan yang dilaksanakan.
Alur kerja perubahan di atas merupakan rekomendasi operasional, bukan persyaratan protokol. NIST SP 800-53 Rev. 5 mengontrol CM-3 dan CM-5 memberikan dasar umum untuk meninjau, menyetujui dan membatasi perubahan; pengikatan muatan, peran, dan bidang handoff yang tepat di sini adalah implementasi yang diusulkan. Katalog kontrol NIST.