Pemeriksa DNS dapat menjawab pertanyaan konfigurasi yang berguna dengan cepat. Ini dapat menunjukkan apakah ia menemukan a catatan DMARC pada nama tertentu, jelaskan kebijakan yang dipilihnya dan identifikasi sintaksis atau temuan pencarian. Ini adalah bukti yang berharga, namun cakupannya bergantung pada apa yang ditanyakan dan bagaimana mereka menafsirkan tanggapannya.
Hasil hijau bukanlah pesan yang ditangkap, inventaris pengirim, atau jaminan bahwa setiap penerima akan menerima surat yang sah. Langkah selanjutnya adalah menghubungkan konfigurasi yang diamati ke layanan bisnis dan identitas sebenarnya yang sedang diselidiki.
Tanyakan apa yang ditanyakan
Mulailah dengan domain yang dimasukkan ke dalam alat dan nama DNS sebenarnya yang ditanyakan. Untuk sebuah pesan, domain Dari yang terlihat adalah identitas awal DMARC penemuan kebijakan di bawah RFC 9989 §4.10.1. Memeriksa domain situs web terkait tidak sama ketika aplikasi mengirim dari nama yang berbeda.
Simpan waktu pencarian, penyelesai, respons, dan catatan yang dipilih. Jika alat mengikuti arus RFC 9989 penemuannya, mintalah untuk menunjukkan bukti perjalanan di pohon yang relevan. Jika ia mengimplementasikan model lain, catat model tersebut daripada berasumsi bahwa setiap pemeriksa menggunakan algoritma yang sama.
Investigasi tanpa catatan membantu memisahkan nama host yang salah dari ketidakhadiran sebenarnya di lokasi yang relevan. Kebijakan dapat ditemukan melalui aturan induk atau sufiks yang berlaku meskipun tidak ada catatan langsung pada nama yang dimasukkan.
Baca batas rekaman dengan benar
Di bawah RFC 9989 §4.5, a catatan TXT dapat berisi beberapa string karakter yang digabungkan DMARC secara berurutan sebelum diurai. Hal ini berbeda dengan beberapa data TXT terpisah yang masing-masing mengklaim sebagai kebijakan DMARC . Oleh karena itu, tampilan yang menggabungkan nilai panjang atau memperlihatkan beberapa fragmen yang dikutip dapat menyesatkan kecuali jika mempertahankan batas rekaman.
Pemeriksa harus membedakan data TXT yang tidak terkait dari kandidat kebijakan DMARC dan menjelaskan data apa yang dibuang. Masalah kumpulan catatan tidak diperbaiki dengan menambahkan catatan kebijakan lain di samping catatan yang sudah ada.
Periksa publikasi resmi dan tampilan penyelesai saat menyelidiki perubahan. Caching dan tanggapan negatif dapat menjelaskan pengamatan yang berbeda pada waktu yang berbeda. Batas waktu atau kesalahan DNS bukanlah temuan yang sama dengan jawaban berhasil yang tidak menunjukkan kebijakan.
Gunakan tabel bukti dengan hal-hal yang tidak diketahui secara eksplisit
Berikut ini adalah model keluaran asli untuk alat diagnostik hipotetis. Ini adalah contoh sintetik tentang cara memberi label pada bukti, bukan laporan dari domain aktif.
- Pertanyaan: Apakah kebijakan terlihat pada nama yang ditanyakan?; Alat yang hanya menemukan DNS ini mungkin menghasilkan: Data TXT yang dikembalikan secara tepat dan status pencarian; Bukti tambahan diperlukan: Pengamatan penyelesai relevan lainnya ketika penentuan waktu menjadi penting
- Pertanyaan: Kebijakan manakah yang dipilih dalam implementasi ini?; Alat yang hanya menemukan DNS ini mungkin dapat menetapkan: Jejak penemuan dan catatan yang dipilih; Bukti tambahan diperlukan: Implementasi penerima dan data untuk pesan tertentu
- Pertanyaan: Apakah nilainya valid secara sintaksis?; Alat yang hanya menemukan DNS mungkin akan menghasilkan: Hasil penguraian di bawah spesifikasi yang disebutkan; Bukti tambahan diperlukan: Validasi pesan aktual dan konfigurasi layanan
- Pertanyaan: Apakah tujuan laporan yang diminta diperbolehkan?; Alat yang hanya menemukan DNS mungkin menghasilkan: Hasil pencarian izin eksternal yang relevan; Bukti tambahan yang diperlukan: Pengiriman surat, penanganan lampiran, penguraian, dan peninjauan laporan
- Pertanyaan: Apakah a DKIM kunci yang dapat diambil untuk input pemilih?; Alat yang hanya menemukan DNS ini mungkin menghasilkan: Hasil pencarian kunci publik untuk d dan s yang disediakan; Bukti tambahan diperlukan: Penandatanganan aktif dan verifikasi tanda tangan pada pesan nyata
- Pertanyaan: Apakah semua email sah diautentikasi?; Pencarian khusus DNS yang mungkin dilakukan oleh alat ini: Tidak ditetapkan; Bukti tambahan yang diperlukan: Inventaris pengirim yang dimiliki dan bukti rute yang representatif
Alat yang jujur dapat yakin dengan kueri yang dijalankannya sambil membiarkan pertanyaan terakhir belum terselesaikan. Ini adalah informasi diagnostik yang lebih baik daripada label luas yang “dilindungi sepenuhnya” tanpa populasi bukti yang jelas.
Jangan menyimpulkan pengiriman aktif dari kunci yang dipublikasikan
Di bawah RFC 6376 §3.6.2.1 Dan RFC 6376 §6, kunci DKIM yang dipublikasikan adalah bahan verifikasi. Ini tidak menunjukkan bahwa layanan produksi memiliki kunci pribadi yang cocok, mengaktifkan penandatanganan, atau menggunakan kombinasi d dan s tersebut. Tanpa konfigurasi pesan atau penyedia, alat juga tidak dapat berasumsi bahwa satu pemilih yang ditebak mewakili setiap kunci yang digunakan.
Di bawah RFC 7208 §4.1, SPF Evaluasi DNS dapat menjelaskan kebijakan yang terkait dengan identitas amplop yang dipilih dan dependensi yang dilihatnya saat ini. Ia tidak dapat mengidentifikasi setiap layanan yang sah atau membuktikan sumber dan identitas sampul mana yang dilihat penerima selama transaksi sebelumnya.
Menggunakan panduan pemilih DKIM Dan panduan rantai identitas untuk mendapatkan identitas pesan sebenarnya sebelum mencocokkan DNS dengan pengirim.
Perlakukan pelaporan sebagai jalur lengkap lainnya
Alamat rua dalam kebijakan yang valid adalah permintaan pelaporan. Di bawah RFC 9990 §4, DNS dapat membantu menetapkan izin yang diperlukan untuk tujuan eksternal, namun tidak dapat membuktikan bahwa pesan tiba, lampiran terkompresi bertahan dalam pemfilteran, parser menerimanya, atau seseorang menyelidiki temuan.
Untuk penerapan nyata, verifikasi pengumpulan secara terpisah dan simpan informasi reporter dan periode dengan observasi. Struktur dan penyampaian laporan dijelaskan dalam RFC 9990 §3.1 Dan RFC 9990 §3.5. Laporan dari salah satu penerima yang berpartisipasi merupakan bukti yang berguna untuk sumber data tersebut, bukan bukti cakupan surat terkirim secara lengkap. Panduan pengumpulan pelaporan menelusuri jalur operasional itu.
Ubah cek menjadi keputusan layanan
Misalkan pemeriksa menemukan kebijakan terpantau yang valid sementara aplikasi tanda terima menggunakan domain penandatanganan penyedia yang tidak terkait. Temuan DNS mungkin benar dan pesan aplikasi masih kurang jalur yang selaras. Memperbaiki konfigurasi layanan sebenarnya memerlukan penyelidikan pesan atau rute yang diterima, bukan publikasi kebijakan serupa lainnya.
Sebaliknya, koreksi yang baru diterbitkan mungkin terlihat secara resmi sebelum cache negatif penyelesai lain kedaluwarsa RFC 2308 §5. Pertahankan pengamatan dan stempel waktu. Jangan terus-terusan mengedit rekaman yang benar hanya untuk memaksa persetujuan langsung antara tampilan yang di-cache.
Handoff yang berguna memasangkan laporan DNS dengan layanan yang tepat, identitas pesan, pemilik pengirim, dan pengujian berikutnya. Jaga agar fakta yang diamati, asumsi implementasi, dan pertanyaan pesan yang belum terselesaikan tetap terlihat. Hal ini mengubah hasil pemeriksa menjadi langkah diagnostik yang dapat direproduksi, bukan klaim jaminan yang tidak didukung.
Buatlah keputusan berikutnya secara eksplisit
Sebuah alat dapat dengan jujur mencatat “kebijakan ditemukan pada nama yang ditanyakan; tidak ada pesan yang diberikan.” Tetap aktifkan penandatanganan DKIM , selaraskan keberhasilan alur kerja, dan tanda terima pelaporan sebagai temuan terpisah yang tertunda. Untuk perubahan yang sensitif terhadap cache, RFC 8767 §4 mengizinkan penggunaan jawaban basi yang memenuhi syarat setelah habis masa berlakunya, sehingga TTL bukanlah jaminan konvergensi global. Artikel ini menjelaskan bukti yang harus dikumpulkan, bukan pemeriksaan yang dilakukan untuk domain aktif.