Alan adınızdan hiç göndermediğiniz halde müşterinize sizden gelmiş gibi görünen bir e-posta ulaşabilir. SPF, DKIM ve DMARC bu taklidi azaltmak için birlikte çalışır; ancak yalnız DNS’e bir DMARC kaydı eklemek, sistemi otomatik olarak anlaşılır hâle getirmez. Asıl görünürlük, alıcı sunucuların gönderdiği toplu raporlardadır. Bu sıkıştırılmış XML dosyaları ilk bakışta gürültülü görünür; doğru sırayla okunduğunda hangi IP’nin sizin adınıza posta yolladığını ve doğrulamanın nerede kırıldığını gösterir.

Mayıs 2026’da yayımlanan IETF RFC 9990, DMARC toplu raporlamasını Standards Track belgesi olarak tanımladı ve eski RFC 7489’un ilgili bölümünü RFC 9989 ve RFC 9991 ile birlikte değiştirdi. Standarda göre rapor XML biçimindedir; gönderici IP’si, mesaj sayısı, uygulanan politika, SPF ve DKIM sonuçları ile bunların görünen From alanıyla hizalanıp hizalanmadığını içerebilir. Bu veri e-posta içeriğini okumak için değil, posta akışının kimliğini topluca ölçmek içindir.

Önce üç katmanı ayırın

SPF: Bu kaynak gönderim yapabilir mi?

SPF, zarf göndericisi için kullanılan alan adı veya IP’nin yetkili olup olmadığına bakar. Bir SaaS fatura sistemi, e-bülten hizmeti ya da destek platformu sizin alan adınız adına gönderim yapıyorsa SPF zincirinde doğru biçimde yer almalıdır. “SPF pass” tek başına DMARC geçişi değildir; doğrulanan alan adının kullanıcıya gösterilen From alanıyla hizalanması gerekir.

DKIM: İmza doğru ve alanla uyumlu mu?

DKIM, mesajın belirli bir alan adına ait kriptografik imzasını doğrular ve içeriğin imzadan sonra değiştirilip değiştirilmediğini sınar. Rapor içindeki domain, selector ve result alanları hangi imzanın değerlendirildiğini gösterir. DKIM geçse bile imza alanı görünen göndericiyle hizalı değilse DMARC yine başarısız olabilir.

DMARC: Geçiş ve hizalama birlikte mi?

DMARC, SPF veya DKIM yollarından en az birinin hem doğrulamayı geçmesini hem de görünen gönderici alanıyla hizalanmasını ister. Politika none, quarantine ya da reject olabilir; ancak doğrudan en sert politikaya geçmek meşru servisleri kesebilir. Önce raporu okuyup gerçek göndericileri envantere almak gerekir.

Bir XML raporunu beş adımda okuyun

1. Raporun kimliğini ve tarih aralığını doğrulayın

report_metadata bölümündeki kurum adı, benzersiz rapor kimliği ve zaman aralığını kontrol edin. RFC 9990, zaman aralığının UTC cinsinden epoch saniyeleriyle ifade edildiğini ve genellikle tek bir UTC gününü kapsadığını belirtir. Aynı raporu iki kez saymamak için rapor kimliğini kayıt altında tutun.

2. Yayımlanan politikayı kontrol edin

policy_published alanı alıcının alan adınız için gördüğü politikayı taşır. Buradaki p, alt alan politikası ve hizalama kipleri, DNS’te yayımladığınızı düşündüğünüz değerlerle aynı mı? Fark varsa önce DNS önbelleği, yanlış bölge veya birden fazla DMARC kaydı ihtimalini araştırın. Aynı ad altında birden fazla DMARC TXT kaydı bırakmak güvenilir bir yapı değildir.

3. En yüksek hacimli kaynak IP’lerden başlayın

Her record satırında source_ip ve count değerleri bulunur. Önce hacme göre sıralayın; yüz bin meşru iletiyi etkileyen yanlış yapılandırma, tek bir şüpheli denemeden operasyonel olarak daha acil olabilir. IP’yi tanımadığınız için hemen saldırgan ilan etmeyin: kullandığınız e-posta sağlayıcısı, CRM veya destek platformuna ait olabilir.

4. Politika sonucu ile ham doğrulamayı karıştırmayın

policy_evaluated bölümündeki DKIM ve SPF değerleri DMARC hizalama sonucunu anlatır. auth_results ise ham DKIM ve SPF doğrulamalarını gösterir. “DKIM pass ama DMARC fail” gördüğünüzde imzanın alan adına bakın; çoğu zaman sorun imzanın başka bir hizmet alanına ait olmasıdır. Benzer biçimde SPF geçebilir, fakat zarf alanı görünen göndericiyle uyuşmayabilir.

5. İstisna nedenini okuyun

Alıcı, yayımlanan politikadan farklı bir sonuç uyguladıysa raporda reason yer alabilir. Yerel politika, iletme veya posta listesi gibi bir istisna görülebilir. Bu alanı yok saymak, gerçek bir yapılandırma hatasını alıcı davranışı sanmanıza yol açar. Tek bir sağlayıcıdaki istisnayı genellemeden önce farklı alıcılardan birkaç günlük raporu karşılaştırın.

Türkiye’deki işletme için güvenli geçiş planı

E-ticaret, e-fatura, destek ve pazarlama sistemleri çoğu işletmede farklı tedarikçilerden gelir. Bu nedenle alan adı ekibinden “SPF var” yanıtını almak yeterli değildir. Finans, pazarlama ve destek ekiplerinden kullanılan tüm gönderim servislerini listeleyin; her servis için sahip, gönderim alanı, DKIM seçicisi ve beklenen günlük hacmi yazın. Cloudflare’ın 5 Mayıs 2026’da güncellenen DMARC Management belgesi, hizmetin Cloudflare DNS kullanan tüm planlarda raporları kaynak bazında izlemeye yardımcı olduğunu belirtiyor; ancak aynı okuma mantığı başka analiz araçlarında da geçerlidir.

Raporlar gönderici IP’leri ve posta akışı hakkında operasyonel bilgi içerdiği için erişimi sınırlandırın. Ham XML eklerini rastgele çevrimiçi dönüştürücülere yüklemeyin. Kurum içi araç veya sözleşmeli bir hizmet kullanın; saklama süresini belirleyin. DNS güvenliğinin yalnız DMARC’tan ibaret olmadığını unutmamak için CAA kaydı rehberindeki yetki sınırlandırma yaklaşımını da alan adı envanterinize ekleyebilirsiniz.

Haftalık DMARC kontrol listesi

  • Rapor kimliği ve UTC tarih aralığıyla mükerrer dosyaları ayırın.
  • Yayımlanan politika değerini canlı DNS kaydıyla karşılaştırın.
  • Kaynak IP’leri hacme göre sıralayıp her birini bilinen servis envanteriyle eşleştirin.
  • Ham SPF/DKIM sonucu ile DMARC hizalama sonucunu ayrı sütunlarda tutun.
  • Bilinmeyen kaynağı en az iki alıcının raporunda ve birkaç gün boyunca gözlemleyin.
  • Meşru akışlar düzelmeden p=reject politikasına geçmeyin.

Sonuç: rapor, politikanın emniyet kemeridir

DMARC kaydı alıcılara niyetinizi söyler; toplu rapor ise bu niyetin gerçek posta trafiğinde ne yaptığını gösterir. 2026 standardı raporun yapısını daha açık ve ayrı bir Standards Track belgesine taşıdı. En güvenli uygulama, önce kaynakları ve hizalama hatalarını görünür kılmak, sonra politikayı kademeli sıkılaştırmaktır. XML’i bir hata listesi gibi değil, alan adınız adına konuşan sistemlerin envanteri gibi okuyun.

Kaynaklar: IETF RFC 9990, DMARC Aggregate Reporting, Mayıs 2026; IETF RFC 9989, DMARC, Mayıs 2026; Cloudflare DMARC Management, 5 Mayıs 2026 güncellemesi.