DMARC Raporları Nasıl Yapılandırılır ve Yorumlanır?

Sesli Dinle — Makale

DMARC (Domain-Based Message Authentication, Reporting, and Conformance) raporları, alan adınız kullanılarak hangi sistemlerden e-posta gönderildiğini ve alıcıların bu iletileri nasıl doğruladığını gösterir.

SPF (Sender Policy Framework), gönderen IP adresinin denetlenen alan adı için e-posta gönderme yetkisini kontrol eder. DKIM (DomainKeys Identified Mail), iletiye eklenen alan adı imzasının geçerliliğini denetler. DMARC, başarılı doğrulamadaki alan adı ile iletinin görünen From (Gönderen) alan adının eşleşme koşulunu karşılayıp karşılamadığına bakar. Bu karşılaştırmaya alan adı hizalaması denir.

Güncel DMARC yapısında çekirdek protokol, İnternet standart belgeleri olan RFC (Request for Comments) serisindeki RFC 9989'da; toplu raporlar RFC 9990'da; iletiye özgü hata raporları ise RFC 9991'de tanımlanır.

DMARC raporlaması, toplu rapor hedefini belirleyen rua ve isteğe bağlı olarak iletiye özgü hata raporu hedefini belirleyen ruf etiketleriyle yapılandırılır. Bir raporu yorumlarken yalnız pass (başarılı) veya fail (başarısız) değerine bakmak yeterli değildir. Kaynak IP adresini, ileti sayısını, ham kimlik doğrulama sonuçlarını ve DMARC hizalamasını birlikte değerlendirin.

DMARC Raporlamasını Kurma ve Sonuçları Değerlendirme

• Toplu XML raporları için DMARC kaydına rua hedefi eklenir; etiket yoksa alıcılar alan adı için toplu rapor üretmez.
• İleti düzeyindeki ayrıntılı hata raporları gerekiyorsa ruf kullanılır; bu raporların gönderilmesi alıcı kuruluşun politikasına bağlıdır.
• fo etiketi, hata raporunun hangi başarısızlık koşullarında istendiğini belirtir ve ruf bulunmadığında dikkate alınmaz.
• Rapor adresi farklı bir kuruluş alan adındaysa, raporu alacak hizmetin yöneticisi kendi DNS bölgesinde harici rapor hedefini onaylayan kaydı yayımlar.
• XML yorumunda kaynak IP adresi ve hacim, yalnız SPF ve DKIM'in ham sonuçlarına göre değil, DMARC hizalama sonuçlarıyla birlikte değerlendirilmelidir.
• Politikayı tek bir rapora göre değiştirmeyin; birden fazla raporlama döneminden ve alıcıdan gelen tutarlı eğilimleri esas alın.

rua, ruf ve fo Etiketleri Nasıl Yapılandırılır?

Raporlama etiketleri, alan adının mevcut DMARC TXT kaydına eklenir. Buradaki amaç DMARC kaydının bütün etiketlerini baştan kurmak değil, raporların nereye gönderileceğini ve hata raporlarının hangi koşullarda istendiğini belirlemektir.

rua ile Toplu Rapor Hedefini Belirleme

DMARC kaydındaki rua etiketi, toplu raporların gönderileceği bir veya daha fazla URI’yi (Uniform Resource Identifier) belirtir. E-posta ile teslimatı belirten mailto: URI'si kullanılır; birden fazla hedef virgülle ayrılabilir. Rapor hacmi yüksek olabileceğinden bu adresin normal kullanıcı posta kutusundan ayrı tutulması, ek dosya boyutu sınırlarının ve depolama kapasitesinin izlenmesi gerekir.

Toplu raporlar genellikle bir günlük dönemi kapsar, ancak rapor üreticileri daha kısa aralıklar kullanabilir. Eski kılavuzlarda görülen ri ve rf etiketleri artık güncel DMARC kayıt etiketleri arasında yer almaz. ri etiketi güncel standartta rapor aralığını belirlemek için kullanılmaz; hata raporu biçimi de rf yerine RFC 9991'e göre belirlenir.

ruf ve fo ile Hata Raporu Koşullarını Belirleme

DMARC kaydındaki ruf etiketi, belirli bir ileti veya aynı nedenle başarısız olan küçük bir ileti grubu hakkında ayrıntılı hata raporu istenmesini sağlar. Bu etiket bir talep ifade eder; alıcı kuruluş rapor üretmeyebilir, içeriği azaltabilir veya gizlilik politikası nedeniyle hata raporlamasını tamamen kapatabilir.

fo etiketinin varsayılan değeri 0'dır. Bu değer, SPF ve DKIM mekanizmalarının hiçbirinin hizalanmış bir geçiş sonucu üretmediği durumda DMARC hata raporu talep eder. Değer 1 olduğunda temel mekanizmalardan herhangi biri hizalanmış geçiş üretmezse rapor istenir; d ve s değerleri ise sırasıyla DKIM ve SPF'ye özgü başarısızlık raporlarını talep eder. Birden fazla değer iki nokta ile ayrılır; 0 ve 1 aynı etikette birlikte kullanılamaz. d ve s seçeneklerinde hizalamadan bağımsız olarak ilgili doğrulama başarısızlığı esas alınır.

Raporlama odaklı örnek: v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-failure@example.com; fo=0

Bu örnek yalnız etiketlerin birlikte nasıl yazıldığını gösterir. Gerçek alan adında adreslerin, mevcut politikanın ve kurumsal veri işleme kurallarının ayrıca doğrulanması gerekir. Yalnız toplu rapor isteniyorsa ruf ve fo çıkarılabilir.

Harici Rapor Adresinin Yetkilendirilmesi

Rapor adresi ile DMARC kaydının bulunduğu alan adı farklı kuruluş alan adlarına bağlıysa alıcı e-posta sistemi harici hedefi DNS üzerinden doğrular. Rapor alıcısı, kendi DNS bölgesinde politika alan adını _report._dmarc etiketi ve hedef alan adıyla birleştiren doğrulama adında v=DMARC1 ile başlayan bir TXT kaydı yayımlar. Örneğin politika example.com alanında, hedef de reports.example.net üzerindeyse sorgulanan ad example.com._report._dmarc.reports.example.net olur.

Bu onay doğrulanamazsa rapor üreticisi ilgili rua hedefine rapor gönderemez. Aynı doğrulama ilkesi ruf hedefleri için de geçerlidir; böylece üçüncü bir alan adına istenmeyen rapor yükü veya hassas hata raporu yönlendirilmesi önlenir.

Toplu Raporlar ile Hata Raporları Arasındaki Farklar

İki rapor türü, DMARC değerlendirmesini farklı ayrıntı düzeylerinde gösterir. Toplu raporlar düzenli görünürlük ve eğilim analizi için temel kaynaktır; hata raporları ise sınırlı, hedefli teşhislerde daha fazla ayrıntı sağlayabilir.

Toplu raporlar bireysel kullanıcı adreslerini veya ileti gövdesini içermez. Buna rağmen kaynak sunucu IP adresleri, gönderim hacimleri ve hizmet ilişkileri kurumsal altyapı hakkında bilgi verebilir; rapor adresi ve saklama alanı buna göre korunmalıdır.

DMARC XML Raporu Nasıl Okunur?

XML dosyası genellikle bir alıcı kuruluşun belirli raporlama döneminde gördüğü trafiği gruplar. Dosya GZIP ile sıkıştırılmış olabilir; açıldıktan sonra önce raporun kimden geldiği ve hangi dönemi kapsadığı, ardından her kaynak IP adresi için oluşturulan kayıtlar incelenir.

Rapor işleme sisteminde XML ve GZIP ekleri için dosya boyutu, açılmış veri miktarı, XML ayrıştırma kaynakları ve işlem süresi sınırı belirleyin. Sıkıştırma bombası, aşırı büyük XML ve sahte rapor verisi olasılığı nedeniyle raporları kesin kanıt saymayın; doğrulanması gereken dış veri olarak işleyin.

Rapor Üreticisi ve Uygulanan Politika

report_metadata bölümünde raporu oluşturan kuruluş, rapor kimliği, iletişim adresi ve UTC aralığı bulunur. Aynı rapor kimliğinin yeniden gelmesi yinelenen teslimata işaret edebilir; dönemler kısmen çakışıyorsa toplam hacmi iki kez saymamak gerekir.

policy_published bölümü, alıcı sistemin değerlendirme sırasında gördüğü DMARC politikasını gösterir. Alan adı, p, sp, np, adkim, aspf, fo ve testing gibi alanlar, rapordaki yapılandırmanın beklediğiniz DNS kaydıyla uyuşup uyuşmadığını kontrol etmenizi sağlar.

Kaynak IP Adresi ve İleti Hacmi

Her record içinde source_ip, alıcıya bağlanan gönderim sistemini; count ise aynı değerlendirme kombinasyonuna giren ileti sayısını gösterir. Aynı IP adresi için DKIM, SPF, hizalama veya uygulanan işlem sonuçları değişiyorsa adres birden fazla satırda yer alabilir.

Kaynak IP adresi, gönderim sisteminin yetkili veya kötü niyetli olduğuna karar vermek için tek başına yeterli değildir. Önce IP adresinin kendi sunucunuza, kullandığınız e-posta hizmetine, pazarlama platformuna, destek sistemine veya unutulmuş bir üçüncü taraf entegrasyonuna ait olup olmadığını doğrulayın.

Ham SPF ve DKIM Sonuçları ile DMARC Hizalaması

auth_results alanı SPF ve DKIM doğrulamasının ham sonucunu gösterir. DKIM kaydında imzadaki d= alan adı ve seçici, SPF kaydında ise SMTP oturumundaki MAIL FROM kimliği için değerlendirilen alan adı yer alır.

policy_evaluated içindeki dkim ve spf değerleri ise bu ham sonuçların DMARC alan adı hizalamasını geçip geçmediğini gösterir. Ham doğrulama ile DMARC hizalaması aynı sonuç değildir. Bir DKIM imzası pass olsa da imzadaki d= alan adı görünür From alan adıyla hizalanmıyorsa bu imza DMARC geçişi sağlamaz. Başka bir geçerli ve hizalanmış DKIM imzası varsa DMARC yine DKIM üzerinden geçebilir. Aynı şekilde SPF pass sonucu, MAIL FROM alan adı görünür From alan adıyla hizalanmadığında DMARC geçişi sağlamaz.

DMARC'ın geçmesi için hizalanmış SPF ve DKIM sonuçlarından en az birinin başarılı olması yeterlidir. İki yöntem de başarısızsa kayıt DMARC denetiminden geçemez. disposition alanı, alıcının ileti grubu için kaydettiği sonucu pass, none, quarantine veya reject değerlerinden biriyle gösterir. DMARC başarısız olduğu halde uygulanan işlem yayımlanan politikadan farklıysa reason alanı bunun gerekçesini belirtmelidir. Yönlendirme, posta listesi, test modu veya yerel politika bu gerekçeler arasında bulunabilir.

Yetkisiz Gönderim ile Hatalı Yapılandırma Nasıl Ayrılır?

Yetkisiz gönderimle yapılandırma hatasını ayırmak için önce meşru gönderim envanterini çıkarın. Tanımadığınız bir kaynak doğrudan saldırı kanıtı değildir; yeni bir hizmet, e-posta hizmetinin değişen IP adresi havuzu, yönlendirme veya unutulmuş bir entegrasyon aynı görünümü oluşturabilir.

• Bilinen kaynakta ham SPF veya DKIM sonucu başarısız: SPF kapsamı, DKIM anahtarı, seçici, DNS yayılımı veya imzalama işlemi hatalı olabilir.
• DKIM pass, DMARC DKIM fail: Geçerli DKIM imzalarının hiçbiri görünür From alan adıyla hizalanmıyor demektir. Üçüncü taraf hizmetin sizin alan adınızla DKIM imzalaması gerekebilir.
• SPF pass, DMARC SPF fail: Gönderen IP adresi MAIL FROM alan adı için yetkilidir, fakat bu alan adı görünür From alan adıyla hizalanmıyordur. Özel dönüş yolu veya alan adı yapılandırmasını inceleyin.
• Bilinmeyen kaynak, SPF ve DKIM hizalaması fail: Yetkisiz kullanım, yönlendirme veya envantere henüz eklenmemiş bir hizmet söz konusu olabilir. Kaynağı ve başarısızlığın nedenini doğrulamadan saldırı sonucuna varmayın.
• Bilinmeyen kaynak, hizalanmış geçiş: Kaynak otomatik olarak meşru sayılmamalıdır. Ele geçirilmiş hesap, sızdırılmış API anahtarı veya yetkili hizmette kötüye kullanım ihtimalini araştırın.
• Hacimde ani değişim: Artışın kampanya, sistem geçişi veya teslimat tekrarlarıyla açıklanıp açıklanamadığını kontrol edin. Diğer alıcıların raporlarıyla ve önceki dönemlerle karşılaştırın.

DMARC Raporlarına Göre Politika Değişikliği

Rapor verisi, meşru gönderim kaynaklarını doğrulamak ve hatalı kaynakları düzeltmek için kullanılır; tek başına daha sert politikaya geçme gerekçesi değildir. Politikayı değiştirmeden önce aşağıdaki noktaları kontrol edin.

1. Kaynak IP adreslerini ve gönderen hizmetleri kurumsal envanterle eşleştirin; bilinmeyenleri hizmet sahipleriyle doğrulayın.
2. Bilinen kaynaklarda SPF yetkilendirmesini, DKIM imza alanını, seçiciyi ve From ile hizalamayı düzeltin.
3. Değişiklikten sonra birkaç raporlama dönemi boyunca aynı kaynakların hizalanmış geçiş üretip üretmediğini izleyin.
4. Alan adınızın _dmarc adındaki TXT kaydını sorgulayarak değişikliğin DNS'te beklenen biçimde göründüğünü doğrulayın.
5. Meşru trafiğin istikrarlı biçimde geçtiği doğrulandıktan sonra politika değişikliğinin teslimat etkisini değerlendirin ve değişikliği kontrollü biçimde uygulayın.

Bir düzeltmenin başarılı sayılması için yalnız genel DMARC geçiş oranına bakmayın. Kritik hizmetlerin her birinin beklenen DKIM alanıyla, SPF dönüş yoluyla ve kaynak IP adresi grubuyla eşleştiğini ayrıca kontrol edin.

p=reject politikasına geçerken yalnız SPF başarısına güvenmeyin. Güncel DMARC standardı, bu politikayı kullanan alan adlarının iletilerine geçerli DKIM imzaları eklemesini zorunlu tutar. Yönlendirme ve posta listeleri üzerinden giden meşru iletilerin durumunu da değerlendirin.

Hata Raporlarında Hassas Verileri Koruma

Hata raporları ileti başlıklarını, gönderici ve alıcı tanımlayıcılarını, iz bilgilerini ve bazı durumlarda ileti içeriğini taşıyabilir. Bu nedenle ruf, sürekli ve geniş kapsamlı izleme için uygun değildir; belirli bir sorunu çözmek üzere sınırlı süreyle ve kontrollü biçimde kullanılabilir.

Raporlardan sorumlu ekip posta kutusuna erişimi sınırlandırmalı, saklama süresini belirlemeli ve inceleme için gerekmeyen başlık ile gövde bilgilerini çalışma kopyalarından çıkarmalıdır. Raporları başka bir ekiple paylaşırken aktarımı TLS ile şifreleyen bir kanal kullanın. Birçok büyük alıcı e-posta hizmeti hata raporlarını kısıtladığı veya göndermediği için ruf bulunması tam kapsam garantisi vermez.