DMARC Raporları Nasıl Okunur? Yetkisiz Gönderimleri Bulmak

DMARC kaydınızdaki rua adresine gelen toplu raporlar, alıcı sunucuların bir gün boyunca sizin alan adınızla gördüğü postaları kaynak IP'ye göre gruplayan sıkıştırılmış XML dosyalarıdır. Her record bloğu bir IP'yi, o IP'den gelen ileti sayısını, DMARC açısından hizalı SPF ve DKIM sonucunu (policy_evaluated) ve ham doğrulama sonuçlarını (auth_results) gösterir. Yetkisiz gönderimi bulmak için IP'leri sahiplerine göre sınıflandırırsınız: kendi sunucunuz, yetki verdiğiniz servisler, yönlendiriciler ve tanımadığınız kaynaklar. Hizalamadan kalan ve tanımadığınız IP'ler araştırılacak listedir.

Toplu rapor mu, adli rapor mu?

DMARC iki tür rapor tanımlar. rua etiketine yazdığınız adrese toplu raporlar (aggregate reports) gelir. Bunlar ileti içeriği taşımaz, yalnızca sayılar ve doğrulama sonuçları içerir ve alıcılar genellikle günde bir gönderir. ruf etiketi ise tek tek başarısız postalar için adli raporları (failure reports) ister. Bu raporlar başlık, hatta içerik parçası taşıyabildiği için standardın kendisi de büyük alıcıların çoğunun gizlilik gerekçesiyle bunları göndermediğini yazar. İşin pratiğinde elinizdeki veri neredeyse tamamen toplu raporlardan oluşur.

Standart cephesinde 2026'da önemli bir değişiklik oldu. Mayıs 2026'da DMARC'ın çekirdeği RFC 9989, toplu raporlama RFC 9990 ve adli raporlama RFC 9991 olarak yayımlandı. Bu üç belge 2015 tarihli RFC 7489'un yerini aldı. Rapor okuyan biri için değişiklik sınırlı: XML öğelerinin adları aynı kaldı, birkaç yeni öğe eklendi. Alıcıların hepsi yeni biçime aynı gün geçmeyeceği için bir süre iki biçimi yan yana görmeniz olası. DMARC kaydının temel yapısını henüz kurmadıysanız önce SPF, DKIM ve DMARC kayıtlarının kurulumunu tamamlayın.

Raporu açmak: konu satırı, dosya adı, zaman

Rapor postasının konusu RFC 9990'a göre Report Domain: ornek.com.tr Submitter: posta.ornek.com kalıbıyla başlar. İlk alan adı raporun hangi alan adı için olduğunu, ikincisi raporu kimin ürettiğini söyler. Ek dosyanın adı da bilgi taşır: alıcı, alan adı, başlangıç ve bitiş zamanı ! işaretiyle ayrılmış olarak sıralanır. Standart sıkıştırma için gzip ister, yani dosya çoğunlukla .xml.gz uzantılıdır. Bazı alıcılardan .zip gelmesi de şaşırtmasın.

Dosya adındaki ! işareti kabukta sorun çıkarabilir. Tek tırnak içine alıp kısa bir ada çevirmek işinizi kolaylaştırır:

mv 'posta.ornek.com!ornek.com.tr!1793059200!1793145599.xml.gz' \
   rapor.xml.gz
gunzip -k rapor.xml.gz
xmllint --format rapor.xml | less
date -u -d @1793059200

gunzip -k sıkıştırılmış dosyayı silmeden açar. xmllint --format tek satıra sıkıştırılmış XML'i girintili hâle getirir. Son komut başlangıç zaman damgasını okunur tarihe çevirir: Tue Oct 27 00:00:00 UTC 2026. Zaman damgaları UTC'dir, raporlama dönemi de genellikle UTC gece yarısında başlayan bir gündür. Türkiye saatiyle eşleştirirken üç saat ekleyin.

Örnek bir raporu satır satır okuyalım

Aşağıdaki rapor varsayımsaldır. Alan adı ornek.com.tr, raporu gönderen alıcı posta.ornek.com, bülten servisi de bulten.ornek.com adlı hayali bir servis. IP'lerin hepsi belgelendirme aralıklarından seçildi. Biçim RFC 9990'daki yeni şemaya uyuyor:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>posta.ornek.com</org_name>
    <email>dmarc-rapor@posta.ornek.com</email>
    <report_id>20261027-0001</report_id>
    <date_range>
      <begin>1793059200</begin>
      <end>1793145599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>ornek.com.tr</domain>
    <p>none</p>
    <sp>none</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <testing>n</testing>
    <discovery_method>treewalk</discovery_method>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.10</source_ip>
      <count>1240</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ornek.com.tr</header_from>
      <envelope_from>ornek.com.tr</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ornek.com.tr</domain>
        <selector>default</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>ornek.com.tr</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>860</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ornek.com.tr</header_from>
      <envelope_from>bounce.bulten.ornek.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>bulten.ornek.com</domain>
        <selector>s1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.bulten.ornek.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>203.0.113.77</source_ip>
      <count>37</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ornek.com.tr</header_from>
      <envelope_from>ornek.com.tr</envelope_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>ornek.com.tr</domain>
        <scope>mfrom</scope>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Üst kısım: kim raporluyor, hangi politika görüldü?

report_metadata raporu üreten kuruluşu, rapor kimliğini ve dönemi verir. policy_published ise alıcının o gün DNS'te bulduğu DMARC kaydınızın özetidir. Kaydı yeni değiştirdiyseniz ilk bakacağınız yer burası. Burada hâlâ eski politikayı görüyorsanız alıcı kaydı önbellekten okumuş ya da değişiklik o gün yayılmamıştır. Yeni şemada üç alan dikkat çekiyor: testing kayıttaki t etiketinin değeridir, discovery_method kaydın eski yöntemle mi (psl) yoksa RFC 9989'un DNS ağaç taramasıyla mı (treewalk) bulunduğunu söyler, np ise yalnız kayıtta tanımlıysa görünür. Eski biçimdeki raporlarda bu alanlar yoktur, onların yerine pct alanı bulunur.

row: kaynak IP ve ileti sayısı

Her row bir kaynak IP'yi ve o IP'den aynı sonuçla gelen ileti sayısını gösterir. Aynı IP farklı sonuçlar ürettiyse, örneğin bazı postalar imzalı bazıları imzasızsa, raporda iki ayrı record olarak çıkar. disposition alıcının ne yaptığını anlatır. p=none yayımladığınız sürece burada none görürsünüz. Yeni şemada zorlayıcı bir politikayla DMARC'tan geçen postalar için pass değeri de tanımlı. Alıcı politikanızdan farklı davrandıysa, mesela bir posta listesinden geldiği için postayı kabul ettiyse, reason alanında mailing_list, trusted_forwarder ya da local_policy gibi bir gerekçe yazar.

policy_evaluated ile auth_results neden çelişiyor?

İkinci kayda bakın. auth_results altında hem DKIM hem SPF pass diyor, ama policy_evaluated ikisine de fail vermiş. Raporları ilk kez okuyanların en çok takıldığı yer burası. auth_results ham sonucu gösterir: imza geçerli, SPF kaydı da o IP'ye izin veriyor. Ne var ki imza bulten.ornek.com adına atılmış, SPF de servisin kendi bounce alan adı için geçmiş. Postanın Kimden satırındaki ornek.com.tr ile ikisi de hizalı değil. DMARC yalnızca hizalı sonuçları sayar. Bu yüzden 860 ileti DMARC'tan kalmış ve politikanız reject olsaydı bülteninizin tamamı geri dönecekti.

Hizalama: gevşek ve sıkı

Hizalamanın iki modu var. Gevşek (relaxed) modda kimliği doğrulanan alan adı ile Kimden satırındaki alan adının aynı kuruluş alan adına bağlı olması yeterlidir. Sıkı (strict) modda ikisinin birebir aynı olması gerekir. Modu SPF için aspf, DKIM için adkim etiketi belirler ve ikisinin varsayılanı r, yani gevşektir.

Diyelim ki bülten servisinizi bounce.ornek.com.tr zarf adresiyle ve d=ornek.com.tr imzasıyla çalışacak şekilde ayarladınız. Gevşek modda SPF de DKIM de hizalanır, çünkü bounce.ornek.com.tr ile ornek.com.tr aynı kuruluş alan adındadır. aspf=s yazarsanız SPF hizası bozulur ama DKIM hâlâ geçer, DMARC için biri yeterli. Sıkı modu ancak alt alan adlarınızın kimin elinde olduğunu tam bildiğiniz ve gerçek bir gerekçeniz olduğunda seçin. Çoğu işletme için varsayılan gevşek mod doğru tercihtir.

RFC 9989 kuruluş alan adını bulma yöntemini de değiştirdi. Eskiden alıcılar bir kamu sonekleri listesine (Public Suffix List) bakıyordu. Artık DNS'te _dmarc kayıtlarını yukarı doğru tarayan bir yöntem tanımlı. ornek.com.tr gibi sıradan bir yapıda sonuç değişmez. Kuruluş içinde farklı birimlerin kendi alt alan adlarına ayrı DMARC kaydı yayımladığı karmaşık yapılarda fark çıkabilir.

Kaynakları sınıflandırmak

Elinizde birkaç günlük rapor birikti. Şimdi her kaynak IP'yi dört gruptan birine yerleştirmeniz gerekiyor:

Yönlendirme satırı bir parantezi hak ediyor. Bir müşteriniz kendi adresine gelen postaları başka bir kutuya yönlendiriyorsa posta, yönlendiren sunucunun IP'sinden çıkar ve SPF doğal olarak kalır. İçerik değişmediyse DKIM imzası sağlam kalır ve DMARC geçer. Posta listeleri konuya ek veya alt bilgi eklediğinde DKIM de bozulabilir. Bu satırları sahtecilik sanıp panik yapmayın, ama DKIM'i olmayan bir kurulumla reject'e geçerseniz yönlendirilen postalarınızın kaybolacağını da bilin.

Bir de dördüncü gruba yanlışlıkla düşen meşru kaynaklar vardır. Ofisteki tarayıcı ya da yazıcının gönderdiği bildirimler, muhasebe yazılımının fatura postaları, yıllar önce kurulmuş ve unutulmuş bir web sunucusu. Hosting firmanızı değiştirdikten sonra eski sunucuda kalan bir site formu da bu listeye girer. Bu tür kaynakları hosting değişikliğinden sonra bozulan e-posta ayarlarıyla birlikte gözden geçirin.

Bir IP'nin sahibini bulmak

Tanımadığınız her IP için iki sorgu çoğu zaman yeterli fikir verir:

dig +short -x 203.0.113.77
whois 203.0.113.77

İlki ters DNS (PTR) adını getirir. Bu ad bir posta sağlayıcısını, bir bulut firmasını ya da bir ev bağlantısını işaret edebilir. İkincisi IP bloğunun hangi kuruluşa tahsis edildiğini ve hangi bölgesel kayıt kuruluşunda kayıtlı olduğunu gösterir. Örnekteki belgelendirme adresleri gerçek bir sonuç döndürmez, kendi raporlarınızdaki IP'lerle deneyin.

Şunu baştan söyleyelim: IP'nin büyük ve tanınmış bir posta sağlayıcısına ait olması, gönderimin size ait olduğunu göstermez. Sahteciler de bu altyapılarda hesap açabilir. Bakmanız gereken soru şu: o sağlayıcıyı siz ya da bir tedarikçiniz kullanıyor mu? Kullanmıyorsanız ve DKIM imzası sizin alan adınıza değilse, o kayıt ya bir yönlendirmedir ya da birinin sizin adınızla posta gönderme denemesidir.

Kendi IP'niz DMARC'tan sorunsuz geçiyor ama ileti sayısı alışılmadık biçimde artmışsa başka bir şeye bakıyorsunuz demektir. Ele geçirilmiş bir posta hesabı da DMARC'tan geçer, çünkü gerçekten sizin sunucunuzdan gönderir. Hesap tarafındaki ilk müdahale adımlarını kurumsal e-posta güvenliği yazısında anlattık. Hacim gerçekten spam'e dönüştüyse sunucu IP'sinin kara listeye girip girmediğini kontrol etmek gerekir.

Elle okumak birkaç kaynağı olan küçük bir alan adı için yeterli. Raporlar çoğaldığında açık kaynaklı parsedmarc gibi ayrıştırıcılar ya da ticari DMARC rapor servisleri verileri tabloya döker. Hızlı bir bakış için şu satır her kayıttaki IP ve ileti sayısını yan yana dizer:

grep -oE '<(source_ip|count)>[^<]*' rapor.xml | paste - -

Raporları bir servise yönlendirmeden önce bir şeyi düşünün. RFC 9989, toplu raporların küçük kuruluşlarda yazışma alışkanlıkları hakkında hassas bilgi açığa çıkarabileceğini not ediyor. Servisin veriyi nerede ve ne kadar süre sakladığını sorun.

Meşru göndericiyi yetkilendirmek

Bülten servisi örneğine dönelim. DMARC'tan geçmesi için iki yol var ve ikisini birden kurmak en sağlamı. Birincisi DKIM: servisin panelinde kendi alan adınız için imzalama açılır, servis size bir ya da birkaç DNS kaydı verir, bunları yayımlarsınız. İmza d=ornek.com.tr ya da onun bir alt alan adıyla atıldığında gevşek modda hizalanır. İkincisi özel zarf adresi: servis geri dönüş adresini bounce.ornek.com.tr gibi sizin alt alan adınıza taşır, SPF o alt alan adında geçer ve hizalanır.

Akla ilk gelen yol, servisin include değerini kökteki SPF kaydına eklemek. Zarf adresi servisin kendi alan adıysa bu adım DMARC'a hiçbir şey kazandırmaz. Üstelik her include, SPF kaydındaki 10 DNS sorgusu sınırından pay alır. Önce DKIM'i kurun, include'u yalnız servis gerçekten sizin alan adınızı zarf adresi olarak kullanıyorsa ekleyin.

Kaynağı meşru ama gereksiz bulduysanız, örneğin artık kullanılmayan bir sunucu hâlâ bildirim gönderiyorsa, en temiz çözüm onu yetkilendirmek değil kapatmaktır.

Politikayı adım adım sıkılaştırmak

Raporları okumanın asıl amacı buraya gelmek. p=none izleme modudur: alıcılar raporlar ama postaya dokunmaz. RFC 9989, alan adı sahibinin tüm postasının doğru doğrulandığından emin olmasının gönderim temposuna göre aylar sürebileceğini açıkça yazar. Biz de takvim yerine raporlara bakmanızı öneriyoruz. Tanıdığınız her kaynak hizalı geçiyorsa ve DMARC'tan kalanlar yalnızca sahtecilik ile bilinen yönlendirmelerden oluşuyorsa sıradaki adıma geçebilirsiniz.

Eski standartta kademeli geçiş pct etiketiyle yapılırdı. RFC 9989 bu etiketi kaldırdı, çünkü 0 ve 100 dışındaki değerler alıcılar arasında tutarlı uygulanmıyordu. Yerine iki değerli t (test) etiketi geldi:

Uygulamada sıra şöyle işleyebilir. Önce v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-rapor@ornek.com.tr ile yeni standardı uygulayan alıcılara "karantinayı deniyorum, henüz uygulama" dersiniz. Raporlarda beklenmedik bir kayıp görmezseniz t=y'yi kaldırırsınız. Aynı adımı p=reject için tekrarlarsınız. Kayıtta sp ile alt alan adlarına ayrı politika vermediyseniz p değeri onlara da uygulanır.

Bu geçiş döneminde iki uyarımız var. RFC 7489'a göre çalışmaya devam eden alıcılar t etiketini tanımaz ve p değerini olduğu gibi uygular. Yeni standardı uygulayan alıcıların da kayıtta kalmış bir pct=25 değerine uymasını beklemeyin. Yani ikisini de güvenlik ağı gibi görmeyin, politikayı ancak raporlar temizken sıkılaştırın.

np etiketinin pratik bir faydası var. Sahteciler çoğu zaman fatura.ornek.com.tr gibi hiç var olmayan alt alan adları uydurur. np=reject yeni standardı uygulayan alıcılara bu adlardan gelen ve DMARC'tan kalan postaları reddetmelerini söyler, ana politikanız henüz none olsa bile.

Raporları başka bir alan adına göndermek

rua adresi kendi kuruluş alan adınızın dışındaysa, mesela raporları bir analiz servisine ya da şirketin ikinci alan adı olan ornek.com'daki bir kutuya yolluyorsanız, alıcılar önce bu yönlendirmeye izin verilip verilmediğini denetler. Bu kural, birinin kaydına rastgele bir kurbanın adresini yazıp onu raporlara boğmasını engellemek için var. RFC 9990'ın dış adres doğrulama bölümüne göre hedef alan adı şu adda bir TXT kaydı yayımlamalıdır:

ornek.com.tr._report._dmarc.ornek.com.  TXT  "v=DMARC1"

Kayıt adı sırasıyla rapor istenen alan adından, _report._dmarc ifadesinden ve raporun gideceği alan adından oluşur. Değer v=DMARC1 ile başlamalıdır. Kayıt yoksa alıcı o adresi yok sayar ve rapor hiç gelmez. Rapor servisleri bu kaydı kendi taraflarında yayımlar, RFC bunun için tüm alan adlarını kapsayan bir joker kaydı da tanımlar. Kendi ikinci alan adınızı kullanıyorsanız kaydı sizin eklemeniz gerekir. Yeni eklediğiniz kaydın neden hemen görünmeyebileceğini TXT kayıtlarının yayılma süresi açıklar.

Raporlar için ayrı bir posta kutusu açmanızı öneririz. Kişisel kutuya gelen günlük XML ekleri hem dikkati dağıtır hem de kotayı doldurur. Netx'in Plesk panelli kurumsal hosting paketlerinde e-posta hesabı sayısı limitsizdir, ama toplam disk alanı pakete bağlıdır. Rapor kutusunun boyutuna arada bir göz atın ve eski raporları arşivleyin.

Düzeldiğini nereden anlarsınız?

Politikayı reject'e taşıdıktan sonraki haftalarda raporlarda şunları görmelisiniz: tanıdığınız her kaynak hizalı pass alıyor, DMARC'tan kalan kayıtların disposition alanında reject ya da quarantine yazıyor ve bu kayıtların IP'leri sizin sınıflandırmanızda sahtecilik grubuna düşüyor. Bülten ya da fatura gibi bir servisten şikâyet gelirse ilk bakılacak yer, o servisin IP'lerinin son raporlarda hâlâ hizalı geçip geçmediğidir.

Raporları politikayı sıkılaştırdıktan sonra da okumaya devam edin. Yeni bir tedarikçi sizin adınıza posta göndermeye başladığında bunu ilk raporlar söyler. Ayda bir raporlara kısa bir bakış, altı ayda bir de politikanın kendisini gözden geçirmek çoğu işletme için yeterli.

Raporlarda tanımadığınız ama sizin altyapınızda olduğundan şüphelendiğiniz bir IP görürseniz Netx müşteri panelinden açacağınız destek talebine alan adını, raporun ilgili record bloğunu, dönemin tarihini ve DMARC kaydınızın güncel hâlini ekleyin. IP'nin hangi hizmetinize ait olduğunu ayırmak için ekibimizin ihtiyaç duyacağı bilgiler bunlardır.