Sebuah hilir DMARC pass tidak menetapkan bahwa orang yang memulai pesan diberi wewenang untuk menggunakan pengirimnya yang terlihat. Penelitian LaunDroMARC bulan Desember 2025 dari Engage Security menjelaskan rute tidak langsung di mana pengiriman email mengubah identitas yang dievaluasi oleh SPF. Pahami lompatan individual sebelum mendeskripsikan temuan sebagai bypass DMARC universal atau asumsikan bahwa setiap penyewa Microsoft berperilaku sama saat ini.
Pisahkan kedua sumber bukti tersebut
Peneliti asli menjelaskan pesan masuk yang melewati SPF untuk domain amplopnya sendiri namun gagal DMARC terhadap domain Dari yang terlihat ditiru. Dalam kasus yang dilaporkan, jalur penerusan Microsoft 365 menulis ulang amplop ke dalam domain penerusan, yang juga cocok dengan domain Dari yang terlihat. Penerima akhir kemudian mengamati SPF yang selaras. Para peneliti melaporkan perlakuan berbeda terhadap salinan asli dan salinan yang diteruskan. Hal ini merupakan temuan yang diatribusikan dari penyelidikan mereka, bukan observasi yang dilakukan untuk tinjauan ini. Libatkan penelitian Keamanan.
Dokumentasi Microsoft menjelaskan hal itu SRS perubahan KIRIM DARI, bukan bidang Dari yang terlihat, dan memberikan pola penulisan ulang untuk rute penerusan yang dapat diterapkan. Ini juga memperingatkan bahwa SRS biasanya tidak menyelesaikan DMARC penyelarasan untuk surat yang diteruskan. Pernyataan tersebut sesuai dengan kebetulan identitas khusus penelitian: biasanya domain Dari asli berbeda dengan domain penerus; kasus yang dilaporkan sengaja melibatkan domain yang sama. Dokumentasi Microsoft SRS.
Pahami putusan hilirnya
Referensi: RFC 9989 §4.4, RFC 8601 §5.
SPF menanyakan apakah host penghubung diberi otorisasi untuk identitas amplop pada hop tersebut. DMARC membandingkan domain yang diautentikasi dengan domain Dari yang terlihat. Tidak ada hasil yang merekonstruksi bagaimana aktor asli memperoleh akses ke alur kerja penerusan. Oleh karena itu, hasil yang selaras di bagian hilir mungkin benar untuk identitas yang dievaluasi namun masih belum cukup menjadi bukti otorisasi bisnis.
Jangan menafsirkan tampilan SRS Return-Path sebagai bukti bahwa Microsoft memproduksinya. Pertahankan hasil terpercaya penerima akhir, informasi rekan dan jejak pesan, dan bandingkan bukti dari batas penerimaan dan penerusan. Disematkan secara sewenang-wenang Authentication-Results teks bukanlah putusan yang dapat dipercaya. RFC 8601 menjelaskan persyaratan batas kepercayaan; RFC 9989 menyediakan konteks penyelarasan domain.
Hanya mereproduksi perbandingan identitas
Model non-pengiriman paket tinjauan pribadi berisi dua kasus fiktif. Dalam kasus normal, domain author.test asli yang terlihat berbeda dari amplop forwarder.test yang ditulis ulang, sehingga diasumsikan pass SPF hilir tetap tidak selaras. Dalam kasus kedua, domain yang terlihat adalah forwarder.test; amplop yang ditulis ulang sama sekarang sejajar. Keduanya dimulai dengan domain amplop asli yang berbeda dan tidak selaras DKIM.
Input perlengkapan yang dipertahankan dihitung ulang secara offline pada tanggal 8 November 2026 menggunakan perbandingan domain yang tepat ini. Itu tidak mengirim email palsu, membuat aturan penerusan, menjalankan Exchange Online , menerapkan hash SRS, atau membuktikan bahwa penyewa saat ini menerima rute tersebut. Tujuannya adalah untuk menjelaskan mengapa kedua putusan tersebut berbeda tanpa mereproduksi serangan terhadap layanan sebenarnya. Perilaku vendor historis, perilaku penyewa saat ini, dan perbandingan abstrak tetap diberi label terpisah.
Selidiki secara defensif
Penerusan eksternal resmi inventaris dan pemilik bisnisnya. Untuk dugaan insiden, simpan salinan asli dan yang diteruskan, stempel waktu, metode perutean, autentikasi pra-penerusan, dan hasil akhir. Tinjau dokumentasi penyedia saat ini dan penelusuran pesan sebelum mengubah aturan. Sumber Microsoft membedakan penerusan yang berlaku dari kumpulan relai dan kasus lokal, sehingga klaim konfigurasi tunggal tidak cukup untuk mencakup setiap jalur.
Terapkan perubahan melalui proses keamanan email yang disetujui organisasi dan uji alur kerja yang sah setelahnya. Hindari aturan izin yang luas hanya berdasarkan infrastruktur penyedia atau hasil izin hilir. Artikel ini menjelaskan mekanisme dan pertanyaan investigasi. Pernyataan ini tidak menyatakan tanggal perbaikan yang belum diverifikasi, paparan universal, eksploitasi yang berhasil, atau kerusakan layanan Microsoft saat ini.