DMARC raporları neden önemlidir?
DMARC, alan adınızdan gönderiliyormuş gibi yapılan sahteciliği (spoofing) azaltmak ve alıcıların SPF/DKIM doğrulama sonuçlarına göre tutarlı kararlar almasını sağlamak için kullanılan bir e-posta doğrulama standardıdır. DMARC’nin en pratik tarafı ise raporlamadır: Kimler alan adınızı kullanarak e-posta göndermeye çalışıyor, bu gönderimler SPF ve DKIM’den geçiyor mu, DMARC uyumu (alignment) sağlanıyor mu gibi sorulara veriye dayalı yanıt üretmenizi sağlar.
Bu rehberde DMARC kaydındaki rua (aggregate/toplu rapor) ve ruf (forensic/adli olay raporu) raporlarının nasıl okunacağını, raporlardan kaynakları nasıl tespit edeceğinizi ve en sık görülen yetkilendirme/hizalama problemleri için uygulanabilir bir aksiyon planını ele alacağız.
DMARC raporlama türleri: rua ve ruf
rua: Toplu (aggregate) raporlar
rua ile gelen raporlar genellikle XML formatındadır ve belirli bir zaman aralığındaki (çoğunlukla günlük) özet sonuçları içerir. Bir alıcı kuruluş, sizin DMARC kaydınızda belirttiğiniz adrese rapor gönderir. Bu raporlar tekil e-posta içeriğini değil; kaynak IP’ler, kullanılan kimlikler ve SPF/DKIM/DMARC değerlendirme sonuçları gibi istatistikleri gösterir.
ruf: Olay (forensic) raporlar
ruf raporları, DMARC başarısızlıklarıyla ilgili daha ayrıntılı olay verisi üretmeyi hedefler. Ancak mahremiyet ve veri paylaşımı kısıtları nedeniyle birçok alıcı artık ruf göndermeyebilir ya da içerik kırpılmış olabilir. Ayrıca ruf, operasyonel olarak daha hassastır; istemeden kişisel veri veya mesaj içeriği taşınması riskleri doğurabileceği için şirket içinde politika ve onay süreci gerektirebilir.
Bir DMARC kaydında raporlama alanları nasıl çalışır?
DMARC DNS kaydında raporlama için genellikle şu etiketleri görürsünüz: rua, ruf, fo, adkim, aspf, pct. Rapor okumayı anlamak için bu alanların neyi etkilediğini bilmek gerekir.
- rua: Toplu raporların gönderileceği adres(ler). Birden fazla adres eklenebilir.
- ruf: Olay raporlarının gönderileceği adres(ler). Her alıcı desteklemeyebilir.
- fo: Hangi koşulda olay raporu üretileceğini belirtir (ör. sadece SPF ve DKIM birlikte fail olursa gibi).
- adkim/aspf: DKIM ve SPF için hizalama modunu (relaxed/strict) etkiler.
- pct: Politikanın yüzde kaç trafik için uygulanacağını belirler; raporlama aşamasında kademeli ilerlemede kullanılır.
rua raporunu adım adım okuma: Hangi alanlar ne anlatır?
Aggregate raporlar farklı araçlarla görselleştirilebilir; ancak temel mantık aynı kalır. Aşağıdaki parçalar, raporun yorumlanmasında kritiktir.
1) Rapor metadatası: kim raporluyor, hangi dönem?
Raporun başında raporu üreten kuruluşun bilgisi ve kapsanan zaman aralığı bulunur. Burada asıl hedef, raporların düzenli gelip gelmediğini ve hangi alıcıların veri sağladığını takip etmektir. Bazı alıcılar rapor üretir, bazıları üretmez; bu normaldir.
2) Politika değerlendirmesi: p/quarantine/reject ve disposition
Rapor, sizin yayınladığınız DMARC politikasını (p=none/quarantine/reject) ve alıcının uyguladığı sonucu (disposition) gösterir. Örneğin p=none iken disposition “none” olması beklenir; p=quarantine iken “quarantine” veya “none” gibi varyasyonlar görülebilir. Bu kısım, politikanın sahada nasıl uygulandığını anlamak için önemlidir.
3) Kaynak IP ve hacim: en hızlı kazanım alanı
Raporlarda genellikle source IP (gönderici IP) ve o IP’den gelen count (adet) yer alır. İlk yapılacak iş, yüksek hacimli IP’leri listeleyip bunların hangi sistemlere ait olduğunu eşleştirmektir. Şirketlerin en sık unuttuğu kaynaklar; web sitesi formları, CRM araçları, e-ticaret platformu bildirimleri, canlı destek yazılımları, ERP sistemleri ve üçüncü taraf SMS/e-posta otomasyon servisleridir.
4) Kimlikler: Header From, envelope from ve DKIM d=
DMARC’nin merkezinde Header From (kullanıcının gördüğü alan adı) vardır. Raporlar çoğu zaman SPF’in hangi domain üzerinden kontrol edildiğini (envelope from/return-path) ve DKIM’in hangi domain ile imzaladığını (d=) gösterir. Burada hedef, SPF ve/veya DKIM’in Header From ile hizalı olup olmadığını tespit etmektir.
5) Sonuçlar: SPF pass/fail, DKIM pass/fail ve DMARC pass/fail
DMARC “pass” olması için en az birinin (SPF veya DKIM) hem doğrulamada başarılı olması hem de Header From ile hizalı olması gerekir. Bu nedenle raporda SPF pass görüp DMARC fail görmek mümkündür (hizalama bozuksa). Aynı şekilde DKIM pass olup DMARC fail de görülebilir (d= farklı bir alan adına aitse).
Raporlardan “kim benim adıma gönderiyor?” sorusuna yanıt üretme
Pratikte DMARC raporlarını okumanın amacı bir envanter çıkarmaktır. Aşağıdaki yöntem, IT ekiplerinin hızlı sonuç almasını sağlar.
- IP bazlı sınıflandırma yapın: Şirketin bilinen mail sunucuları, uygulama sunucuları, ofis IP’leri ve üçüncü taraf servis IP’leri olarak gruplandırın.
- Hacmi yüksek ama tanımsız kaynaklara öncelik verin: Bu kaynaklar ya kritik bir iş akışıdır ya da kötüye kullanım belirtisidir.
- Kimlik kombinasyonuna bakın: Header From alan adınız iken return-path veya DKIM d= farklıysa, genellikle yanlış yapılandırılmış bir üçüncü taraf entegrasyonu vardır.
- Her kaynak için hedef durum tanımlayın: “SPF aligned + DKIM aligned”, “en az bir aligned geçsin”, “asla göndermemeli” gibi.
En yaygın DMARC rapor bulguları ve kök nedenler
1) SPF fail veya SPF pass ama hizalama fail
SPF fail genellikle kaynak IP’nin SPF kaydınızda yetkili olmaması demektir. SPF pass olup hizalama fail olması ise return-path domain’inin Header From ile aynı olmaması (ve strict alignment kullanılması) nedeniyle görülür.
Çözüm yaklaşımı: Gönderimi yapan sistemi belirleyin; gerçekten sizin adınıza göndermesi gerekiyorsa SPF tarafında yetkilendirme veya servis sağlayıcının önerdiği yöntemi uygulayın. Eğer üçüncü taraf sizin domaininizle hizalı return-path sağlayamıyorsa, DKIM hizalamasını doğru kurmak daha sürdürülebilir olabilir.
2) DKIM fail veya DKIM pass ama hizalama fail
DKIM fail; imza eklenmemesi, DNS’te DKIM kaydının bulunmaması, selector hatası, anahtar değişimi sırasında kopma veya mesajın yolda değiştirilmesi gibi nedenlerle ortaya çıkar. DKIM pass olup hizalama fail ise d= alanının Header From ile farklı olduğu anlamına gelir.
Çözüm yaklaşımı: Gönderim kaynağında DKIM imzasının gerçekten aktif olduğundan emin olun; DNS’te doğru selector kaydı yayınlayın. Üçüncü taraf servis kullanılıyorsa “custom DKIM” veya alan adınıza ait DKIM imzalama seçeneklerini değerlendirin.
3) Beklenmeyen IP’lerden gelen denemeler
Raporlarda şirketinizin hiç kullanmadığı ülkelerden, hostinglerden veya şüpheli IP bloklarından düşük hacimli ama sürekli denemeler görebilirsiniz. Bu çoğu zaman alan adınızı taklit etme girişimidir.
Çözüm yaklaşımı: DMARC politikanız “none” ise gözlem süresi sonrası quarantine/reject’e geçiş planı oluşturun. Aynı zamanda SPF/DKIM’in doğru çalıştığından emin olmadan reject’e geçmek meşru postaları da etkileyebilir.
DMARC raporlarına dayalı pratik aksiyon planı
1) 1-2 hafta: Envanter ve hızlı düzeltmeler
- Kurumsal gönderim yapan tüm sistemleri listeleyin (CRM, ERP, web formları, uygulama bildirimleri).
- Her sistem için SPF mi DKIM mi hizalama sağlayacak, karar verin.
- Yüksek hacimli kaynaklarda DKIM ve SPF hatalarını düzeltin.
2) 2-4 hafta: Politika sıkılaştırma provası
- DMARC p=none aşamasında raporları stabil hale getirin.
- Eksik kaynak kalmadığından emin olun.
- pct kullanıyorsanız, kademeli artış planı yapın.
3) 1-3 ay: quarantine ve reject’e kontrollü geçiş
- Önce p=quarantine ile başlayın; raporları günlük kontrol edin.
- Yanlış pozitif görmüyorsanız p=reject’e geçin.
- Yeni entegrasyonlar devreye alındıkça DMARC raporlarını tekrar kontrol edin.
Operasyonel ipuçları: raporları sürdürülebilir yönetmek
- Rapor sahipliği belirleyin: DMARC raporlarını kimin izleyeceği ve aksiyon alacağı net olmalı (IT, güvenlik veya e-posta yöneticisi).
- Değişiklik yönetimi uygulayın: SPF/DKIM/DMARC değişiklikleri için kayıt tutun; “küçük DNS değişikliği” büyük kesintilere yol açabilir.
- Yeni sistem eklenince kontrol listesi çalıştırın: Yeni bir SaaS aracı e-posta göndermeye başladığında raporlarda hemen görünür; beklemeden doğrulayın.
Sonuç: DMARC raporları bir uyumluluk değil, bir görünürlük aracıdır
DMARC raporları doğru okunduğunda yalnızca sahteciliği azaltmakla kalmaz; şirketinizin e-posta gönderim mimarisini görünür kılar, teslim edilebilirliği iyileştirir ve yetkisiz kaynakları erken yakalamanıza yardım eder. Düzenli rapor inceleme alışkanlığı, e-posta altyapısında yapılan değişikliklerin etkisini ölçmenin de en güvenilir yollarındandır.
MX1Mail üzerinde alan adınızı doğrulama (SPF/DKIM/DMARC) çalışmalarınızı planlarken, rua raporlarından gelen bulguları bir kontrol listesine dönüştürmek; geçiş ve sonrasında politikanızı güvenle sıkılaştırmanızı kolaylaştırır.