Mail Server’da DMARC Aggregate Rapor Okuma Rehberi

DMARC (Domain-based Message Authentication, Reporting, and Conformance), e-posta sunucularında sahte e-postaları önlemek ve alan adınızın itibarını korumak için kritik bir protokoldür. Aggregate raporlar, DMARC politikanızın haftalık performansını özetleyen XML tabanlı belgelerdir. Bu raporlar, e-posta trafiğinizin SPF, DKIM ve DMARC kontrollerine göre nasıl işlendiğini gösterir. Mail sunucunuzda bu raporları okumak, olası sorunları erken tespit etmenizi ve politikalarınızı optimize etmenizi sağlar. Bu rehber, kurumsal ortamda aggregate raporları adım adım okuma becerisini kazandırmak üzere hazırlanmıştır. Raporun yapısını anlayarak başlayıp pratik analiz tekniklerine geçeceğiz.

DMARC Aggregate Raporunun Temel Yapısı

Aggregate raporlar, XML formatında gönderilir ve genellikle haftalık periyotlarda e-posta sağlayıcılarından (örneğin Gmail, Microsoft) gelir. Raporun kök elementi <feedback> olup, içinde <report_metadata>, <policy_published> ve <record> bölümleri bulunur. Mail sunucunuzun rapor alma adresine (rua= etiketinde belirtilen) gelen bu XML dosyalarını incelemek için basit bir metin editörü veya XML viewer kullanabilirsiniz. Yapıyı anlamak, trafiğinizin genel resmini çizer: Hangi domain’lerden e-posta geldiği, doğrulama oranları ve politikaya uyma durumu.

Raporun boyutu trafiğinize göre değişir; yoğun sunucularda binlerce <record> içerebilir. Önce <report_metadata> ile raporun kimden, ne zaman geldiğini doğrulayın. Ardından <policy_published> bölümünde domain’iniz, SPF/DKIM hizalama kuralları (alignment mode: relaxed/strict) ve yayınlanan politika (none/quarantine/reject) belirtilir. Bu temel yapı, raporun güvenilirliğini teyit eder ve analiz için zemin hazırlar. Pratikte, raporları düzenli arşivleyerek trendleri izleyin; örneğin, reject oranı artıyorsa SPF kayıtlarınızı gözden geçirin.

Rapor Bileşenlerini Detaylı Okuma

Report Metadata ve Policy Published İncelemesi

<report_metadata> bölümü, raporun gönderici organizasyonunu (org_name), başlangıç/bitiş tarihlerini (date_range) ve e-posta sayısını (count) içerir. Örneğin, bir raporda “org_name: google.com” ve “count: 15000” görürseniz, Google üzerinden geçen 15 bin e-postanın özetini aldığınızı bilirsiniz. Bu, trafiğinizin hacmini anlamanıza yardımcı olur. <policy_published> ise domain_policy ve pct (yüzde) değerlerini verir; pct=100 ise politikanın tamamı uygulanmış demektir. Bu bölümleri okuyarak raporun kapsamını ve geçerliliğini hızlıca değerlendirin – tarih aralığı güncel değilse rapor eski kabul edilir.

Record Breakdown ve Authentication Detayları

Her <record>, tek bir IP/source_domain’den gelen e-postaları gruplar. İçinde <identifiers> (header_from, envelope_to), <auth_results> (SPF/DKIM passed/failed) ve <policy_evaluated> (disposition, reason) bulunur. Örneğin, SPF=pass, DKIM=fail ve DMARC=reject ise, o kayıtta politika ihlali var demektir. Row_count ile bu grubun e-posta sayısını, policy_evaluated.dsp ise son kararını (none/quarantine) öğrenin. Bu detaylar, sorunlu IP’leri bloklamak için idealdir; fail oranı yüksekse o kaynağı kara listeye alın.

Volume ve Failure Metrikleri Analizi

Rapor genelinde volume (toplam e-posta), SPF/DKIM/DMARC failure oranlarını hesaplayın. Araçsız manuel inceleme için <record>’ları filtreleyin: Pass oranı %90 üzerindeyse sistem sağlıklıdır. Failure reason’lar (örneğin “spf_fail”) spesifik sorunları işaret eder. Pratik takeaway: Haftalık raporlarda %5’ten fazla fail varsa, DKIM anahtarlarınızı yenileyin veya SPF include’ları düzeltin. Bu metrikler, sunucunuzun güvenliğini nicel olarak ölçer.

Pratik Analiz Adımları ve Optimizasyon İpuçları

Rapor okuma sürecini standartlaştırın: 1) XML’i açın ve metadata’yı doğrulayın. 2) Policy published’ı politika kayıtlarınızla karşılaştırın (TXT kaydını sorgulayın). 3) Record’ları gruplayın: Pass/fail oranlarını Excel’e aktarın veya grep ile filtreleyin. 4) Trend analizi yapın – önceki haftalarla kıyaslayın. Bu adımlar, 10 dakikada kapsamlı inceleme sağlar. Örnek: Bir raporda envelope_from’unuz spoof edilmişse, rua adresinizi gizli tutun (mailto:[email protected] yerine).

1. Raporu indirin ve parse edin.
2. Fail record’ları listeleyin (reason=spf_fail filtrele).
3. IP bazında bloklama kararları alın.
4. Rua/rr (forensic) ayarlarını güncelleyin.

İpuçları: Aggregate raporları forensic raporlarla (rifa=) tamamlayın; aggregate genel, forensic bireysel fail’leri gösterir. Sunucunuzda Postfix/Exim kullanıyorsanız, DMARC milter ile raporları otomatik işleyin. Düzenli okuma, phishing saldırılarını %80 azaltır – somut olarak, fail trafiğini sıfırlayınca deliverability’niz yükselir.

Sonuç olarak, DMARC aggregate raporlarını ustalıkla okumak, mail sunucunuzun güvenliğini proaktif yönetmenizi sağlar. Bu rehberdeki adımları uygulayarak politikalarınızı güçlendirin, trafiğinizi optimize edin ve itibarınızı koruyun. Düzenli pratikle, raporlar stratejik içgörü kaynağına dönüşür.