DMARC Raporu Nasıl Okunur? Adım Adım Rehber

Bir DMARC kaydı kurduktan birkaç gün sonra kutuna gelen ilk XML dosyasını açtığında çoğu kişi ne okuduğunu anlamaz — bu normal, çünkü aggregate rapor insan için değil, makine için tasarlanmış bir formattır. Bu yazı DMARC kaydının ne işe yaradığını, aggregate ve forensic raporların farkını ve bu raporlardan domain adınıza kimin mail gönderdiğini nasıl çıkaracağınızı adım adım anlatıyor.

DMARC kaydı ne işe yarar

DMARC (Domain-based Message Authentication, Reporting & Conformance), domainin DNS'inde _dmarc.domain.com altında yayınlanan bir TXT kaydıdır. İki temel işlevi vardır: birincisi SPF ve DKIM sonuçlarını "alignment" (From başlığındaki domain ile SPF/DKIM'in kontrol ettiği domainin eşleşmesi) ile birleştirip alıcı sunucuya bir politika söylemek (p=none, p=quarantine, p=reject); ikincisi ise bu kontrollerin sonucunu rapor olarak geri almak.

İkinci işlev — raporlama — DMARC'ı sadece bir engelleme mekanizması değil, aynı zamanda bir görünürlük aracı yapar. Domain sahibi, DMARC raporları sayesinde kendi domaini adına gerçekte kimlerin mail gönderdiğini (meşru araçlar mı, unutulmuş eski bir entegrasyon mu, yoksa bir saldırgan mı) görebilir.

Basit bir DMARC kaydı örneği şöyle görünür: v=DMARC1; p=none; rua=mailto:dmarc-raporlari@sirket.com; ruf=mailto:dmarc-forensic@sirket.com; pct=100. Buradaki v protokol versiyonunu, p politikayı, rua/ruf rapor adreslerini, pct ise politikanın uygulanacağı mail yüzdesini belirtir.

DMARC kaydı yoksa, alıcı sunucular SPF veya DKIM başarısız olan bir maili kendi iç politikalarına göre değerlendirir — bazıları teslim eder, bazıları spam'e atar, bazıları reddeder, ama bu tamamen alıcının inisiyatifindedir ve domain sahibi bu kararlar hakkında hiçbir görünürlüğe sahip olmaz. DMARC kaydı eklemek, bu belirsizliği ortadan kaldırıp hem talimat verme hem de sonucu görme imkânı sağlar.

Aggregate rapor (rua) nasıl okunur

Aggregate rapor, DMARC kaydındaki rua= adresine genelde günlük olarak gelen bir XML dosyasıdır (çoğunlukla .zip veya .gz içinde sıkıştırılmış). Bu dosya, o gün boyunca domain adına gönderilen maillerin özetini IP bazında listeler — kaç mail gönderildiği, hangi SPF/DKIM sonucunun alındığı ve DMARC politikasının o mailler için ne uyguladığı.

XML'in içinde her kaynak IP için bir <record> bloğu bulunur; bu blok içinde <row><source_ip>, <count> (o IP'den gelen mail sayısı), <policy_evaluated> (dmarc sonucunun pass/fail olduğu ve uygulanan aksiyon) ve <auth_results> (SPF ve DKIM'in ayrı ayrı sonucu) yer alır.

Pratikte bu XML'i elle satır satır okumak yerine yapılması gereken şey, IP'leri tek tek tanıyıp tanımadığını kontrol etmektir: bu IP bizim mail sunucumuz mu, kullandığımız CRM/ESP'nin sunucusu mu, yoksa hiç tanımadığımız bir IP mi? Tanınan IP'lerin SPF/DKIM sonucu "pass" ise sorun yok; tanınmayan bir IP'den yüksek sayıda mail görülüyorsa bu ya unutulmuş bir entegrasyon ya da potansiyel bir spoofing girişimidir.

Raporda ayrıca <policy_evaluated> bloğu içinde "disposition" alanı bulunur; bu alan o özel kayıt için DMARC politikasının fiilen ne uyguladığını gösterir (none, quarantine, reject). p=none kaydıyla bile bu alan raporda görünür — yani p=none aşamasında bile, eğer politika p=reject olsaydı ne olacağını raporlardan öngörebilirsin, bu da geçiş kararını vermeden önce riski test etmenin bir yoludur.

Forensic rapor (ruf) ve neden artık daha az kullanılıyor

Forensic rapor, aggregate raporun aksine, tek tek başarısız olan mail örneklerinin (başlık bilgileri, bazen içerik parçası dahil) neredeyse gerçek zamanlı olarak gönderilmesidir. Amaç, bir spoofing girişimini somut bir örnekle görmektir — hangi mail, hangi konu satırıyla, hangi IP'den gönderilmiş.

Ancak forensic raporlar kişisel veri ve gizlilik kaygıları taşıdığı için (mail başlıkları ve bazen içerik parçaları üçüncü bir tarafa - raporu alan domain sahibine - gönderiliyor), başta Gmail olmak üzere büyük mail sağlayıcılarının çoğu bu raporları artık göndermiyor veya çok kısıtlı gönderiyor. Bu yüzden pratikte DMARC izlemesinin büyük kısmı aggregate rapora dayanır; ruf= kaydını eklemek zararsızdır ama gelen veri miktarı düşük olabilir.

Bu durum aggregate raporun önemini daha da artırır — forensic detay eksikse, hangi kaynakların meşru olduğunu anlamanın tek yolu aggregate raporlardaki IP/sayı örüntülerini zaman içinde izlemektir.

Forensic rapor geldiğinde bile içeriği dikkatli okunmalıdır — bu rapor genelde başarısız mailin başlıklarını ve bazen bir kısım gövde metnini içerir, bu da kurum içinde kimin erişebileceği konusunda bir gizlilik/güvenlik politikası gerektirir. Forensic rapor adresini (ruf=) geniş bir ekibe değil, güvenlik veya IT'nin ilgili dar bir grubuna yönlendirmek daha sağlıklı bir uygulamadır.

Ham XML yerine analiz aracı kullanmak: dmarc checker mantığı

Birkaç domainden gelen günlük aggregate raporları elle XML olarak okumak, ölçeklenmeyen bir iştir — büyük bir kurumsal domain günde onlarca farklı sağlayıcıdan (Gmail, Outlook, Yahoo gibi büyük alıcı sunucuları dahil) rapor alabilir. Bu yüzden pratikte bir DMARC checker/analiz aracı kullanılır; bu araçlar gelen XML raporlarını otomatik toplar, IP'leri bilinen sağlayıcı/servis veritabanlarıyla eşleştirir ve bir panoda özetler.

Bu tür bir araç (dmarc checker api üzerinden kendi sistemine entegre edilebilen veya hazır panel sunan) genelde şunu gösterir: hangi kaynaklar SPF/DKIM'den geçiyor (yeşil, sorun yok), hangileri geçmiyor ama muhtemelen meşru (sarı, incelenmeli — örneğin yeni eklenen bir araç henüz SPF kaydına eklenmemiş olabilir), hangileri hiç tanınmıyor ve şüpheli (kırmızı, muhtemel spoofing).

Bu üç renkli ayrım, DMARC politikasını p=none'dan p=quarantine/p=reject'e ne zaman güvenle taşıyabileceğine karar vermenin temelidir: tüm sarı kaynaklar yeşile döndüğünde (yani tüm meşru araçlar SPF/DKIM'den geçmeye başladığında), politikayı sıkılaştırmak meşru maili engelleme riski taşımaz.

Bazı analiz araçları ayrıca bir dmarc checker api sunar; bu, raporları elle panele bakmak yerine kendi iç sistemine (örneğin bir güvenlik dashboard'una veya uyarı mekanizmasına) programatik olarak entegre etmek isteyen IT ekipleri için kullanışlıdır — özellikle birden fazla domain yöneten şirketlerde, her domain için ayrı ayrı panele bakmak yerine tek bir merkezi görünüm elde etmeyi sağlar.

Rapor okuma sürecinde sık yapılan hatalar

DMARC raporlarını izlemeye yeni başlayan ekiplerde tekrar eden bazı hatalar var.

• Raporları hiç kurulum sonrası izlememek — DMARC kaydı sadece kurulduğu için değil, raporları düzenli okunduğu için değer üretir.
• İlk haftadan itibaren p=reject'e geçmek — henüz hangi kaynakların meşru olduğu bilinmeden sıkılaştırmak, meşru maili de engelleyebilir.
• Tanınmayan bir IP'yi görüp hemen "saldırı" diye panik yapmak — çoğu zaman bu, unutulmuş eski bir entegrasyon veya yeni eklenen bir SaaS aracıdır; önce doğrulanmalı.
• Sadece bir günün raporuna bakıp genel bir yargıya varmak — kaynak örüntüleri günden güne değişebilir, en az birkaç haftalık veri üzerinden değerlendirme yapılmalı.
• rua adresini kimsenin okumadığı bir kutuya yönlendirmek — raporlar bir analiz aracına veya düzenli izlenen bir gelen kutusuna gitmeli, aksi halde toplanan veri hiçbir işe yaramaz.
• Birden fazla domain (örneğin ana kurumsal domain ve ayrı bir B2B outreach alt-domaini) yönetirken raporları sadece birinde izleyip diğerini unutmak — her gönderim yapan domainin kendi DMARC kaydı ve izlenen raporu olmalı, aksi halde outreach alt-domaini gözden kaçan bir kör nokta haline gelir.

Sık sorulan sorular