Menambahkan satu detik DMARC kebijakan bukanlah cara untuk memperbarui yang pertama. Kedua nilai tersebut tidak menjadi instruksi gabungan, dan DNS tidak menyediakan aturan “kemenangan kebijakan terbaru” yang diurutkan untuk keduanya.
Perbaikan dimulai dengan penyelesaian catatan TXT ditetapkan pada nama yang terpengaruh. Identifikasi berapa banyak kandidat kebijakan versi saat ini yang ada, bedakan batasannya dari format tampilan, dan rekonsiliasi kebijakan yang diinginkan pemilik sebelum mengedit.
Periksa pemilik DNS yang sebenarnya
Mulai dari domain di alamat Dari pesan. Kueri nama _dmarc yang berlaku dan catat jawaban rekursif yang otoritatif dan relevan dengan stempel waktu.
Kebijakan domain root dan kebijakan subdomain eksplisit diterbitkan dengan nama berbeda. Mereka bukan duplikat hanya karena keduanya ada. Hubungan mereka diatur oleh penemuan dan ruang lingkup. Panduan kebijakan subdomain menjelaskan bagaimana menilai hubungan itu.
Demikian pula, kebijakan TXT pada akar domain bukanlah pengganti nama _dmarc yang relevan. Perbaiki pemilik yang dituju daripada menambahkan catatan di beberapa tempat dan berharap penerima memilih salah satu.
Membedakan rekaman dari string karakternya
Satu data sumber daya TXT dapat berisi lebih dari satu string karakter. DMARC menggabungkan string-string tersebut secara berurutan sebelum diurai RFC 9989 §4.5. Tanda kutip yang ditampilkan di sekitar string biasanya merupakan representasi alat pencarian.
Perlengkapan bergaya zona sintetis ini adalah salah satu rekor TXT :
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; " "rua=mailto:reports@example.com"Nilai gabungannya berisi pemisah dan spasi antara tag p dan rua karena karakter tersebut disertakan di dalam string. Resolver tidak menemukan pemisah yang hilang saat ia menggabungkannya.
Sebaliknya, dua data sumber daya TXT yang terpisah adalah dua data. Jangan menggabungkannya dalam spreadsheet atau catatan kejadian dan kemudian menganalisis nilai yang ditemukan tersebut.
Filter sebelum menghitung kandidat kebijakan
Itu RFC 9989 §4.10 Jalan pohon DNS membuang catatan yang tidak dimulai dengan tag v yang mengidentifikasi versi saat ini. Jika beberapa data kebijakan DMARC dikembalikan pada satu target, semua data kebijakan tersebut akan dibuang pada target tersebut.
Oleh karena itu, nilai TXT yang tidak terkait dengan nama yang sama tidak otomatis menjadi kebijakan DMARC kedua. Hitung kandidat yang relevan setelah menyimpan setiap catatan asli dan menerapkan pemfilteran yang ditentukan.
Berikut ini adalah perlengkapan sintetis, bukan hasil pencarian langsung:
- Rekor ditetapkan pada satu target: Satu kandidat DMARC versi saat ini; Interpretasi untuk diselidiki: Parsing kandidat tersebut dan semantik kebijakannya
- Rekor ditetapkan pada satu target: Satu kandidat DMARC ditambah TXT deskriptif yang tidak terkait; Interpretasi untuk diselidiki: TXT yang tidak terkait bukanlah kandidat kebijakan DMARC kedua
- Catatan ditetapkan pada satu target: Dua catatan terpisah dimulai dengan v=DMARC1; Interpretasi untuk diselidiki: Kandidat kebijakan yang bersaing; tidak ada penggabungan atau pemilihan rekaman terakhir
- Kumpulan rekaman pada satu target: Satu rekaman terbuat dari dua string karakter; Interpretasi untuk diselidiki: Gabungkan stringnya secara berurutan, lalu parsing
Di bawah RFC 9989 §4.7, tag versi harus muncul terlebih dahulu dengan nilai persis DMARC1 . String yang hanya menyebutkan teks tersebut di kemudian hari bukanlah pengganti identifikasi rekaman yang ditentukan.
Telusuri konsekuensinya daripada menjanjikan satu label kesalahan
Beberapa kandidat kebijakan pada pencarian awal tidak dapat meninggalkan kebijakan yang valid pada nama tersebut. Di bawah RFC 9989 §4.10.1, penemuan saat ini kemudian dapat dilanjutkan melalui penelusuran pohon DNS yang berlaku. Kebijakan yang dapat digunakan di tempat lain dapat memengaruhi pesan tersebut.
Misalnya, dalam perlengkapan subdomain fiksi, dua kandidat di _dmarc.alerts.example.com dibuang. Jika penemuan kemudian menemukan kebijakan valid yang berlaku di suatu domain organisasi, kebijakan itu dapat diterapkan. Jika penemuan lengkap tidak menemukan apa pun, DMARC tidak berlaku untuk pesan tersebut.
Jangan berjanji bahwa setiap duplikat menghasilkan hal yang sama Authentication-Results label atau respons SMTP di seluruh implementasi. Pertahankan hasil aktual penerima dan jalur penemuan yang dapat diterapkan.
Rekonsiliasi satu kebijakan yang disetujui sebelum mengubah DNS
Tentukan nilai mana yang disengaja. Dua catatan mungkin dibuat oleh tim yang berbeda, melalui integrasi pelaporan lama, atau melalui migrasi yang menambahkan, bukan mengganti data.
Bangun satu nilai yang koheren dan disetujui. Pertahankan tujuan dan tinjauan laporan yang diinginkan penyelarasan, cakupan subdomain, dan pengaturan pengujian. Jika beberapa penerima gabungan diotorisasi, daftar tujuan rua yang dipisahkan koma ditentukan dalam RFC 9989 §4.7 dalam satu polis dapat mengungkapkan permintaan tersebut; itu tidak memerlukan beberapa data TXT kebijakan.
Verifikasi izin pelaporan eksternal yang diperlukan secara terpisah di bawah RFC 9990 §4. Menggabungkan alamat tujuan tidak memberikan izin pada tujuan yang tidak Anda kendalikan.
Buat dan verifikasi koreksinya
Simpan status sebelum, lengkapi status setelah disetujui, nama pemilik, TTL, dan otorisasi perubahan. Gantikan kandidat yang bersaing dengan kebijakan tunggal yang dimaksudkan pada nama tersebut.
Kemudian periksa server otoritatif untuk kumpulan data baru dan periksa tampilan rekursif yang relevan. Nilai-nilai yang disimpan dalam cache sebelumnya mungkin tetap ada untuk sementara waktu, jadi satu jawaban resmi saat ini bukanlah bukti bahwa setiap penerima telah membuang kumpulan yang lama.
Jalankan pengujian pesan yang representatif dan periksa hasil autentikasi dan kebijakannya yang tepercaya. Koreksi DNS menetapkan ketergantungan konfigurasi yang valid; itu tidak membuat tidak berhubungan tanda tangan DKIM menyelaraskan atau memperbaiki identitas amplop lamaran.
Menggunakan alur kerja rekaman untuk menghubungkan publikasi dan verifikasi pesan.
Cegah konflik yang sama pada integrasi berikutnya
Berikan domain tersebut pemilik kebijakan dan minta integrasi untuk mengusulkan perbedaan pada catatan yang ada daripada menambahkan kebijakan lain secara membabi buta. Pertahankan tujuan bisnis dan siklus hidup setiap tujuan pelaporan.
Nama serah terima migrasi yang berguna yang menghapus konfigurasi usang dan yang memverifikasi kumpulan data yang dihasilkan. Perbaikan yang tahan lama adalah satu kebijakan yang disengaja pada setiap nama yang relevan, dengan pemahaman penemuan, pelaporan, dan perilaku email sebenarnya.
Pisahkan keputusan dan bukti
Untuk perlengkapan string terpisah, string pertama diakhiri dengan titik koma dan spasi, jadi menggabungkannya dengan rua menghasilkan satu nilai koheren. Dua rekaman terpisah tetap menjadi dua kandidat, apa pun urutan tampilannya. Jaga agar hasil penemuan lengkap berbeda dari cacat satu nama. RFC 8767 §4 juga berarti masa berlaku TTL bukan merupakan jaminan tenggat waktu penghapusan global untuk data cache. Perlengkapan tersebut tidak dipublikasikan atau ditanyakan.