Sebelum memperketat kebijakan DMARC Anda, identifikasi semua sistem yang mengirim email sah menggunakan domain Anda. Laporan dapat mengungkap pengirim yang memerlukan perubahan autentikasi sebelum penegakan memblokir emailnya.
Laporan mana yang sebaiknya Anda gunakan?
Gunakan laporan agregat untuk membandingkan sumber pengiriman dan hasil autentikasi selama periode pelaporan. Alamat rua pada rekaman DMARC Anda meminta ringkasan XML ini dari penerima yang berpartisipasi.
Alamat ruf meminta laporan kegagalan individual, yang terkadang disebut laporan forensik. Laporan ini menggunakan format pelaporan kegagalan autentikasi dan dapat berisi header atau konten pesan. Penerima mungkin menyunting atau tidak mengirimnya karena konten tersebut dapat mengekspos informasi pribadi. Aturan pelaporan RFC 7489 menjelaskan kedua jenis laporan.
Laporan agregat mencakup lalu lintas yang diamati setiap penerima pelapor. Laporan yang tidak ada bukan bukti bahwa tidak ada pesan yang menggunakan domain Anda. Penjelasan rekaman DMARC membahas tempat mengatur alamat pelaporan.
Apa isi laporan agregat?
Laporan agregat mengidentifikasi organisasi pelapor, periode pelaporan, dan kebijakan yang dipublikasikan, diikuti oleh rekaman yang mengelompokkan pesan dengan karakteristik yang sama. Satu IP sumber dapat muncul di beberapa rekaman jika hasil autentikasi atau field pengelompokan lainnya berbeda.
Kutipan ilustratif ini mempertahankan field yang diperlukan untuk membandingkan sumber dengan hasil autentikasinya:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Rekaman ini mewakili 42 pesan dari 203.0.113.10 yang menggunakan example.com di alamat From yang terlihat. Kedua metode autentikasi lolos dan selaras. Penerima tidak menerapkan penegakan DMARC pada pesan tersebut; ini tidak menetapkan penempatan kotak masuknya.
Field mana yang mengidentifikasi masalah autentikasi?
Bandingkan policy_evaluated dengan auth_results untuk membedakan kegagalan autentikasi dari kegagalan keselarasan domain.
| Field | Yang perlu diperiksa |
|---|---|
source_ip | Identifikasi server pengirim dan layanan yang bertanggung jawab. |
count | Hitung pesan yang diwakili rekaman ini, bukan seluruh laporan. |
header_from | Konfirmasi domain yang ditampilkan kepada penerima. |
disposition | Periksa apakah penerima menerapkan none, quarantine, atau reject. |
dkim dan spf di policy_evaluated | Periksa apakah setiap metode lolos dan selaras untuk DMARC. |
auth_results | Bandingkan hasil autentikasi mentah dan domain yang diautentikasi. |
Misalnya, SPF dapat lolos di auth_results tetapi gagal di policy_evaluated jika domain yang diautentikasi tidak selaras dengan domain From. Kelulusan DKIM yang selaras tetap dapat membuat pesan tersebut lolos DMARC. Cara kerja DMARC menjelaskan hubungan tersebut.
Apa yang harus Anda lakukan dengan setiap sumber pengiriman?
Cocokkan setiap sumber dengan layanan yang Anda otorisasi sebelum mengubah kebijakan. Hasil autentikasi saja tidak memberi tahu Anda apakah organisasi Anda memang bermaksud mengizinkan layanan tersebut mengirim.
- Untuk pengirim yang dikenal dan lolos serta selaras, konfirmasi bahwa volume yang dilaporkan sesuai dengan lalu lintas yang Anda harapkan.
- Untuk pengirim yang dikenal tetapi gagal, perbaiki autentikasi atau keselarasannya dan periksa laporan berikutnya untuk hasilnya.
- Untuk pengirim yang tidak dikenal tetapi lolos, identifikasi siapa yang mengonfigurasinya dan apakah otorisasinya perlu dipertahankan.
- Untuk pengirim yang tidak dikenal dan gagal, selidiki apakah itu layanan sah yang salah konfigurasi atau penggunaan domain Anda tanpa izin.
Selesaikan kegagalan yang sah sebelum beralih dari pemantauan ke karantina atau penolakan, karena pesan tersebut akan menjadi kandidat penegakan. Memperbaiki kegagalan DMARC membahas penyebab umum.
Bagaimana cara memeriksa laporan untuk domain pengiriman Bird?
Anda dapat mengarahkan laporan agregat ke kotak masuk Anda sendiri melalui alamat rua di rekaman DMARC Anda. Gunakan penganalisis laporan DMARC untuk memeriksa XML, atau buka laporan di editor teks.
Verifikasi DNS Bird memeriksa kebijakan yang Anda publikasikan; laporan penerima menjelaskan hasil autentikasi untuk pesan. Ini adalah pemeriksaan yang terpisah. Panduan autentikasi membahas kebijakan dan rekaman DNS yang perlu dipublikasikan.