DMARC Raporu Nasıl Okunur? XML Toplu Rapor Rehberi

Q: DMARC raporunda disposition none ne anlama gelir?

disposition değeri none ise alıcı iletiye DMARC kaynaklı bir işlem uygulamamıştır. Bu ya politikanızın p=none olmasından ya da iletinin DMARC'tan geçmesinden kaynaklanır; RFC 9990 biçimindeki raporlarda geçen iletiler için ayrıca pass değeri görülebilir. Hangisi olduğunu aynı satırdaki dkim ve spf sonuçlarından anlayabilirsiniz.

DMARC raporu, Gmail ve Yahoo gibi alıcı posta sağlayıcılarının alan adınız adına gördükleri e-postaları özetleyip DMARC kaydınızdaki rua adresine gönderdiği XML dosyasıdır. Her rapor, belirli bir zaman aralığında hangi IP adreslerinin kaç ileti gönderdiğini, bu iletilerin SPF ve DKIM sonuçlarını ve alıcının uyguladığı işlemi gösterir. Bu raporları okumayı öğrendiğinizde meşru göndericilerinizi ve alan adınızı taklit edenleri net biçimde ayırabilirsiniz.

DMARC rapor türleri nelerdir?

DMARC iki tür rapor tanımlar:

Toplu (aggregate) raporlar: rua etiketiyle istenir, genellikle günde bir kez gönderilir ve ileti içeriği barındırmayan istatistiksel bir özet sunar.
Hata (failure veya forensic) raporları: ruf etiketiyle istenir ve tek tek başarısız iletilerin ayrıntılarını içerir. Gizlilik nedeniyle büyük sağlayıcıların çoğu bu raporları göndermez.

Bu yazıda pratikte asıl işinize yarayacak toplu raporlara odaklanıyoruz. Biçimleri ilk olarak RFC 7489 ekindeki XML şemasıyla tanımlanmıştı; 2026'da yayımlanan RFC 9990 bu biçimi güncelledi ve np, testing gibi yeni alanlar ekledi. Temel yapı korunduğu için aşağıdaki okuma yöntemi her iki biçimde de geçerlidir.

Rapor e-postası nasıl gelir?

Raporlar, sıkıştırılmış (.zip veya .gz) bir XML dosyasını ek olarak taşıyan e-postalar halinde gelir; RFC 9990 yeni raporlar için GZIP sıkıştırmasını öngörse de pratikte ZIP dosyalarıyla da karşılaşabilirsiniz. Konu satırı genellikle "Report Domain: example.com.tr Submitter: google.com" kalıbındadır. Dosya adı ise raporu gönderen kuruluşu, alan adınızı ve zaman aralığını içerir:

google.com!example.com.tr!1791590400!1791676799.zip

Buradaki iki sayı, raporun kapsadığı dönemin başlangıç ve bitiş zamanını Unix zaman damgası olarak verir.

Toplu raporun yapısı

Sadeleştirilmiş bir rapor şöyle görünür:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>4182736459012384756</report_id>
    <date_range>
      <begin>1791590400</begin>
      <end>1791676799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com.tr</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>148</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com.tr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com.tr</domain>
        <selector>s2026</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com.tr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Gerçek raporlarda genellikle çok sayıda record bölümü bulunur. Şimdi her bölümün ne anlattığına bakalım.

Rapor üst bilgileri: kim, ne zaman gönderdi?

report_metadata bölümünde org_name raporu gönderen kuruluşu, report_id raporun benzersiz kimliğini, date_range ise kapsanan dönemi gösterir. Zaman damgalarını okunur tarihe çevirmek için Linux ve PowerShell'de şu komutları kullanabilirsiniz:

date -u -d @1791590400
[DateTimeOffset]::FromUnixTimeSeconds(1791590400).UtcDateTime

Bu örnekteki rapor, 10 Ekim 2026 gününü UTC saatiyle 00:00 ile 23:59 arasında kapsar.

Yayımlanan politika: alıcı ne gördü?

policy_published bölümü, alıcının rapor döneminde DNS'te okuduğu DMARC kaydını yansıtır. Burada beklediğinizden farklı bir politika görüyorsanız (örneğin quarantine yayımladığınızı düşünürken none görünüyorsa) DNS değişikliğiniz yayılmamış ya da yanlış ada eklenmiş olabilir.

Kayıt satırları: asıl veri burada

Her record bölümü, aynı kaynak IP adresinden gelen ve aynı sonuçları alan iletilerin grubunu temsil eder:

source_ip: İletileri gönderen sunucunun IP adresi.
count: Bu IP adresinden o dönemde gelen ve aynı sonuçları alan ileti sayısı.
disposition: Alıcının uyguladığı işlem (none, quarantine veya reject; RFC 9990 biçiminde geçen iletiler için pass da görülebilir).
policy_evaluated içindeki dkim ve spf: DMARC hizalaması dikkate alınarak üretilmiş sonuçlar.
reason: Varsa, alıcının politikadan sapma gerekçesi (mailing_list, local_policy veya trusted_forwarder gibi).

Ham doğrulama sonuçları

auth_results bölümü, SPF ve DKIM'in hizalamadan bağımsız ham sonuçlarını ve hangi alan adı için üretildiklerini gösterir. Raporu okurken en önemli ayrım budur. auth_results içinde SPF pass görünürken policy_evaluated içinde fail görünüyorsa, SPF başka bir alan adı (genellikle gönderim hizmetinin kendi geri dönüş alan adı) için geçmiş, ancak From alan adınızla hizalanmamıştır.

Satırları nasıl yorumlamalı?

DKIM (hizalı)	SPF (hizalı)	Olası anlam	Yapılacak
pass	pass	Doğru yapılandırılmış meşru kaynak	İşlem gerekmez
pass	fail	Yönlendirme ya da SPF kaydında eksik kalan kaynak	IP sizinse SPF kaydına ekleyin
fail	pass	DKIM imzası yok ya da hizasız	Kaynakta kendi alan adınızla DKIM açın
fail	fail	Sahtecilik ya da yapılandırılmamış meşru hizmet	IP adresini araştırın

İlk iki satırdaki iletiler DMARC'tan geçer. Üçüncü satır da geçer, ancak ileti yönlendirildiğinde SPF bozulacağı için kırılgandır; bu kaynakta DKIM imzalamayı mutlaka etkinleştirin. Dördüncü satır, politikanızı sıkılaştırmadan önce çözmeniz gereken gruptur.

Meşru gönderici mi, sahtecilik mi?

Başarısız satırları sınıflandırmak için şu adımları izleyin:

Hacme göre sıralayın: En çok iletinin geldiği IP adreslerinden başlayın; meşru kaynaklar genellikle yüksek ve düzenli hacimle görünür.
Ters DNS sorgusu yapın: dig -x 198.51.100.25 +short komutu, IP adresinin hangi ana makine adına ait olduğunu gösterir. Bu konuda ilk ipucunu PTR kaydı verir.
Envanterinizle eşleştirin: IP adresini kullandığınız posta sunucusu, Microsoft 365, CRM veya bülten hizmetiyle karşılaştırın.
DKIM alan adlarına bakın: Ham sonuçlardaki DKIM alan adı, iletiyi hangi hizmetin imzaladığını çoğu zaman ele verir.
Bilinmeyenleri işaretleyin: Hiçbir hizmetinizle eşleşmeyen, düzensiz hacimli ve SPF ile DKIM'den geçemeyen IP adresleri büyük olasılıkla sahte gönderimdir.
Meşru olanları düzeltin: SPF kaydını güncelleyin, hizmette kendi alan adınızla DKIM'i etkinleştirin ve sonraki raporlarda sonucu doğrulayın.

Sahte gönderim satırlarında disposition değeri none ise, bu iletilere DMARC kaynaklı bir işlem uygulanmamıştır; alıcının diğer filtrelerine takılmadıkça gelen kutularına ulaşmış olabilirler. Bu tür girişimlerin nasıl engelleneceğini e-posta sahteciliği yazımızda anlattık.

Rapor gelmiyorsa neleri kontrol etmeli?

Raporlar günlük gönderildiği için DMARC kaydını yayımladıktan sonra ilk dosyaların bir iki gün içinde gelmesi beklenir. Hiç rapor gelmiyorsa şu noktaları gözden geçirin:

rua değerinin mailto: önekiyle ve geçerli bir adresle yazıldığından emin olun.
Rapor adresi başka bir alan adındaysa, o alan adında raporları kabul ettiğini beyan eden _report._dmarc doğrulama kaydının bulunduğunu kontrol edin.
Rapor posta kutusunun dolu olmadığını ve sıkıştırılmış eklerin kendi spam veya ek filtrenize takılmadığını doğrulayın.
Alan adınızdan gerçekten e-posta gönderildiğinden emin olun; trafik yoksa rapor da oluşmaz.

Raporları okumak için hangi araçlar kullanılır?

Birkaç raporu bir metin düzenleyicide okumak mümkündür, ancak farklı sağlayıcılardan her gün gelen dosyaları elle incelemek kısa sürede yönetilemez hale gelir. Seçenekler kabaca şunlardır:

Elle inceleme: Küçük alan adları ve ilk keşif için yeterlidir.
Açık kaynak ayrıştırıcılar: parsedmarc gibi araçlar raporları bir posta kutusundan okuyup veritabanına aktarır; kurulum ve bakım sizin sorumluluğunuzdadır.
Rapor analiz panelleri: Raporları otomatik toplar, IP adreslerini gruplar ve eğilimleri grafikle gösterir.

MXZilla'in DMARC rapor analizi bu son gruptadır: rua adresine gelen toplu raporları ayrıştırır, kaynakları ve doğrulama sonuçlarını panelde okunabilir biçimde özetler. Böylece XML dosyalarıyla uğraşmadan hangi kaynağın düzeltilmesi gerektiğini görebilirsiniz.

İpucu: Raporları kişisel bir posta kutusuna değil, yalnızca bu iş için açılmış bir adrese yönlendirin. Günlük rapor trafiği kısa sürede kalabalıklaşır ve önemli iletilerin arasında kaybolabilir.

Henüz DMARC kaydınız yoksa veya rua adresi tanımlı değilse önce ücretsiz güvenlik kontrolü ile mevcut durumunuzu görün. DMARC raporlaması ve gelen posta koruması için paketlerimize göz atabilirsiniz.

Sık sorulan sorular

DMARC raporları ne sıklıkla gelir?

Toplu raporlar genellikle günde bir kez gönderilir ve her alıcı sağlayıcı kendi raporunu ayrı gönderir; bu yüzden aynı gün için farklı sağlayıcılardan birden fazla rapor almanız normaldir. RFC 7489'daki ri etiketi farklı bir aralık istemeye izin veriyordu, ancak alıcılar çoğunlukla günlük raporlamayı sürdürdü ve etiket RFC 9989 ile kaldırıldı.

DMARC raporunda disposition none ne anlama gelir?

disposition değeri none ise alıcı iletiye DMARC kaynaklı bir işlem uygulamamıştır. Bu ya politikanızın p=none olmasından ya da iletinin DMARC'tan geçmesinden kaynaklanır; RFC 9990 biçimindeki raporlarda geçen iletiler için ayrıca pass değeri görülebilir. Hangisi olduğunu aynı satırdaki dkim ve spf sonuçlarından anlayabilirsiniz.

SPF ham sonuçta geçtiği halde DMARC değerlendirmesinde neden başarısız görünür?

Bu durum SPF'nin geçtiğini, ancak From alan adınızla hizalanmadığını gösterir. Genellikle gönderim hizmeti zarf adresinde kendi alan adını kullanır. Hizmette özel bir geri dönüş (Return-Path) alan adı ayarlamak veya kendi alan adınızla DKIM imzalamak sorunu çözer.

DMARC raporları kişisel veri içerir mi?

Toplu raporlar ileti içeriği veya alıcı adresi içermez; IP adresleri, alan adları, sayılar ve doğrulama sonuçlarından oluşur. Hata raporları ise ileti başlıkları gibi ayrıntılar taşıyabildiği için kişisel veri barındırabilir. Bu nedenle büyük sağlayıcıların çoğu hata raporu göndermez.

Raporlarda tanımadığım bir IP görürsem ne yapmalıyım?

Önce ters DNS ve IP sahibi sorgusuyla adresin hangi kuruma ait olduğunu belirleyin. Kullandığınız bir hizmete aitse o hizmeti SPF ve DKIM ile yapılandırın. Hiçbir hizmetinizle eşleşmiyorsa büyük olasılıkla sahte gönderimdir ve DMARC politikanızı sıkılaştırarak engellenmelidir.