DMARC Raporları: Aggregate ve Forensic Analiz ile p=none’dan p=reject’e Geçiş

DMARC raporlarını gerçekten okumak neden bu kadar önemli

DMARC kaydını DNS’e ekleyip politikayı p=none bıraktıktan sonra çoğu kurum aynı yerde takılıyor: Posta kutularına her gün onlarca, bazen yüzlerce DMARC raporu düşüyor, ama kimse bu raporları sistematik biçimde okumuyor. Sonuç olarak da DMARC ayarları yıllarca görünürlük modunda kalıyor, sahtecilik ve kimlik avı riski azalmıyor, e-posta itibarı ise tam potansiyeline ulaşamıyor.

Oysa DMARC raporları; hangi IP’lerden, hangi servislerden, hangi alan adları adına e-posta gönderildiğini; SPF ve DKIM kayıtlarınızın gerçekten işe yarayıp yaramadığını ve DMARC’nin bu sonuçları nasıl yorumladığını günlük olarak önünüze serer. Yani doğru okunduğunda, p=none’dan p=reject’e güvenle geçmek için ihtiyacınız olan tüm veriyi zaten elinize vermektedir.

Bu yazıda DCHost ekibi olarak, DMARC aggregate (RUA) ve forensic (RUF) raporlarını pratik biçimde nasıl okuyabileceğinizi; sahtecilik girişimlerini iyi niyetli ama yanlış yapılandırılmış kaynaklardan nasıl ayırabileceğinizi ve politikayı kademeli olarak p=reject seviyesine nasıl taşıyabileceğinizi adım adım anlatacağız. Zaten SPF ve DKIM temellerini kurduysanız, DMARC rapor analizi ile bu altyapıyı güvenlik ve teslim edilebilirlik açısından üst seviyeye çıkarabilirsiniz.

Kısa hatırlatma: DMARC, SPF, DKIM ve hizalama

Detaylı DMARC rapor analizine girmeden önce birkaç kavramı netleştirmek önemli. SPF, hangi IP’lerin alan adınız adına e-posta göndermeye yetkili olduğunu; DKIM ise e-posta içeriğinin sizden çıktıktan sonra değiştirilmediğini kriptografik imza ile kanıtlar. DMARC ise bu iki mekanizmanın sonuçlarını birleştirip, alıcı tarafa şu soruyu yanıtlar: Bu mesaj gerçekten bu alan adına mı ait, değilse ne yapmalıyım.

DMARC tarafında kritik kavram, hizalama (alignment). Özetle:

• SPF hizalaması: MAIL FROM veya Return-Path alanındaki alan adı, From başlığındaki alan adı ile aynı kökten geliyor mu
• DKIM hizalaması: DKIM imzasındaki d= alan adı, From başlığındaki alan adı ile aynı kökten geliyor mu

DMARC kaydınızda p=none iken, alıcılar mesajı sadece raporlar; p=quarantine veya p=reject olduğunda ise hizalama başarısızsa DMARC politikanıza göre spama atar ya da tamamen reddeder. Eğer SPF ve DKIM temellerini tazelemek isterseniz, daha önce hazırladığımız SPF, DKIM ve DMARC nedir rehberine göz atmanız faydalı olacaktır.

DMARC rapor türleri: Aggregate (RUA) ve Forensic (RUF)

DMARC raporları iki ana türe ayrılır:

• Aggregate raporlar (RUA): Günlük özet raporlardır. Genellikle XML formatında gelir ve belirli bir zaman aralığında alan adınız adına gönderilen tüm e-postaları IP, gönderen servis, SPF/DKIM sonuçları ve DMARC kararı bazında özetler.
• Forensic raporlar (RUF): Tekil mesaj bazlı hata raporlarıdır. DMARC başarısız olduğunda, ilgili mesajın başlıklarını ve bazen gövde özetini içerir. Hata analizinde oldukça detaylı bilgi verir, fakat hacim ve gizlilik nedeniyle dikkatli yönetilmesi gerekir.

DMARC DNS kaydınızda bunları şu etiketlerle tanımlarsınız:

• rua=mailto:[email protected]
• ruf=mailto:[email protected]

Genellikle güvenli bir başlangıç için önce sadece RUA tanımlayıp birkaç hafta sadece aggregate raporları toplamak, daha sonra gerektiğinde RUF raporlarını açmak en pratik yaklaşımdır.

Aggregate (RUA) DMARC raporlarını okumak

Aggregate raporlar ilk bakışta göz korkutucu olabilir; çünkü XML formatında ve genellikle ham haliyle okunması zor dosyalardır. Çoğu kurum bu nedenle onları doğrudan bir klasöre bırakıp unutuyor. Ancak yapı aslında oldukça düzenlidir ve birkaç temel alanı tanıdığınızda tablo gözünüzde netleşir.

Aggregate rapor yapısını anlamak

Tipik bir RUA raporunda şu bloklar bulunur:

• report_metadata: Raporu gönderen sağlayıcı, rapor id’si ve kapsadığı zaman aralığı
• policy_published: Sizin DNS’te yayınladığınız DMARC kaydının o anki hali (p, sp, adkim, aspf, pct gibi alanlar)
• record: Asıl faydalı kısım. Her record bir kaynak IP ya da kaynak sunucu grubu için özet veriyi içerir.

Record içindeki kritik alanlar ise şunlardır:

• row.source_ip: Hangi IP’den gönderim yapıldığı
• row.count: İlgili IP’den gelen kaç mesaj olduğu
• policy_evaluated.disposition: DMARC’in bu mesajlar için verdiği karar (none, quarantine, reject)
• policy_evaluated.dkim / spf: DKIM ve SPF sonuçları (pass veya fail)
• identifiers.header_from: From başlığındaki alan adı
• auth_results.dkim / spf: Detaylı SPF ve DKIM sonuçları

Bu alanları tabloya döktüğünüzde, alan adınız adına gerçekte kimlerin e-posta gönderdiğini, hangi IP’lerden çıktığını ve hangi mesajların DMARC açısından sorunlu olduğunu çok net görebilirsiniz.

Analize pratik bir başlangıç: Kaynak envanteri çıkarma

İlk adım, raporlardaki tüm benzersiz kaynak IP ve gönderen servisleri gruplayarak bir gerçek hayat gönderen envanteri çıkarmaktır. Çoğu kurum bu aşamada şu sürprizlerle karşılaşıyor:

• Eski bir pazarlama otomasyon aracının hâlâ alan adınız adına e-posta atması
• Geliştirici ekibin test amaçlı kurduğu ama unutulan SMTP servisleri
• Yanlış yapılandırılmış bir CRM veya helpdesk yazılımı
• Farkında olunmayan üçüncü taraf sistem bildirimleri

Bu envanteri ikiye ayırın:

• Yetkili ve kalıcı gönderenler: Kurumsal posta sunucunuz, pazarlama platformlarınız, ERP/CRM bildirimleri gibi
• Yetkisiz veya gereksiz gönderenler: Eski servisler, test ortamları, saldırı amaçlı denemeler

Yetkili gönderenler için SPF ve DKIM hizalamasını düzeltmek; yetkisiz gönderenler için ise trafiği kesmek veya alan adınızı kullanmalarını önleyecek ek önlemler almak, p=reject’e giden yolun temel taşlarını oluşturur.

SPF ve DKIM hizalamasını rapor üzerinden okumak

RUA raporlarında SPF ve DKIM ile ilgili iki önemli sütun grubu görürsünüz:

• auth_results altındaki SPF/DKIM sonucu: Teknik olarak SPF ve DKIM’in geçip geçmediğini gösterir.
• policy_evaluated.spf / dkim: DMARC açısından hizalamanın da başarıyla sağlanıp sağlanmadığını gösterir.

Örneğin:

• auth_results.spf = pass, policy_evaluated.spf = fail ise, SPF teknik olarak geçiyor ama alan adı hizalaması tutmuyor demektir.
• auth_results.dkim = pass, policy_evaluated.dkim = pass ise, hem DKIM imzası hem de hizalama başarılı demektir.

p=none aşamasında hedefiniz, yetkili tüm gönderenler için en az bir tanesinin (SPF veya DKIM) hem pass hem de aligned olmasını sağlamak. İdeal senaryo ise ikisinin de hizalı şekilde geçmesidir.

Aggregate raporlardan aksiyon listesi çıkarmak

Pratik bir yöntem olarak, her bir RUA raporu dönemini (örneğin haftalık) şu sorularla tarayın:

1. Hangi IP’ler alan adım adına en çok e-posta gönderiyor ve bunlar gerçekten onaylı mı
2. Yetkili IP ve servisler için SPF ve DKIM hizalaması tam olarak sağlanmış mı
3. DMARC açısından sürekli fail olan ama görece yüksek hacimli kaynaklar var mı
4. Yeni ortaya çıkan, daha önce hiç görmediğiniz IP’ler veya servisler var mı

Bu analiz sonunda elinizde tipik olarak şöyle bir liste oluşur:

• SPF kaydına eklenmesi gereken yeni servisler
• DKIM anahtarı oluşturulması ve DNS’e eklenmesi gereken platformlar
• Kapatılması veya sınırlandırılması gereken eski SMTP servisleri
• Muhtemel kimlik avı denemesi olan IP blokları

DCHost üzerinde çalışan kendi posta sunucunuzu veya VPS’inizi kullanıyorsanız, bu listeyi doğrudan güvenlik ekibiniz ve sistem yöneticilerinizle paylaşarak firewall kuralları, reverse DNS ve gönderim politikalarınızı netleştirebilirsiniz. Örneğin IP itibarı tarafını güçlendirmek için dedicated IP ısıtma ve e-posta itibarı yönetimi rehberimizdeki adımları DMARC verileri ile birleştirmek çok etkili olur.

Forensic (RUF) DMARC raporları: Ne zaman ve nasıl kullanmalı

Forensic raporlar, DMARC başarısız olduğunda tek tek mesaj bazlı olarak gönderilen detaylı raporlardır. Genellikle:

• Mesaj başlıklarının tamamını
• Bazen gövde özetini veya sınırlı bir kısmını
• SPF, DKIM ve DMARC değerlendirme sonuçlarını

içerir. Bu sayede özellikle:

• Gerçek kimlik avı kampanyalarını
• Belirli bir kullanıcıyı hedef alan saldırıları
• Yanlış yapılandırılmış ama önemli bir sistemin ürettiği hatalı trafiği

çok hızlı şekilde teşhis edebilirsiniz.

Forensic rapor açarken dikkat edilmesi gerekenler

RUF raporları çok değerli olmakla birlikte bazı riskler barındırır:

• Gizlilik: Bazı sağlayıcılar mesaj gövdesinin bir kısmını da ekler. Bu nedenle RUF posta kutusunu sadece yetkili güvenlik ve sistem ekiplerinin erişebileceği şekilde tasarlayın.
• Hacim: Özellikle büyük hacimli alan adlarında, yanlış yapılandırılmış bir sistem bir anda binlerce forensic rapor üretip gelen kutusunu doldurabilir.
• Depolama: Mesaj başlıkları zamanla ciddi disk alanı tüketebilir. Bu nedenle iyi bir arşiv ve rotasyon politikası belirleyin.

DCHost tarafında, RUF raporlarını ayrı bir posta kutusunda toplamak için ister paylaşımlı e-posta hosting, ister VPS üzerinde kendi Postfix/Dovecot kurulumunuzu kullanabilirsiniz. Büyük hacimli yapılarda bu posta kutusunu ayrı bir disk havuzunda veya object storage üzerinde arşivlemek, büyüyen log hacmini yönetmeyi kolaylaştırır.

p=none’dan p=reject’e geçiş için adım adım yol haritası

DMARC politikasını doğrudan p=reject yapmak genellikle iyi bir fikir değildir; çünkü yanlış yapılandırılmış meşru sistemlerin mail’leri de bir anda reddedilebilir. Sağlıklı yaklaşım, DMARC raporlarını kullanarak kademeli ve ölçülebilir bir geçiş planı izlemektir.

Aşama 0: Altyapıyı hazırlama

Başlangıçta şu adımların tamamlanmış olması gerekir:

• SPF kaydı güncel, 10 DNS lookup sınırı aşılmayacak şekilde tasarlanmış
• Aktif tüm gönderim servisleri için DKIM anahtarları üretilmiş ve DNS’e eklenmiş
• Temel DMARC kaydı şu tarzda yayınlanmış: v=DMARC1; p=none; rua=mailto:[email protected];
• RUA posta kutusuna erişen teknik ekipler belirlenmiş, raporların işlenmesi için en azından temel bir otomasyon ya da inceleme rutini kurulmuş

SPF tasarımında çoklu servis kullanıyorsanız, lookup limitine takılmamak için gelişmiş SPF yönetimi rehberindeki prensipleri uygulamanız, DMARC sürecini daha sorunsuz hale getirecektir.

Aşama 1: p=none ile görünürlük dönemi (en az 2–4 hafta)

Bu aşamada amaç, hiçbir mesajı fiilen etkilemeden tüm trafiği net biçimde haritalamak ve hizalama sorunlarını düzeltmektir. Yapmanız gerekenler:

• RUA raporlarını haftalık olarak inceleyip gönderen envanterinizi netleştirmek
• Her yetkili gönderici için en az bir mekanizmanın (SPF veya DKIM) hizalı şekilde pass olduğunu doğrulamak
• DMARC tarafında sürekli fail olan kaynakları tespit edip ya yapılandırmasını düzeltmek ya da tamamen devre dışı bırakmak

Bu dönemde raporlardan çıkan sorunları çözerken, teslim edilebilirlik tarafını da gözlemlemeniz faydalı. Örneğin, spam klasörüne giden meşru e-postalar için teslim edilebilirlik kontrol listemizdeki adımları DMARC verileriyle birlikte değerlendirmek, sorunun DNS kaynaklı mı, içerik kaynaklı mı olduğunu daha net ortaya koyar.

Aşama 2: p=quarantine’e ve pct parametresine geçiş

Görünürlük aşamasında yeterince veri topladıysanız ve yetkili tüm gönderenlerde hizalamayı sağladıysanız, artık daha sıkı bir politika uygulamaya başlayabilirsiniz. Pratik bir ara adım:

• p=quarantine; pct=10 ile başlayın. Yani DMARC fail olan mesajların sadece yüzde 10’u karantinaya (spam klasörüne) düşsün.
• RUA ve gerekirse RUF raporlarını birkaç gün yakından takip edin. Beklemediğiniz meşru trafiğin karantinaya girdiğini görürseniz ilgili sistemi düzeltin.
• Sorunları giderdikçe pct değerini kademeli olarak 25, 50, 75 ve sonunda 100’e çıkarın.

Bu aşamada özellikle iki nokta kritiktir:

• Alt alan adı politikası (sp=): Sadece ana alan adınız için mi, tüm alt alan adları için mi sıkı politika uygulayacağınızı netleştirin. Örneğin sp=none ile alt alan adlarını geçici olarak dışarıda bırakabilirsiniz.
• İç sistemler ve gateway’ler: Bazı kurumlarda iç SMTP relay sunucuları From alanını yeniden yazar veya DKIM imzasını bozar. Raporlarda bu tür vakalar tespit ederseniz, gateway yapılandırmasını da DMARC uyumlu hale getirmeniz gerekir.

Aşama 3: p=reject’e kademeli geçiş

Quarantine aşamasında hem teslim edilebilirlik hem de rapor verisi açısından tablo stabil hale geldiyse, artık hedef politikaya geçebilirsiniz. Yine pct parametresi ile kademeli ilerlemek en sağlıklısıdır:

• Önce p=reject; pct=25 ile başlayın.
• RUA ve RUF raporlarını en az 1–2 hafta yakından takip edin. Özellikle önemli iş süreçlerine ait e-postalarda beklenmedik reddedilme var mı kontrol edin.
• Her şey yolundaysa pct’yi 50, sonra 75 ve sonunda 100’e taşıyın.

Bu noktadan sonra DMARC, hizalamayı geçemeyen mesajları alıcılara şu sinyali verir: Bu alan adı adına gelen bu mesajların reddedilmesini istiyorum. Birçok büyük alıcı bu talebe uyduğundan, sahtecilik ve kimlik avı girişimlerinin önemli bir kısmı daha sunucu aşamasında elenir.

Yönlendirme, alias ve üçüncü taraf sistemler için özel durumlar

DMARC geçişinin en zorlu kısımlarından biri, e-posta yönlendirme senaryolarıdır. Birçok durumda:

• Kullanıcıların kişisel adreslerine tanımlı yönlendirmeler
• Mailing list yazılımları
• Eski alias mekanizmaları

SPF hizalamasını bozar. Çünkü mesaj, orijinal sunucudan değil, aradaki yönlendirme sunucusundan çıkmış gibi görünür. Bu durumda DKIM hizalamasını güçlendirmek ve mümkünse ARC gibi mekanizmaları destekleyen modern altyapıları tercih etmek daha kritik hale gelir.

Yönlendirme kaynaklı SPF kırılmalarını ve olası çözümleri detaylı şekilde anlattığımız e-posta yönlendirmede SPF ve DMARC neden kırılıyor rehberine mutlaka göz atmanızı öneririz. DMARC raporlarınızda forward eden sistemleri doğru yorumlayabilmek, p=reject’e geçtiğinizde beklenmedik teslimat sorunlarının önüne geçer.

Rapor okurken sık görülen hatalar

DMARC raporlarıyla çalışan ekiplerde sık gördüğümüz bazı tuzaklar var:

• Sadece SPF’e odaklanmak: Modern ekosistemde yönlendirme ve gateway’ler nedeniyle tek başına SPF’e güvenmek sağlıklı değildir. Raporlarda mutlaka DKIM hizalamasını da inceleyin.
• Alignment sütunlarını gözden kaçırmak: auth_results’taki pass sonucunu görüp policy_evaluated align sütunlarına bakmamak, gerçekte hizalama başarısızken her şey yolundaymış gibi algılanmasına yol açar.
• Forward trafiğini saldırı sanmak: Bazı üniversite ve kurumsal ağlarda yoğun yönlendirme kullanıldığından, DMARC fail görünen ama aslında meşru olan trafik oluşabilir. RUF raporları ve başlık analizi ile bunları ayırmak gerekir.
• Raporları sadece bir sağlayıcının verisine göre değerlendirmek: Farklı alıcılar DMARC’i farklı şekillerde uygular. Mümkün olduğunca çok büyük sağlayıcıdan gelen raporları birlikte değerlendirmek daha gerçekçi bir tablo sunar.
• Raporları bir seferlik kampanya gibi görmek: DMARC rapor analizi, sadece geçiş sürecinde değil, sürekli yapılması gereken bir güvenlik ve teslim edilebilirlik pratiğidir.

DMARC rapor analizi olgunlaştıkça, bu veriyi BIMI gibi marka görünürlüğü özellikleriyle de birleştirmek mümkün. Bu konuda daha ileri seviye bir yol haritası arıyorsanız, gelişmiş DMARC ve BIMI rehberimizde RUA/RUF raporlarından marka göstergesine giden süreci detaylı anlattık.

DCHost altyapısında DMARC verisini kullanmaya dair örnek senaryo

Somut bir örnek üzerinden gidelim. Orta ölçekli bir e-ticaret firması, DCHost üzerinde hem kurumsal web sitesini hem de transactional e-postalarını barındırıyor. Bir süre sonra müşteri hizmetleri, sipariş onay ve şifre sıfırlama e-postalarının bazı kullanıcılarda spam klasörüne düştüğünü fark ediyor. Güvenlik ekibi ayrıca marka adına sahte kampanya mailleri gönderildiğine dair geri bildirimler alıyor.

Alınan aksiyonlar şu şekilde olabilir:

1. Alan adına SPF, DKIM ve p=none DMARC kaydı ekleniyor; RUA raporları DCHost üzerindeki özel bir posta kutusunda toplanıyor.
2. İlk hafta sonunda RUA raporları incelendiğinde, beklenen DCHost SMTP IP’lerine ek olarak eski bir üçüncü taraf servis IP’sinin hâlâ sipariş maili atmaya çalıştığı görülüyor. SPF kaydından bu IP çıkarılıyor, ilgili API anahtarları iptal ediliyor.
3. CRM sisteminin kullandığı alt alan adında DMARC tanımlı olmadığı fark edilip sp=quarantine ile kapsam altına alınıyor.
4. İkinci hafta sonunda yetkili tüm sistemlerde DKIM hizalamasının tam olduğu doğrulanıyor ve p=quarantine; pct=25 ile devreye alınıyor.
5. Raporlarda beklenmedik bir etki görülmeyince pct kademeli olarak 100’e çıkarılıyor, ardından p=reject’e geçiliyor.

Bu süreç sonunda hem sahte kampanya maillerinin etkisi büyük ölçüde azalıyor hem de transactional e-postaların teslim oranı belirgin şekilde iyileşiyor. DCHost altyapısında çalışan MTA logları ile DMARC raporlarını birlikte analiz etmek, hatalı veya zayıf yapılandırılmış IP’lerin hızla iyileştirilmesini sağlıyor.

Sonuç: DMARC raporlarıyla yaşayan bir e-posta güvenlik kültürü kurmak

DMARC çoğu kurum için önce DNS’e eklenen bir TXT kaydından ibaret başlıyor. Gerçek fark ise, bu kaydın ortaya çıkardığı RUA ve RUF raporlarını düzenli olarak okuyup aksiyona dönüştürdüğünüzde ortaya çıkıyor. Aggregate raporlarla gönderen envanterinizi netleştirip SPF ve DKIM hizalamasını olgunlaştırdığınızda; forensic raporlarla da gerçek saldırıları ve kritik hataları yakalamaya başladığınızda, p=none’dan p=reject’e geçiş korkulan bir adım olmaktan çıkıyor.

DCHost olarak, ister paylaşımlı hosting, ister VPS, dedicated sunucu veya colocation altyapınızda kendi MTA’nızı çalıştırıyor olun; DMARC, SPF ve DKIM üçlüsünü doğru kurguladığınızda e-posta altyapınız hem daha güvenli hem de daha itibarlı hale gelir. Sonraki adım olarak DMARC raporlarını BIMI, MTA-STS ve TLS-RPT gibi gelişmiş mekanizmalarla birleştirmek için gelişmiş DNS ayarları rehberimize ve DMARC odaklı teslim edilebilirlik stratejilerine göz atabilirsiniz.

Eğer DMARC raporlarını okumak ve p=reject’e geçiş planını tasarlamak için deneyimli bir ekiple birlikte çalışmak isterseniz, DCHost üzerinden kullandığınız barındırma hizmetiyle entegre, ölçülebilir ve sürdürülebilir bir e-posta güvenlik mimarisini birlikte kurabiliriz.