DMARC Raporu Nasıl Okunur ve Yorumlanır?

DMARC kaydınızı DNS’e eklediğiniz an, dünyanın dört bir yanındaki alıcı posta sunucuları size düzenli olarak rapor göndermeye başlar. Birkaç gün içinde gelen kutunuza google.com, outlook.com, yahoo.com gibi kaynaklardan sıkıştırılmış XML ekleri düşmeye başlar. İlk kez açan çoğu kişi bu dosyaya bakıp “burada ne yazdığını nasıl anlayacağım?” diye düşünür. Bu yazının amacı tam olarak bu: ham DMARC raporunu satır satır sökmek ve her alanın gerçekte ne anlattığını göstermek.

Rapor okumayı öğrenmek teknik bir merak meselesi değildir. DMARC dağıtımının en kritik aşaması olan p=none gözlem döneminde, hangi sistemlerin sizin alan adınız adına posta gönderdiğini yalnızca bu raporlar sayesinde keşfedebilirsiniz. Bu envanteri çıkarmadan uygulama (enforcement) politikasına geçerseniz, kendi fatura sisteminizin veya bülten servisinizin postalarını yanlışlıkla karantinaya attırma riski taşırsınız.

DMARC raporu tam olarak nedir?

DMARC (Domain-based Message Authentication, Reporting and Conformance) iki şey yapar: bir yandan alıcılara “benim adıma gelen ama doğrulamayı geçemeyen postalara şunu yap” der, öte yandan alıcılardan bu doğrulamaların sonuçlarını size geri raporlamasını ister. İşte bu ikinci kısım, DMARC’ı sadece SPF ve DKIM’den ayıran özelliktir. Görünürlük olmadan hiçbir e-posta güvenlik politikasını güvenle sıkılaştıramazsınız.

İki tür rapor vardır ve karıştırılmaları çok yaygındır:

Özellik	Toplu Rapor (RUA)	Adli Rapor (RUF)
DNS etiketi	rua=	ruf=
Ne içerir?	IP başına istatistik özeti (sayı, sonuç)	Tek tek başarısız postanın örneği
Gönderim sıklığı	Genellikle günde bir	Olay anında (gönderiliyorsa)
Mesaj içeriği	Yok	Başlık ve kısmi içerik olabilir
Yaygınlık	Neredeyse tüm büyük sağlayıcılar gönderir	Gizlilik nedeniyle çoğu sağlayıcı artık göndermez

Pratikte çalışmanızın %95’i toplu raporlar (RUA) üzerinden yürür. Adli raporlar (RUF) KVKK/GDPR gibi gizlilik düzenlemeleri nedeniyle son yıllarda büyük ölçüde terk edildi; birçok sağlayıcı artık hiç RUF göndermiyor. Bu yüzden bu yazıda ağırlığı toplu rapora veriyoruz.

XML dosyasının anatomisi: üç ana bölüm

Bir DMARC toplu raporu, teknik karmaşasına rağmen üç mantıksal bölümden oluşur. Bunları bir kez oturttuğunuzda gerisi kolaylaşır.

1) report_metadata — raporu kim, ne zaman gönderdi?

Dosyanın başındaki bu blok, raporun kimliğini taşır. Kritik alanlar:

• org_name: Raporu üreten alıcı kuruluş (örneğin Google, Microsoft).
• email: İtiraz veya soru için iletişim adresi.
• report_id: Raporun benzersiz kimliği.
• date_range: Raporun kapsadığı zaman aralığı (Unix zaman damgası olarak begin ve end). Genellikle 24 saatlik bir dilimdir.

2) policy_published — alıcı sizin politikanızı nasıl gördü?

Bu bölüm, alıcının rapor anında DNS’inizde okuduğu DMARC kaydını yansıtır. Kendi kaydınızın alıcı tarafından doğru çözümlenip çözümlenmediğini buradan denetlersiniz:

• domain: Politikanın uygulandığı alan adı.
• p: Ana politika — none, quarantine veya reject.
• sp: Alt alan adları için politika.
• pct: Politikanın uygulandığı posta yüzdesi (örn. pct=25 ise postaların yalnızca %25’ine uygulanır).
• adkim / aspf: DKIM ve SPF hizalama modu — r (gevşek) veya s (katı).

3) record — asıl veri burada

Raporun kalbi <record> bloklarıdır. Her blok, benzersiz bir “gönderen IP + doğrulama sonucu” kombinasyonunu temsil eder. Tipik bir kayıt şöyle görünür:

<record>
  <row>
    <source_ip>192.168.42.17</source_ip>
    <count>120</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>alanadiniz.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>alanadiniz.com</domain><result>pass</result></dkim>
    <spf><domain>bounce.saglayici.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Kritik alanları tek tek yorumlamak

Yukarıdaki örneği anlamlı hale getirelim. Her alanın “ne söylediğini” bilmek, sizi ham veriden karara götüren köprüdür.

Alan	Ne anlatır?	Nasıl yorumlanır?
source_ip	Postayı gönderen IP adresi	Bu IP size ait mi? Bülten servisiniz mi, yoksa tanımadığınız bir kaynak mı?
count	Bu kombinasyona uyan posta sayısı	Hacim anomalisi göstergesidir; ani yükselişler dikkat ister.
disposition	Alıcının uyguladığı gerçek eylem	none/quarantine/reject — politikanızın sahada karşılığı.
policy_evaluated > dkim	Hizalı DKIM sonucu	DKIM imzası hem geçerli hem de From alanıyla hizalı mı?
policy_evaluated > spf	Hizalı SPF sonucu	SPF geçti ama zarf alan adı From ile hizalı mı?
header_from	Kullanıcının gördüğü From alan adı	DMARC hizalamasının referans noktasıdır.
auth_results	Ham SPF/DKIM sonuçları	Hizalamadan önceki “çıplak” doğrulama; sorunun kaynağını gösterir.

Hizalama (alignment): en çok kafa karıştıran nokta

DMARC’ın can alıcı kavramı hizalamadır ve raporları yanlış okuyan çoğu kişi burada takılır. Bir postanın DMARC’ı geçmesi için SPF veya DKIM’in yalnızca teknik olarak geçmesi yetmez; geçen alan adının, kullanıcının gördüğü header_from alan adıyla hizalı olması gerekir.

Yukarıdaki örneğe dönelim: SPF bounce.saglayici.net için geçmiş, ama header_from alanadiniz.com. Bu iki alan adı farklı olduğu için SPF hizalaması fail gelir; nitekim policy_evaluated içinde SPF fail görünür. Ancak DKIM, doğrudan alanadiniz.com için geçtiğinden hizalı sayılır ve bu posta DMARC’ı geçer. Kural nettir: SPF ya da DKIM’den en az biri hizalı geçerse posta DMARC’ı geçer; ikisi de hizasız düşerse başarısız olur.

Hizalama modu da bunu etkiler. aspf=r (gevşek) ise posta.alanadiniz.com ile alanadiniz.com hizalı sayılır; aspf=s (katı) ise birebir aynı olmaları gerekir. Rapordaki beklenmedik fail’lerin önemli bir kısmı, aslında yanlış yapılandırılmış hizalama modundan kaynaklanır.

Raporu okurken hangi desenleri ararsınız?

Ham veriyi tabloya çevirdikten sonra üç tip desen aramaya odaklanın:

• Tanıdık göndericiler, başarısız hizalama: Kendi CRM’iniz veya fatura sisteminiz DMARC’ı düşürüyorsa, o sistemin SPF kaydınıza eklenmesi veya DKIM imzalamasının açılması gerekir. Bu, uygulamaya geçmeden önce çözmeniz gereken meşru bir sorundur.
• Bilinmeyen kaynak IP’leri, yüksek sayı: Tanımadığınız bir IP sizin header_from‘unuzla yüksek hacimde posta gönderip doğrulamayı düşürüyorsa, bu genellikle bir taklit (spoofing) veya oltalama kampanyasının işaretidir. DMARC’ın koruma sağladığı asıl senaryo budur.
• Hacim anomalileri: Normalde günde 200 posta atan bir kaynağın aniden 20.000’e çıkması, ele geçirilmiş bir sistemi veya izinsiz kullanımı düşündürmelidir.

Neden manuel okuma ölçeklenmez?

Tek bir XML dosyasını elle sökmek öğreticidir ve bu yazıda tam olarak bunu yaptık. Ama gerçek dünyada küçük bir kuruluş bile ayda yüzlerce rapor dosyası biriktirir. Onlarca sağlayıcıdan gelen sıkıştırılmış ekleri tek tek açıp IP’leri karşılaştırmak sürdürülebilir değildir. Bu noktada iki yol vardır:

1. Bir DMARC analiz servisi kullanmak: Raporlar özel bir rua adresine yönlendirilir, servis XML’leri ayrıştırıp okunabilir panolar sunar. Öğrenme aşamasından çıkıp operasyona geçtiğinizde pratik seçenektir.
2. Sağlam bir e-posta altyapısıyla baştan doğru kurmak: Raporların büyük kısmı zaten SPF/DKIM’i düzgün yapılandırılmamış sistemlerden kaynaklanan gürültüdür. Doğru kurulmuş bir posta altyapısı bu gürültüyü baştan azaltır.

Alastyr’ın kendi geliştirdiği, %100 KVKK uyumlu mail altyapısı tam da bu ikinci yaklaşımı hedefler. SPF, DKIM ve DMARC kayıtlarının doğru kurgulanması, sektörün en yüksek gelen kutusu (inbox) oranlarından birinin arkasındaki temel nedenlerden biridir. E-posta gönderim itibarınızı sıfırdan sağlam kurmak isterseniz e-posta hosting çözümlerimizi inceleyebilir; kurumsal ölçekte tam kontrol için VPS sunucu veya bulut sunucu seçeneklerine bakabilirsiniz. Alan adınızın DNS ve WHOIS bilgilerini yönetmek için de alan adı sorgulama ve WHOIS sorgulama araçlarımız hazır.

Rapordan aksiyona: pratik yol haritası

Rapor okumanın kendisi bir amaç değil, aracıdır. Süreci şöyle işletin:

1. p=none ile başlayın; teslimatı etkilemeden veri toplayın.
2. Birkaç hafta boyunca raporları düzenli okuyun, tüm meşru göndericilerinizin tam envanterini çıkarın.
3. Hizalamayı düşüren her meşru sistemi düzeltin (SPF’e ekleyin, DKIM açın).
4. Güven kazandıkça düşük bir pct ile p=quarantine‘e geçin.
5. Raporlar temiz kaldığında p=reject‘e yükselerek tam koruma sağlayın.

Sıkça Sorulan Sorular

DMARC raporu ile SPF ve DKIM arasındaki fark nedir?

SPF ve DKIM postanın kimliğini doğrulayan mekanizmalardır. DMARC bu iki mekanizmanın sonucunu birleştirir, hizalama kuralı uygular ve en önemlisi sonuçları size raporlar. SPF ve DKIM tek başına size görünürlük sağlamaz; hangi IP’lerin adınıza posta attığını yalnızca DMARC raporundan öğrenirsiniz.

Toplu (RUA) ve adli (RUF) rapor arasındaki fark nedir?

Toplu rapor, IP başına istatistik özeti verir ve mesaj içeriği içermez; neredeyse tüm büyük sağlayıcılar gönderir. Adli rapor ise tek tek başarısız postaların örneğini içerir, ancak gizlilik düzenlemeleri nedeniyle çoğu sağlayıcı artık göndermez. Pratikte çalışmanızın büyük kısmı toplu raporlar üzerinden yürür.

DMARC raporunun içinde e-postalarımın metni yer alır mı?

Hayır. Toplu (RUA) raporlar istatistiksel özetlerdir; içinde e-posta gövdesi, konu satırı veya alıcı adresi bulunmaz. Yalnızca kaynak IP, mesaj sayısı, doğrulama sonuçları ve uygulanan eylem yer alır. Bu, KVKK ve gizlilik açısından önemli bir güvencedir.

Raporda hem SPF hem DKIM “pass” görünüyor ama posta neden DMARC’ı geçemedi?

Çünkü DMARC teknik geçişten değil, hizalamadan geçmiş olmayı arar. SPF veya DKIM geçebilir ama doğrulanan alan adı, kullanıcının gördüğü From alan adıyla hizalı değilse DMARC yine de başarısız olur. Bu tablodaki en yaygın kafa karışıklığıdır; her zaman hizalanmış sonucu, yani policy_evaluated bölümünü esas alın.

DMARC hizalaması (alignment) tam olarak nedir?

Hizalama, SPF veya DKIM’de doğrulanan alan adının, kullanıcının gördüğü From başlığındaki alan adıyla eşleşmesidir. Gevşek (r) modda alt alan adları da eşleşmiş sayılır; katı (s) modda birebir aynı olmaları gerekir. Bir posta DMARC’ı geçmek için en az bir hizalı geçişe ihtiyaç duyar.

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

Önce bu IP’nin gizli bir meşru gönderici olup olmadığını araştırın; birçok kuruluş kendi kullandığı bülten, fatura veya CRM servislerini unutur. Meşru ise SPF/DKIM’e ekleyin. Tanımadığınız bir IP yüksek hacimde adınıza posta atıp doğrulamayı düşürüyorsa, bu genellikle bir taklit veya oltalama girişimidir ve DMARC politikanızı sıkılaştırmanız için nedendir.

Raporları elle okumak yerine bir araç kullanmam şart mı?

Öğrenme aşamasında birkaç raporu elle sökmek çok faydalıdır ve mekanizmayı gerçekten anlamanızı sağlar. Ancak ölçekte ayda yüzlerce dosya biriktiğinde manuel okuma sürdürülemez; bu noktada bir DMARC analiz servisi XML’leri ayrıştırıp okunabilir panolar sunarak işinizi kolaylaştırır.

DMARC politikasını doğrudan p=reject ile başlatabilir miyim?

Teknik olarak mümkündür ama önerilmez. Meşru göndericilerinizin tam envanterini çıkarmadan reject’e geçerseniz, kendi fatura veya bülten sistemlerinizin postalarını reddettirme riski taşırsınız. Doğru yol p=none ile başlayıp raporları okumak, sorunları düzeltmek, sonra kademeli olarak quarantine ve reject’e geçmektir.

Alastyr’ın e-posta altyapısı DMARC uyumunu nasıl kolaylaştırır?

Alastyr’ın kendi geliştirdiği, %100 KVKK uyumlu mail altyapısında SPF, DKIM ve DMARC kayıtları doğru kurgulanacak biçimde tasarlanmıştır. Bu doğru temel, sektörün en yüksek gelen kutusu oranlarından birinin arkasındaki nedenlerden biridir ve rapordaki “gürültüyü” baştan azaltarak yorumlamayı kolaylaştırır.