DMARC Raporları Nasıl Okunur? XML Dosyası Ne Anlatır?

DMARC raporları almaya başladınız; e-posta adresinize ziplenmiş XML dosyaları geliyor. Dosyayı açtığınızda yüzlerce satır ham XML görüyorsunuz — iç içe etiketler, IP adresleri, sonuç değerleri. Bu verinin neyi gösterdiğini, hangi satırın hangi sorunu işaret ettiğini anlamak için XML yapısını kavramak gerekiyor. Raporu bir kez çözdükten sonra aynı mantığı her yeni rapora uygulayabiliyorsunuz.

Burada ele alınan konu DMARC politikası kurmak değil — DMARC kaydı ve politika geçişi ayrı bir yazıda anlatılıyor. Bu yazı, politikanız yayında ve raporlar geliyor ama içlerinde ne yazdığını çözemiyorsunuz noktasından başlıyor. Raporlardaki her alan bir soruya cevap verir: kim gönderdi, hangi IP'den, SPF ve DKIM sonuçları ne oldu, politika ne uygulandı. Bu soruları sırayla yanıtlayan alanları tanıyınca XML'in karmaşıklığı dağılıyor.

Önemli bir pratik not: pek çok kişi DMARC raporlarını etkinleştirdiğinde iki tür rapor bekliyor. Ama gerçekte yalnızca biri düzenli olarak geliyor. Neden böyle olduğunu ve hangisinin asıl çalışma kaynağınız olacağını anlamak, doğru veriye odaklanmanıza yardımcı olur.

İki rapor türü: aggregate (rua) ve forensic (ruf)

DMARC kaydınızda iki farklı rapor adresi tanımlayabilirsiniz: rua ve ruf. Bu ikisi çok farklı veri sunar ve pratikte çok farklı sıklıkla gelir.

rua (aggregate rapor) günlük olarak gönderilir. Belirlenen 24 saatlik pencerede domain'inizden yapılan tüm göndermelerin özetini içerir — kaynağa göre gruplandırılmış, her kaynak IP için kaç mesaj gönderildiği, SPF ve DKIM sonuçları, DMARC politikasının ne uyguladığı. Bu raporlar XML formatında, zip ile sıkıştırılmış olarak gelir. Format: rua=mailto:[email protected]

ruf (forensic rapor veya failure rapor), DMARC değerlendirmesinin başarısız olduğu bireysel mesajlar için tetiklenir. Her başarısız mesaja dair detaylı bir rapor — konu satırı, başlıklar, hatta kimi zaman mesaj gövdesi. Bu hassas içerik nedeniyle büyük alıcı sunucuların çoğu (Gmail, Microsoft, Yahoo) forensic rapor artık göndermemektedir. DMARC kaydınızda ruf adresi tanımlasanız bile büyük ihtimalle hiç rapor gelmeyecektir. Bu beklenen bir durum; forensic raporların gelmemesi sistemin bozuk olduğu anlamına gelmiyor.

Dolayısıyla analizinizin tamamı rua aggregate raporlara dayanacak. Günlük gelen bu dosyalar, e-posta altyapınızın tam görüntüsünü taşır ve doğru okunduğunda teşhisin tüm katmanlarını sunar.

XML dosyasının iskelet yapısı

Bir aggregate raporu açtığınızda karşınıza çıkan XML'in dört ana katmanı var. Bu katmanları bir kez yerleştirince dosyanın geri kalanı mantıklı hale geliyor.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1712188800</begin>
      <end>1712275200</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>...</row>
    <identifiers>...</identifiers>
    <auth_results>...</auth_results>
  </record>

  <record>...</record>
</feedback>

<report_metadata> raporu gönderen alıcı sunucuyu tanımlar. org_name hangi e-posta sağlayıcısının gönderdiğini gösterir — gmail.com, outlook.com, yahoo.com gibi. date_range içindeki değerler Unix timestamp formatındadır; raporun hangi 24 saatlik pencereyi kapsadığını gösterir.

<policy_published>, rapor döneminde domain'inizde yayında olan DMARC politikasını yansıtır. Politikanızı değiştirdiğinizde eski raporlarda önceki değeri, yeni raporlarda güncel değeri görürsünüz. Bu alan, politika değişikliklerinin etkisini geriye dönük izlemek için kullanışlıdır.

Asıl bilgi her <record> bloğunda. Bir rapor birden fazla record içerebilir; her record farklı bir kaynak IP'ye karşılık gelir. 10 farklı IP'den mesaj gönderildiyse 10 ayrı record görürsünüz. Tüm analiziniz bu bloklar üzerinde yoğunlaşır.

<record> bloğunu okuma: row, policy_evaluated, auth_results

Bir record bloğunun içinde üç kritik bölüm var. Bunların birbirinden ne farkı olduğunu anlamak, DMARC raporunu gerçekten okuyabilmenin özü.

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>143</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
      <selector>google</selector>
    </dkim>
    <spf>
      <domain>mail.example.com</domain>
      <result>fail</result>
    </spf>
  </auth_results>
</record>

<source_ip> mesajların geldiği IP adresi. <count> bu IP'den rapor döneminde kaç mesaj gönderildiği. Bu iki alan birlikte size şunu söyler: belirli bir kaynak, domain'iniz adına 143 mesaj gönderdi.

<policy_evaluated> DMARC motorunun bu kaynak için verdiği nihai karar. disposition politikanın ne uyguladığını gösterir: none mesaj teslim edildi, quarantine spam'e yönlendirildi, reject reddedildi. Buradaki dkim ve spf değerleri alignment sonucudur — yani ham doğrulama değil, domain eşleşmesi dahil değerlendirme.

<auth_results> ise ham mekanizma sonuçlarını tutar — DMARC alignment hesaba katılmadan, SPF ve DKIM'in teknik olarak ne döndürdüğü. Burada SPF'nin hangi domain için değerlendirildiğini de görebilirsiniz. <identifiers> altındaki header_from ise e-postanın "From" başlığındaki domain — alignment kontrolü bu iki domain'i karşılaştırır.

Bu iki blok arasındaki fark önemli: auth_results içinde SPF pass görünebilir ama policy_evaluated içinde spf: fail yazabilir. Bu, SPF doğrulamasının teknik olarak geçtiği ama "From" başlığıyla alignment sağlamadığı anlamına gelir — çoğunlukla göndericinin envelope-from domain'i ile header-from domain'i birbirinden farklıdır.

SPF ve DKIM sonuç kombinasyonları ne anlama geliyor?

DMARC, SPF ve DKIM'den en az birinin alignment sağlamasını yeterli sayar. Bu nedenle policy_evaluated içindeki kombinasyonları doğru yorumlamak, sorunun nerede olduğunu tespit etmenin anahtarı.

Her iki mekanizma da pass döndürüyorsa — dkim: pass ve spf: pass — bu kaynak domain'inizin tam yetkisi altında çalışıyor demektir. Yapılandırma eksiksiz, alignment sağlanmış, DMARC geçer. disposition: none görüyorsanız teslimatta sorun yok.

DKIM pass ama SPF fail durumu çok yaygın ve genellikle sorun değildir. Bir üçüncü taraf gönderim servisi (pazarlama aracı, CRM, destek platformu) mesajları kendi mail sunucularından gönderdiğinde SPF kontrolü o servisin domain'i üzerinden geçer, sizin "From" domain'inizle alignment sağlamaz. DKIM imzası ise doğrudan başlığa eklendiği için domain'inizi taşır ve alignment sağlar. DMARC bu durumda DKIM'e dayanarak geçer — teslimatta sorun olmaz. Ancak SPF kaydınıza o servisin include'unu eklemek hem alignment'ı tamamlar hem de raporlarda temiz bir görünüm sağlar.

SPF pass ama DKIM fail görüyorsanız — DKIM imzası bozuk, eksik ya da yanlış selector kullanılıyor olabilir. DKIM kurulumunda selector'ın TXT kaydına doğru işlenip işlenmediğini ve imzanın gönderim servisi tarafından eklenip eklenmediğini doğrulamak gerekir. SPF tek başına alignment sağlıyorsa DMARC geçer ama DKIM sorununu gidermek yine de doğru yaklaşım.

Her ikisi de fail döndürüyorsa DMARC fail olur ve politikanıza göre disposition değeri quarantine veya reject olur. Bu kombinasyon ciddi bir teslimat sorununa işaret eder ve kaynağın kim olduğunu anlamak ilk adımdır.

spf: permerror görünüyorsa SPF 10 lookup limiti aşılmış olabilir — SPF değerlendirmesi tamamlanamadığı için kalıcı hata döner. Bu durumda SPF alignment beklenemez; DMARC'ın geçebilmesi tamamen DKIM alignment'ına bağlıdır.

dkim: none veya spf: none durumları değerlendirmenin yapılamadığı anlamına gelir: DKIM kaydı bulunamadı ya da imza hiç eklenmedi. Gönderim servisi DKIM imzalaması yapmıyorsa bu kaynak için DKIM sonucu sürekli none gelecektir.

Hangi IP'den ne geliyor? Kaynakları tanımlama

source_ip alanı, rapordaki en operasyonel bilgidir. Orada gördüğünüz her IP adresini üç kategoriden birine koymanız gerekir: bilinen ve yetkili gönderici, bilinen ama SPF/DKIM ayarlanmamış servis, hiç tanımadığınız kaynak.

Bilinen ve yetkili göndericiler — kendi mail sunucunuz, Google Workspace, Microsoft 365 veya yapılandırdığınız diğer servisler — her iki mekanizmada da pass dönmeli. Bu IP'lerden gelen kayıtlar sağlıklıysa alarm yok. count değeri beklenen hacimle orantılı mı, buna bakın; anormal yüksek sayılar kimi zaman gönderim hataları veya döngülerin işareti olabilir.

Tanıdığınız ama DMARC başarısız olan bir IP görüyorsanız — mesela domain doğrulaması yapılmamış yeni bir servis entegre edilmiş — yapılacak şey bellidir: o servis için DKIM imzalamasını etkinleştirmek veya SPF kaydına ekleme yapmak. Rapor size bunu açık biçimde söylüyor.

Hiç tanımadığınız bir IP'den gelen kayıtlar farklı bir durum. İki olasılık var: biri, domain'iniz adına yetkisiz e-posta gönderilmeye çalışılıyor — spoofing denemesi. Diğeri, iç altyapınızda farkında olmadığınız bir sistemin e-posta gönderdiği. IP adresini bir whois sorgusunda veya IP-to-organization aracında aramak kaynağı çoğunlukla açığa çıkarır. DMARC politikanız reject düzeyindeyse bu IP'lerden gelen mesajlar zaten reddediliyor — raporlar bu korumanın çalıştığını doğrular.

count değerini küçümsememeye dikkat edin. Küçük sayılar da önemli: birkaç mesajlık bir kayıt, yanlış yapılandırılmış bir iç sistem veya test ortamının izi olabilir. Büyük sayılar ise gerçek teslimat hacmini temsil eder ve o kaynağın sağlıklı çalışıp çalışmadığını öncelikli olarak izlemenizi gerektirir.

Rapor analiz araçları — XML'i elle okumak zorunda değilsiniz

Ham XML'i bir metin editöründe açıp okumak mümkün ama verimli değil. Özellikle günde onlarca rapor gelmeye başladığında elle okuma hızla kullanılamaz hale gelir. Bu iş için geliştirilmiş araçlar, XML'i görsel tablolara ve zaman serisi grafiklere dönüştürür; IP adreslerini bilinen gönderim servisleriyle otomatik eşleştirir.

Dmarcian bu araçların en kapsamlısı. Raporları otomatik alır, her source_ip'yi servis adına çevirir (Google Workspace, Mailchimp, SendGrid vb.), zaman içindeki pass/fail oranlarını görselleştirir. Ücretsiz planı küçük hacimler için yeterli. Sorunlu kaynağı tespit etmek, aylık raporları karşılaştırmak ve yeni bir servis ekledikten sonra alignment'ı doğrulamak için ilk başvurulacak araç olarak konumlanmıştır.

Google Postmaster Tools farklı bir odak sunar: yalnızca Gmail alıcılar için veri. Domain reputation, spam oranı ve teslimat başarısını Gmail perspektifinden izler. DMARC raporlarını görselleştirmez ama teslimat kalitesini doğrudan ölçer — DMARC raporlarıyla birlikte kullanıldığında tamamlayıcı bir katman oluşturur.

MXToolbox'ın DMARC analiz aracı tek seferlik kontroller için pratik. Bir XML dosyasını yükleyip hızlı bir özet almak istediğinizde işe yarar; sürekli izleme için değil, arızi teşhis için uygundur.

Araçların XML'e kıyasla sunduğu en kritik avantaj kaynak haritalama. Ham raporda 209.85.220.41 görürsünüz; araç bunu "Google Workspace" olarak etiketler. Onlarca IP adresi içeren raporlarda bu eşleme, hangi kaynağın sorunlu olduğunu bulmak için gereken zamanı ciddi ölçüde kısaltır.

DMARC raporları başlangıçta karmaşık görünür çünkü XML sözdizimi göz korkutucu. Ama yapıyı bir kez tanıyınca — hangi blokta ne var, policy_evaluated ile auth_results'ın farkı ne, hangi IP neyi temsil ediyor — aynı çerçeveyi her raporda hızla uygulayabiliyorsunuz. Her yeni rapor yeni bir bulmaca değil; bilinen bir yapının yeni bir örneği.

Raporları düzenli okumak, e-posta altyapısındaki değişikliklerin etkisini doğrudan ölçer. Yeni bir servis entegre ettikten sonra o servisin kayıtlarda nasıl göründüğünü, DKIM alignment'ının sağlanıp sağlanmadığını, beklenmedik IP'lerin ortaya çıkıp çıkmadığını görmek — bunların hepsi raporlarda var. Bu veriyi okumasını bilmek, altyapınızın görünmez kalan bir katmanını görünür kılıyor.