Sistem email dapat melaporkan SPF lulus dan DKIM lewati sementara DMARC masih gagal. Hasil tersebut tidak bertentangan. Setiap mekanisme dimulai dengan identitas yang berbeda, dan DMARC menambahkan tes hubungan antara identitas yang lewat dan domain di alamat Dari pesan.
Cara yang dapat diandalkan untuk menyelidiki pesan adalah dengan mencatat rantai identitas sebelum mengubah DNS . Mulailah dengan domain yang dilihat penerima di Dari. Kemudian catat domain yang digunakan untuk SPF dan setiap domain yang ditemukan di a tanda tangan DKIM. Baru setelah itu Anda harus menilai penyelarasan dan hasil DMARC tingkat pesan.
Sebutkan ketiga identitas tersebut sebelum membaca hasilnya
Pertimbangkan pesan fiksi ini:
Dari: Tim Penagihan < statements@billing.example.com > Return-Path : < bounce+739@mailer.example.net > DKIM-Signature : ... d=billing.example.com; s=outbound1; ...Domain Dari adalah billing.example.com. DMARC menyebutnya Domain Penulis. Itu pengirim amplop diwakili di sini oleh Return-Path domain mailer.example.net; untuk pemeriksaan MAIL FROM dari pesan biasa ini, itulah identitas yang dievaluasi SPF RFC 7208 §2.4. Terpisah HELO pemeriksaan juga dapat terjadi di bawah RFC 7208 §2.3; Penanganan Return-Path ditentukan dalam RFC 5321 §4.4. Domain penandatanganan DKIM adalah nilai d=, yang billing.example.com dalam contoh ini.
Nama tampilan seperti Tim Penagihan bukan merupakan identitas autentikasi. Reply-To juga bukan Domain Penulis. Bidang tersebut penting dalam penyelidikan penipuan, namun bidang tersebut tidak menggantikan domain yang dibandingkan dengan DMARC .
Catat hasil dan penyelarasan secara terpisah
Lulus SPF mentah berarti sumber penghubung diberi otorisasi untuk identitas SPF yang dievaluasi. Kartu DKIM mentah berarti tanda tangan yang diverifikasi d= domain dan materi pesan yang dicakup. Tidak ada hasil yang menyatakan bahwa domainnya memiliki hubungan yang diperlukan dengan Dari.
Oleh karena itu DMARC memerlukan dua kolom untuk setiap jalur:
- Jalur: SPF ; Pertanyaan autentikasi: Apakah SPF lolos untuk identitas amplop yang dievaluasi?; Pertanyaan penyelarasan: Apakah identitas tersebut selaras dengan Domain Penulis?
- Jalur: DKIM ; Pertanyaan autentikasi: Apakah tanda tangan ini lolos untuk domain d=-nya?; Pertanyaan penyelarasan: Apakah domain d= tersebut selaras dengan Domain Penulis?
Di bawah RFC 9989 §3.2.10.2, penyelarasan yang ketat memerlukan kesetaraan domain yang tepat. Di bawah RFC 9989 §4.10.2, penyelarasan santai menggunakan hubungan penemuan domain organisasi yang berlaku. Jangan memperkirakan batas tersebut dengan mengambil dua label terakhir, karena aturan sufiks publik dapat membuat pintasan tersebut salah.
Selesaikan umpan dan umpan mentah yang menyesatkan
Berikut ini adalah contoh pengajaran sintetik, bukan pesan pelanggan. Asumsikan kebijakan valid yang berlaku, pemeriksaan yang telah selesai, hasil penerimaan yang tepercaya, dan mode penyelarasan yang diketahui; RFC 9989 §5.3.5 mendefinisikan aturan lulus/gagal yang dihasilkan.
- Pengamatan: Dari; Pesan A: alerts@example.com ; Pesan B: alerts@example.com
- Pengamatan: hasil SPF ; Pesan A: Lulus untuk bounce.vendor.example.net ; Pesan B: Lulus untuk bounce.vendor.example.net
- Pengamatan: SPF selaras?; Pesan A: Tidak; Pesan B: Tidak
- Observasi: Hasil DKIM ; Pesan A: Lulus dengan d=example.com; Pesan B: Lulus dengan d=vendor.example.net
- Pengamatan: DKIM selaras?; Pesan A: Ya; Pesan B: Tidak
- Pengamatan: DMARC tingkat pesan ; Pesan A: Lewati DKIM ; Pesan B: Gagal
Pesan A lolos DMARC karena satu tanda tangan DKIM memverifikasi dan menyelaraskan. Hasil SPF yang tidak selaras tidak membatalkan jalur valid tersebut. Pesan B memiliki dua jalur autentikasi mentah, namun tidak ada domain yang diautentikasi yang selaras dengan Domain Penulis, sehingga tidak ada jalur DMARC yang lewat.
Tabel ini juga merupakan catatan perubahan yang berguna. Ini menunjukkan apakah perbaikan termasuk dalam identitas amplop, konfigurasi penandatanganan, atau domain Dari yang terlihat. Ikon hijau tanpa domain ini tidak cukup sebagai bukti untuk mengizinkan perubahan DNS .
Periksa setiap tanda tangan DKIM
Sebuah pesan dapat membawa lebih dari satu tanda tangan DKIM . Layanan keluar, gateway, dan perantara masing-masing dapat menambahkan satu layanan. Evaluasi setiap tanda tangan secara mandiri. Satu tanda tangan yang diselaraskan dapat memberikan jalur DKIM meskipun tanda tangan lainnya tidak selaras atau gagal.
Jangan menyimpulkan pemilih dari nama penyedia. Baca s= nilai dari header DKIM-Signature yang sebenarnya, gabungkan dengan tanda tangan tersebut d= domain, dan kueri nama DNS yang dihasilkan di bawah RFC 6376 §3.6.2.1. Menerbitkan kunci hanya membuat materi verifikasi tersedia. Sistem pengirim masih harus membuat tanda tangan yang valid dengan kunci privat yang sesuai.
Surat tidak langsung dapat mengubah konten yang ditandatangani atau jalur amplop. Oleh karena itu, penerusan dapat mempengaruhi SPF , sedangkan perubahan daftar dapat mempengaruhi DKIM . Perlakukan jalur yang diamati sebagai bukti untuk diselidiki, bukan bukti bahwa pengirim atau perantara asli adalah orang yang jahat.
Gunakan bukti penerimaan yang tepercaya
Authentication-Results dapat merangkum identitas dan hasil, tetapi kepercayaan bergantung pada di mana header ditambahkan. Pengirim dapat memasukkan header yang mengklaim berhasil. Di bawah RFC 8601 §7.1, gunakan hasil yang dihasilkan oleh sistem penerima yang Anda kelola, atau batasan lain yang penanganannya Anda pahami.
Jika pesan ditolak sebelum dikirimkan, salinan yang dikirimkan mungkin tidak ada. Gunakan respons penolakan, log penyedia, dan telemetri penerima apa pun yang tersedia. Jangan menciptakan identitas yang hilang hanya dari kode kesalahan.
Ubah rantai identitas menjadi catatan operasional
Untuk setiap pengirim materi, simpan:
- pemilik bisnis dan aplikasinya;
- domain Dari yang diizinkan untuk digunakan;
- identitas amplop yang diamati;
- setiap DKIM yang diamati d= domain dan pemilih;
- hasil otentikasi untuk setiap jalur;
- mode penyelarasan dan kesimpulan;
- tanggal tes yang representatif dan pengidentifikasi pesan.
Catatan itu memisahkan otorisasi bisnis dari bukti protokol. Hal ini juga mencegah kesalahan umum: mengubah akar organisasi Catatan SPF untuk mengatasi masalah penyelarasan DKIM , atau mengubah kebijakan DMARC ketika konfigurasi pengirim merupakan cacat sebenarnya.
Setelah rantai identitas jelas, gunakan panduan pemecahan masalah penyelarasan untuk memperbaiki jalur yang gagal dan inventaris pengirim untuk menetapkan kepemilikan.
Pertahankan kesimpulan dalam bukti
Untuk pesan A, tulis SPF pass/unaligned dan DKIM pass/aligned sebagai fakta terpisah. Untuk B, jangan ubah dua pass mentah yang tidak terkait menjadi pass DMARC . Simpan setiap tanda tangan secara independen dan jangan menyimpulkan identitas SMTP hanya dari nama tampilan. Kasus-kasus ini dan tanda tangan yang disingkat adalah contoh pengajaran, bukan materi tanda tangan yang sah atau verifikasi yang dilakukan.