DMARC Aggregate ve Forensic Raporları Farkı: Hangisi Ne Zaman İncelenir?
DMARC kaydına birkaç satır TXT eklemek, posta güvenliğinin başlangıcıdır; raporları okumayı öğrenmeden politikayı ilerletmek ise kör yürümektir. Hangi IP meşru, hangi IP sahte, mesajlar neden başarısız oluyor - bunları göremeden politikayı none'dan reject'e taşırsanız meşru e-postalarınızı bloke edersiniz; kademe DMARC politika geçişinin tam merkezidir. Alıcı posta sunucuları, domain'inizden geliyormuş gibi görünen mesajlar için iki ayrı rapor türü üretir; bu çıktı DMARC raporlarını okuma disiplininin ham girdisidir: aggregate (toplu) ve forensic (adli).
Her biri farklı bir soruyu yanıtlar. Aggregate raporlar büyük resmi gösterir: hangi kaynak IP ne kadar mesaj gönderdi, DMARC hizalamasından kaçı geçti, kaçı geçemedi. Forensic raporlar ise tek bir başarısız mesaja odaklanır; zarftan bir kesit sunar. Yüksek hacimde bu ayrım newsletter DMARC izlemesinde daha da keskinleşir. Her ikisi de DMARC kaydına eklenen ayrı adreslere iletilir, her ikisi de isteğe bağlıdır.
Hangi rapor türünü ne zaman aktif etmeniz gerektiği, karşı karşıya olduğunuz soruna göre şekillenir. Forensic raporlar olmadan da pek çok sorun çözülebilir; aggregate raporlar olmadan ise düzeltecek zemin bile bulunamaz. E-postaların spam klasörüne düşmesi gibi teslimat sorunlarının büyük bölümü, aggregate raporların ortaya koyduğu hizalama hatalarında gizlidir.
Aggregate Raporlar: 24 Saatlik Trafik Özeti
Aggregate raporlar, alıcı posta sunucuları tarafından her 24 saatte bir gönderilir. DMARC kaydınızda rua=mailto:[email protected] tanımladıysanız bu raporları o adrese alırsınız; adres, TXT kaydındaki raporlama alanıdır. Gelen dosya genellikle .xml.gz ya da .zip uzantısıyla sıkıştırılmış gelir; arşiv açıldığında içinde düz bir XML belgesi bulunur.
Bu belge, söz konusu alıcı sunucunun 24 saat içinde domain'inizden geliyormuş gibi gördüğü tüm mesajları kaynak IP başına gruplar; her gruba mesaj sayısını ve DMARC hizalama sonucunu ekler. Tek bir rapor onlarca kaynak IP içerebilir. Raporun en değerli kullanımı, hiç fark etmediğiniz gönderim kaynaklarını gün yüzüne çıkarmaktır: eski bir CRM entegrasyonu, hâlâ aktif bir eski SMTP sunucusu ya da hizalama hatası yaratan üçüncü taraf bir gönderici.
Aggregate raporlar mesajın içeriğini anlatmaz. Alıcıyı, konuyu ya da metni göremezsiniz. Bu sınır kasıtlıdır; mahremiyet kaygısıyla konmuştur ve forensic raporlardan temel farkı budur.
XML Dosyasını Açmak ve Temel Yapıyı Tanımak
Dosyayı doğrudan bir metin editöründe açabilirsiniz. Güzel yazdırma (pretty print) yapan herhangi bir uygulama belgeyi okunaklı hâle getirir. Tipik bir aggregate raporun iskelet yapısı şöyledir:
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<date_range>
<begin>1746057600</begin>
<end>1746143999</end>
</date_range>
</report_metadata>
<policy_published>
<domain>siteniz.com</domain>
<p>quarantine</p>
<adkim>r</adkim>
<aspf>r</aspf>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>siteniz.com</domain>
<result>pass</result>
<selector>google</selector>
</dkim>
<spf>
<domain>siteniz.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>policy_published bloğu, alıcı sunucunun DNS'inizden okuduğu politikayı gösterir. Burada beklenmedik bir değer varsa DNS kaydınız henüz güncellenmemiş ya da TTL eski değeri dağıtıyor olabilir. adkim ve aspf alanlarındaki r değeri "relaxed" hizalamayı, s ise "strict" hizalamayı ifade eder; relaxed modda alt domain'ler geçerlidir, strict modda tam eşleşme aranır.
Raporu gönderen kuruluşu report_metadata bloğundaki org_name alanından okuyabilirsiniz. Google, Outlook, Yahoo ve diğer büyük alıcılar ayrı raporlar gönderir; her biri kendi trafik dilimini temsil eder. Tek bir kaynaktan gelen raporu değil, birden fazla kaynaktan gelen toplam tabloyu değerlendirmek daha sağlıklı karar zemini sunar.
Raporun Kilit Alanları: Neye Dikkat Edilmeli?
Her record bloğunda iki farklı sonuç yatar: policy_evaluated altındaki DMARC hizalama kararı ve auth_results altındaki ham doğrulama sonucu. Bu ikisi çoğu zaman örtüşür; ama bir mesajın SPF'den geçip DMARC hizalamasında başarısız olması mümkündür. Neden? SPF Return-Path adresinin From başlığıyla hizalanmaması, DMARC'ta SPF hizalama başarısızlığı sayılır.
Üçüncü taraf e-posta servis sağlayıcıları genellikle kendi Return-Path adreslerini kullandığından bu durum sık görülür. Toplu e-posta gönderiminde bu hizalama kopmalarını aggregate raporlardan erken okumak, politika ilerletilmeden önce düzeltme imkânı tanır. Google Workspace DNS kurulumunda da DKIM selector'ının doğru tanımlanması bu başarısızlıkları önler.
DKIM başarısızlıkları farklı bir işaret taşır. auth_results'ta none görüyorsanız DKIM imzası hiç eklenmemiştir; fail görüyorsanız imza var ama doğrulanamıyordur. Fail durumu, mesajın iletimde değiştirildiğine ya da imzalayan domain'in From başlığıyla uyuşmadığına işaret eder.
disposition alanı alıcı sunucunun mesaja ne yaptığını gösterir: none, quarantine ya da reject. Bu değer bazen policy_published'daki p değeriyle örtüşmez; bazı alıcı sunucular DMARC politikasını tam uygulamaz ve bunu raporlarda belirtir. Politikanızı quarantine'e taşısanız bile bazı alıcılar mesajı yine de teslim edebilir; bu bir sorun değil, sistem böyle tasarlanmıştır.
Forensic Raporlar: Tek Başarısız Mesajın Kırıntıları
Forensic raporlar RFC 6591'de tanımlanmış ARF (Abuse Reporting Format) yapısında gelir. DMARC kaydınızda ruf=mailto:[email protected] tanımladıysanız, alıcı sunucu DMARC'ta başarısız olan her mesaj için ayrı bir bildirim gönderir. Aggregate raporların 24 saatlik döngüsünün aksine, bunlar gerçek zamanlıya yakın gelir.
Bir forensic rapor şunları içerir: mesajın From, To, Subject ve Date başlıkları; gönderen IP; Authentication-Results başlığındaki DKIM ve SPF sonuçları. Bazı sağlayıcılar mesaj gövdesinin tamamını da ekler, çoğu eklemez. Raporu incelediğinizde başarısızlığın tam nedenini görebilirsiniz: DKIM imzası hangi selector ile denenmiş, SPF hangi mekanizmada takılmış.
Forensic raporun en pratik değeri, spoofing girişimlerini somutlaştırmaktır. Aggregate raporda "şu IP'den 47 başarısız mesaj" yazan satır, forensic raporda "Subject: Ödemenizi doğrulayın" başlıklı, sahte bir adresten gönderilmiş spesifik bir mesaja dönüşür. Bu fark, bir güvenlik olayında karar vermeyi kolaylaştırır.
Forensic Raporların Sınırları ve Gizlilik Sorunu
Pratik bir sorun var. Büyük alıcı sağlayıcıların çoğu, özellikle Gmail, forensic rapor göndermez. Google 2023'te kullanıcı gizliliğini gerekçe göstererek bu desteği kaldırdı; bazı diğer büyük sağlayıcılar da benzer kararlar aldı. Yani ruf adresini tanımlasanız bile alacağınız forensic rapor hacmi aggregate raporların çok gerisinde kalabilir.
Bir diğer sınır, hacim sorunudur. Siteniz yoğun saldırı altındaysa her başarısız mesaj için ayrı bir forensic rapor gelir; bu, saatler içinde posta kutunuzu dolduran yüzlerce bildirime dönüşebilir. Forensic raporlama adresini ayrı, özel bir posta kutusuna yönlendirmek bu sorunu yönetir.
Gizlilik boyutu da göz ardı edilemez. Forensic raporlar mesaj başlıklarını içerdiğinden, meşru ama başarısız bir mesajın alıcısının adresi size ulaşır. Microsoft 365 ortamında ya da herhangi bir kurumsal yapıda forensic raporlama aktifse, bu veriyi işleyen ekibin veri koruma politikalarını buna göre güncellemesi gerekir.
Hangi Senaryoda Hangisi Gerekir?
Kural basit: aggregate raporlar her zaman açık olmalıdır. Politikayı none'dan ilerletmeyi düşünmeden önce en az birkaç haftalık aggregate rapor verisi toplamak, karar zemini oluşturur. Zoho Mail gibi üçüncü taraf servisler de dahil olmak üzere tüm meşru gönderim kaynaklarını bu raporlardan tespit edebilirsiniz.
Aggregate rapor (rua): Her zaman aktif edin. Politika kararlarının tamamı bu veriye dayanır.
Forensic rapor (ruf): Belirli bir saldırıyı veya başarısızlığı incelemeniz gerektiğinde aktif edin; soruşturma bittikten sonra kapatabilirsiniz.
Forensic raporlar şu senaryolarda gerçekten işe yarar: domain'inizi taklit eden bir phishing kampanyası aktifse ve hangi içerikle, hangi alıcılara gönderildiğini anlamak istiyorsanız; ya da belirli bir entegrasyonun neden DMARC'tan geçemediğini aggregate rapordaki IP'den anlayamıyorsanız. İkinci senaryoda forensic rapor, başlık ayrıntılarıyla teşhisi hızlandırır.
Forensic raporları gereksiz kılan senaryo ise aggregate raporların net cevap verdiği durumdur. Hangi IP'nin başarısız olduğunu biliyorsanız, o IP'nin sahibini ters DNS ile tespit edip DKIM veya SPF yapılandırmasını düzeltmek için forensic rapora gerek kalmaz. Aggregate veri çoğu zaman yeterlidir.
DMARC Kaydına rua ve ruf Eklemek
Her iki rapor adresi aynı TXT kaydında tanımlanır. Örnek bir kayıt:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1fo parametresi forensic rapor tetikleyicisini belirler. fo=0 yalnızca hem DKIM hem SPF başarısız olduğunda rapor gönderir; fo=1 herhangi birinin başarısız olması durumunda gönderir. Spoofing incelemesi için fo=1 daha fazla veri sağlar; ama yukarıda belirtildiği gibi büyük sağlayıcıların çoğu bu raporları göndermez.
Raporlama adreslerini başka bir domain'de tanımlamak da mümkündür. Farklı bir domain kullanıyorsanız o domain'in DNS'ine izin kaydı eklemeniz gerekir: siteniz.com._report._dmarc.raporlama-domain.com TXT "v=DMARC1;". Bu adım atlanırsa alıcı sunucular raporu göndermez. Microsoft 365 ve Google Workspace ortamlarında raporlama adresini aynı domain'de tutmak bu karmaşıklığı ortadan kaldırır.
DMARC raporlarını birkaç hafta izledikten sonra tablonuz netleşir: hangi IP'ler meşru, hangilerinin yapılandırılması gerekiyor, hangileri tamamen yabancı. Bu tabloya dayanmadan politikayı quarantine ya da reject'e taşımak, meşru iş e-postalarının bloke edilmesi riskini beraberinde getirir.
İki rapor türü birbirinin rakibi değil, tamamlayıcısıdır. Aggregate raporlar karar verdirir, forensic raporlar araştırır. Birini sürekli açık tutun; diğerini ihtiyaç duyduğunuzda aktif edin, işiniz bitince kapatın. DNS kayıtlarını değiştirmek dakikalar alır; domain portföyünüzü birden fazla domain üzerinden yönetiyorsanız her domain için ayrı raporlama adresleri belirlemek izlemeyi kolaylaştırır.