DMARC toplu raporlarını gönderici kararına dönüştürün

1. İşi ve kanıt sınırını tanımlayın

Günlük raporlar birleştirilirken aynı zaman aralığı iki kez sayılmadan, XML saldırı yüzeyi açılmadan ve kaynak IP otomatik olarak kötü niyetli ilan edilmeden hangi gönderici grupları incelenmelidir?

Başlamadan önce karar sahibini, kabul eşiğini, başarısızlıkta yapılacak işlemi ve saklanacak artifact’leri yazın. Böylece araç sonucu sonradan amaca göre yorumlanmaz.

2. Hazırlık ve doğrulama yöntemi

1. XML dosyalarını dış varlık ve DOCTYPE kullanımına kapalı biçimde ayrıştırın; bozuk dosyayı kısmi başarı gibi göstermeyin.
2. report_id, org_name, tarih aralığı ve içerik parmak izleriyle tekrarları belirleyin; örtüşen dönemleri metriklerden ayrı görünür tutun.
3. SPF ve DKIM sonucunu From alanına uyum bağlamında değerlendirin; yalnız authentication pass sayısını DMARC uyumu sanmayın.
4. Kaynak gruplarını hacim, politika disposition ve tutarlı başarısızlık örüntüsüyle önceliklendirin; IP sahipliği veya niyet hakkında kanıtsız hüküm vermeyin.

Bozuk, eksik veya kapsamı karşılaştırılamayan girdide güvenilir karar üretilemiyorsa süreç fail-closed kalmalıdır. INDETERMINATE, eksik kanıtı PASS gibi göstermemek için gerçek bir sonuç sınıfıdır.

3. Cerrahi rollout sırası

1. Rapor posta kutusundan alınan dosyaları tarih ve alıcı kaynağıyla ayrı bir çalışma klasöründe toplayın.
2. Dosya boyutu, XML yapısı, DOCTYPE ve tekrar kontrolleri başarısızsa analizi durdurun ve nedeni kaydedin.
3. Hacimli failure gruplarını bilinen gönderici envanteri, SPF include zinciri ve DKIM selector kayıtlarıyla eşleştirin.
4. Değişiklik gerekiyorsa DNS sahibi ve e-posta sağlayıcısıyla kontrollü rollout hazırlayın; doğrudan reject politikasına sıçramayın.
5. Sonraki rapor döneminde aynı grubu yeniden ölçün; receipt zinciriyle önceki kararın hangi girdiye dayandığını koruyun.

4. Kaçınılacak kısa yollar

5. Güvenli işlenmiş örneği yeniden üretin

Önce sentetik fixture byte’larını doğrulayın, sonra Türkçe çalışma tezgâhında yükleyin. Üretilen artifact’lerin hash’lerini receipt ile karşılaştırın; sayfadaki açıklamayı yeni bir run sonucu sanmayın.

• pass.xmlSHA-256 5897bf1ffeb488e0ee35fdd9e06c33f80be58fe180028b82017832966259924b
• blocked-doctype.xmlSHA-256 7993a02e313748dfabcd2e2034c87bb917a5b08758c24a1b3f2d260f69efe52e

Fixture beklenen davranışı göstermiyorsa gerçek veriye geçmeyin. Sorunu, tarayıcı sürümünü, dosya hash’ini ve gözlenen sonuç sınıfını düzeltme kanalına ekleyin.

6. Kabul, durdurma ve kayıt kararı

PASS yalnız seçili politika içinde kabul anlamına gelir. BLOCK, tanımlı eşik aşıldığı için ilerlemenin durmasıdır. INDETERMINATE ise girdinin veya motor kanıtının güvenilir karar için yetersiz olduğunu söyler. Her üç sonuçta da exact input hash, artifact hash’leri, araç sürümü, varsayımlar ve sınırlar korunmalıdır.

Yöntem sınırı ve gizlilik

Bu araç DNS kaydı sorgulamaz veya değişiklik yapmaz, IP’nin sahibini ya da niyetini belirlemez, spoofing olayını kanıtlamaz ve teslimat garantisi vermez. Aggregate raporların kendisi kişisel veya kurumsal açıdan hassas sayılabilir; kurum politikasına göre işlenmelidir.

Ham kullanıcı girdisi analitiğe gönderilmemelidir. Dosya adı, sorgu metni, kişisel veri veya içerik byte’ları yerine yalnız allowlist tool slug, result sınıfı, artifact sayısı ve sample işareti gibi operasyonel alanlar kullanılmalıdır.

Kaynaklar

• RFC 9989: DMARC politika ve authentication modeli
• RFC 9990: DMARC aggregate raporlama
• RFC 7208: SPF
• RFC 6376: DKIM