Pengecualian lama adalah kandidat peninjau, bukan bukti otomatis bahwa izinnya dapat dihapus. Tetapkan apa yang awalnya diperlukan, apakah kebutuhan tersebut masih ada, dan bagaimana layanan yang terpengaruh akan bekerja setelahnya. Pensiun harus mengurangi wewenang yang tidak perlu tanpa menimbulkan insiden pengiriman baru.
Pulihkan alasan aslinya
Baca cakupan pengecualian, pemilik, persetujuan, dan pengujian penutupan yang dimaksudkan. Tentukan apakah ini menyangkut sebuah SPF mekanisme, a DKIM delegasi, DMARC kebijakan, aturan gateway, atau pengecualian pelaporan. Ini mempunyai efek yang berbeda-beda. Pihak ketiga pemilih DKIM dan penyertaan SPF bukanlah cara yang dapat dipertukarkan untuk memberikan wewenang. RFC 6376 , manajemen kunci Dan RFC 7208.
Jika alasan aslinya tidak ada, beri label tidak diketahui dan tugaskan penyelidik. Jangan menciptakan pembenaran bisnis dari nama penyedia yang sudah dikenal. Konfirmasikan layanan pelanggan dan penyewa yang sebenarnya, bukan hanya merek infrastruktur. Pertahankan ketergantungan kontrak atau operasional apa pun untuk ditinjau oleh pemilik yang bertanggung jawab.
Uji keadaan akhir yang diusulkan
Identifikasi rute penggantian dan latih aliran yang representatif berdasarkan rencana pengujian resmi. Catat identitas autentikasi, hasil tepercaya, dan tanda terima bisnis jika relevan. Periksa penggunaan musiman dan volume rendah dengan kalender bisnis. Periode tenang yang singkat mungkin melewatkan kampanye triwulanan atau pemberitahuan pemulihan bencana.
Menggunakan laporan agregat sebagai satu sumber observasi, dengan log pengirim dan konfirmasi pemilik yang sesuai. Laporan tidak mencakup setiap penerima atau membuktikan suatu layanan tidak aktif. RFC 9990. Dokumentasikan interval pengamatan dan kesenjangannya. Tidak adanya bukti harus tetap berbeda dari bukti tidak digunakan.
Bedakan kesiapan dari izin untuk menghapus
Pertimbangkan tiga pengecualian hipotetis. EX-01 memiliki pemilik yang terkonfirmasi, rute pengganti yang terverifikasi, dan peninjauan terdokumentasi atas rute lama di seluruh siklus bisnis yang relevan; itu adalah kandidat untuk persetujuan perubahan. EX-02 tidak memiliki pemilik saat ini dan hanya memiliki jendela pelaporan singkat, sehingga atribusi dan cakupan tetap terbuka. EX-03 masih menjalankan kampanye terjadwal, jadi menghapusnya sebelum penggantinya diuji dapat mengganggu penggunaan yang sah.
Ini hanyalah masukan yang diasumsikan untuk pengambilan keputusan, bukan model pensiun yang dilaksanakan atau bukti verifikasi nyata. Bahkan EX-01 tidak dihapus secara otomatis: ketergantungan sebenarnya, penggunaan bersama, status saat ini, dan persetujuan harus diperiksa. Pernyataan bahwa bukti sudah lengkap harus menyebutkan layanan yang tercakup dan interval waktu, bukan menyiratkan visibilitas universal.
Hapus hanya ketergantungan yang disetujui
Siapkan rencana perubahan dan pemulihan yang tepat sebelum dan sesudah. Periksa kembali keadaan saat ini sebelum mutasi. Jika cakupannya mencakup DNS , validasi pengamatan resmi setelahnya dan uji aliran sah yang terpengaruh. Jawaban yang disimpan dalam cache dapat tetap ada, sehingga periode verifikasi harus sesuai dengan ketergantungan sebenarnya. RFC 1035.
Tutup pengecualian hanya jika penghapusan yang disetujui dan hasil layanan yang relevan dicatat. Pertahankan cakupan sebelumnya, mengapa pensiun dapat dibenarkan dan risiko apa pun yang tersisa. Jika suatu ketergantungan belum dapat dihilangkan, perbarui hanya dengan keputusan yang dapat dipertanggungjawabkan dan tindakan konkrit selanjutnya. Pembaruan yang dilakukan berulang-ulang tanpa adanya bukti baru hanyalah temuan tata kelola, bukan kemajuan.
Verifikasi pensiun sebelum menutup catatan
Setelah penghapusan disetujui, simpan objek yang diubah secara persis dan verifikasi hilangnya otoritas dan kesinambungan yang sah. Jika salah satunya tidak pasti, biarkan penutupan tertunda dengan nama cek berikutnya daripada menghapus riwayat pengecualian.