DMARC raporu, alıcı mail sunucularının alan adınız adına gördükleri mailleri kaynak IP'ye göre gruplayıp SPF, DKIM ve DMARC sonuçlarıyla birlikte size gönderdiği XML dosyasıdır. Okumak için her satırda üç şeye bakarsınız: mail kimden geldi, kaç adet geldi ve görünen alan adınızla uyumlu biçimde doğrulandı mı. Bu üç cevap, p=reject seviyesine güvenle geçip geçemeyeceğinizi gösterir.
DMARC raporları neden okunmadan bekliyor?
Tipik tablo şudur: BT ekibi ya da dışarıdaki bir danışman _dmarc kaydını p=none ve bir rua adresiyle kurmuştur. Kayıtların ne olduğunu ve nasıl kurulduğunu SPF, DKIM ve DMARC rehberimizde anlattık. Ardından o adrese her gün Google, Microsoft, Yahoo ve başka sağlayıcılardan sıkıştırılmış XML ekleri yağmaya başlar. Kimse açmaz; kutu dolar, kayıt aylarca izleme modunda kalır.
Sorun teknik değil, yorumlamadır. Ham XML'de IP adresleri, Unix zaman damgaları ve iç içe geçmiş pass/fail değerleri vardır. Hangi satırın muhasebe yazılımınızın fatura bildirimi, hangisinin sizin adınıza mail atan bir dolandırıcı olduğu ilk bakışta anlaşılmaz. Bu yazı o ayrımı yapmanın yöntemini veriyor.
Raporları okumamanın maliyeti
DMARC'ı izleme modunda bırakmak, alan adınızı taklide açık bırakmak demektir: p=none sahte maili yalnızca raporlar, durdurmaz. EasyDMARC'ın 1,8 milyon alan adını tarayan 2026 DMARC Adoption Report'una göre alan adlarının %52,1'inde DMARC kaydı var, ancak yalnızca yaklaşık %23'ü karantina ya da reddetme politikası uyguluyor.
Aynı rapora göre alan adlarının yalnızca yaklaşık %9'u uygulama politikasını raporlamayla birlikte kullanıyor. (EasyDMARC, 2026 DMARC Adoption Report)
Boşluğun karşılığı somuttur. FBI IC3'ün 2025 Internet Crime Report'una göre en çok şikâyet edilen suç türü 191.561 şikâyetle oltalama/sahte gönderici (phishing/spoofing) oldu. Sizin alan adınızla müşterilere giden sahte bir "hesap numaramız değişti" maili, IBAN değişikliği dolandırıcılığının en kısa yoludur.
Teslim edilebilirlik tarafı da var. Microsoft'un yüksek hacimli göndericiler için duyurusuna göre 5 Mayıs 2025'ten itibaren Outlook.com, Hotmail ve Live adreslerine günde 5.000'den fazla mail gönderen alan adlarından SPF, DKIM ve en az p=none politikalı, SPF ya da DKIM ile uyumlu DMARC aranıyor. Raporu okumadığınızda, uyumsuz kalan meşru gönderici de fark edilmez; o maillerin spama düşmesinin sebebi aylarca bulunamaz. Teslim sorunlarının bütün nedenleri için mailler spama düşüyorsa ne yapmalı yazısına bakın; rapor okuma oradaki adımlardan biridir.
Toplu (rua) DMARC raporunun anatomisi
Toplu rapor, RFC 7489 ile tanımlanan bir XML belgesidir. Genellikle günde bir kez, her raporlayan sağlayıcıdan ayrı gelir ve gzip ya da zip ile sıkıştırılmıştır. Üç ana bölümden oluşur: rapor bilgileri, yayımlanan politika ve her gönderici kaynağı için bir record. Önemli alanlar şunlardır:
| Blok / alan | Ne söyler? | Neye bakmalısınız? |
|---|---|---|
report_metadata → org_name, date_range | Raporu kim gönderdi, hangi zaman aralığını kapsıyor (UTC, Unix zamanı) | Aynı sağlayıcıdan her gün rapor geliyor mu? |
policy_published → p, sp, adkim, aspf, pct | Alıcının o gün DNS'te gördüğü politikanız | Beklediğiniz kayıt mı; alt alan adı politikası (sp) doğru mu? |
row → source_ip, count | Hangi IP'den kaç mail geldi | Hacmi yüksek, tanımadığınız IP'ler |
policy_evaluated → disposition, dkim, spf | DMARC açısından uyumlu sonuç ve maile uygulanan işlem | fail olan ve hacmi yüksek satırlar |
identifiers → header_from | Görünen "Kimden" alan adı | Alt alan adlarınız da görünüyor mu? |
auth_results → dkim / spf altında domain, result | Uyumdan bağımsız ham SPF ve DKIM sonucu, hangi alan adıyla geçtiği | Geçen alan adı sizin mi, hizmet sağlayıcınızın mı? |
Rapor okumanın püf noktası son iki satırdır. auth_results altında spf result=pass görüp rahatlamak sık yapılan hatadır. Eğer SPF'in geçtiği alan adı bülten aracınızın kendi alan adıysa, policy_evaluated altında spf yine fail görünür; çünkü DMARC, doğrulanan alan adının header_from ile uyumlu olmasını ister. Yani belirleyici olan ham sonuç değil, uyumlu sonuçtur.
disposition alanı ise alıcının gerçekte ne yaptığını gösterir: none, quarantine ya da reject. Politikanız p=none iken burada none görmek normaldir. Bazen reason alanında forwarded ya da mailing_list gibi bir gerekçe yer alır; bu, alıcının politikanızı bilinçli olarak esnettiğini anlatır.
Adli (ruf) raporlar
Toplu raporun yanında, DMARC'tan geçemeyen tek tek mesajlar için adli rapor (ruf) da istenebilir. Bu raporlar mesaj başlıklarını, kimi zaman içerik parçalarını taşır. Gizlilik nedeniyle birçok büyük sağlayıcı bu raporları göndermez. Gönderenler için de dikkat: içerdikleri adres ve konu bilgileri kişisel veri olabilir; saklama ve erişim kuralını KVKK uyum süreciniz içinde tanımlayın.
DMARC raporu nasıl okunur? Yedi adımda çalışma yöntemi
- Raporların gerçekten geldiğini doğrulayın.
ruaadresi başka bir alan adındaysa (ör. bir rapor analiz hizmeti), o alan adının sizin raporlarınızı kabul ettiğini gösteren_report._dmarcdoğrulama kaydını yayımlaması gerekir; yoksa sağlayıcılar rapor göndermez. - XML'i elle okumayın, ayrıştırın. Ekleri açıp bir ayrıştırıcıyla tabloya dökün: sağlayıcı, tarih,
source_ip,count,header_from, uyumlu ve ham sonuçlar. Birkaç haftalık veriyi birleştirmeden karar vermeyin. - IP'leri gönderene çevirin. Ters DNS (PTR) ve IP'nin ait olduğu ağ bilgisiyle her kaynağa bir ad verin: "kendi mail sunucumuz", "e-fatura entegratörü", "CRM", "bilinmiyor".
- Uyumlu ve ham sonucu yan yana koyun. Ham
pass, uyumlufailise sorun yetki değil, alan adı eşleşmesidir. - Her kaynağı aşağıdaki gruplardan birine yerleştirin. Aşağıdaki tablo bu sınıflandırmayı veriyor.
- Düzeltmeyi kaynağın sahibiyle yapın. Hizmet sağlayıcıda kendi alan adınızla DKIM imzasını açtırın ya da zarf göndericisini (Return-Path) kendi alt alan adınıza taşıyın.
- Uyumlu geçiş oranını haftalık izleyin. Meşru hacmin tamamına yakını uyumlu geçtiğinde
p=quarantine'e, istikrar sürdüğündep=reject'e geçin; geçişipctile kademelendirebilirsiniz.
Kaynak sınıflandırma tablosu
| Görünüm | Olası anlam | Yapılacak |
|---|---|---|
Kendi IP'niz, uyumlu DKIM ve SPF pass | Sağlıklı meşru trafik | İşlem yok; izlemeye devam |
Tanıdık hizmet, ham pass, uyumlu fail | SaaS aracı kendi alan adıyla imzalıyor | Hizmette özel alan adı DKIM'i ve Return-Path ayarı |
Tanıdık hizmet, SPF ve DKIM fail | Envantere eklenmemiş gönderici | SPF'e ekleyin, DKIM anahtarını DNS'e yayımlayın |
SPF fail, DKIM uyumlu pass, kaynak bir yönlendirme sunucusu | Yönlendirme ya da e-posta grubu | DMARC DKIM sayesinde geçer; DKIM'in her kaynakta açık olduğundan emin olun |
Bilinmeyen IP'ler, her şey fail, dağınık ülke ve ağlar | Alan adınızı taklit eden gönderim | Düzeltmeyin; p=reject tam da bunları durduracak |
En zor karar, "bilinmeyen" ile "unutulmuş" arasındaki ayrımdır. Şüpheli bir IP'yi bir hafta izleyin; hacmi mesai saatlerine uyuyorsa ve kurum içinden biri bir aracı hatırlıyorsa büyük olasılıkla unutulmuş göndericidir. En sık unutulanlar web formu, e-fatura bildirimi ve eski yazıcı-tarayıcı cihazlarıdır; fatura tarafını e-fatura entegrasyonu yazısında anlattık.
Raporda hiç görünmeyen bir saldırı türü de vardır: size benzeyen başka bir alan adından gelen mail. O alan adı sizin değildir, rapor da size gelmez. Bu boşluğu benzer alan adı saldırıları yazısında ele aldık.
Digital Bridge'de DMARC raporlarını nasıl ele alıyoruz?
Bir DMARC projesinin çoğu kayıt yazmak değil, rapor okumak ve gönderici sahipleriyle düzeltme yapmaktır. Siber güvenlik danışmanlığı kapsamında süreci şöyle yürütüyoruz:
- Keşif: Alan adlarınızın mevcut SPF, DKIM, DMARC ve PTR kayıtlarını inceliyor, eldeki raporları ayrıştırıp kaynak listesini çıkarıyoruz.
- Sınıflandırma ve düzeltme: Her kaynağı ekiplerinizle birlikte adlandırıyoruz. ERP, CRM ya da özel yazılımdan giden mailde değişiklik gerekiyorsa sistem entegrasyonları ekibimiz gönderim ayarlarını düzeltir.
- Pilot alan adı: Önce hacmi düşük bir alan adını ya da alt alan adını
rejectseviyesine taşıyıp yöntemi doğruluyor, sonra ana alan adına geçiyoruz. - Süreklilik: Rapor verisini kendi raporlama ortamınızda görmek isterseniz uyumlu geçiş oranını BI dashboard üzerinde izlenecek bir göstergeye dönüştürebiliriz; hangi göstergenin işe yaradığını BI dashboard KPI'ları yazısında tartıştık. Güvenlik olaylarını merkezde topluyorsanız DMARC özetleri SIEM ve log yönetimi akışına da eklenebilir.
Mail altyapınızı taşıyorsanız, eski sunucunun IP'leri raporlarda bir süre görünmeye devam eder; bu geçişi e-posta taşıma rehberimizdeki sırayla planlamak yanlış alarmları azaltır. Hazır paket satmıyoruz; ihtiyaç analizinin ardından kapsamı, aşamaları ve bedeli yazılı teklifle netleştiriyoruz.
Smart360 ve SmartMail ile iki yönlü görünürlük
DMARC raporu, başkalarının sizin maillerinize nasıl baktığını gösterir. Smart360 ailesinin kurumsal e-posta ürünü SmartMail ise işin diğer yarısını, sizin gelen maillere nasıl baktığınızı yönetir:
- Alan adı ve DNS tek panelde: Alan adları ve DNS ayarları, kullanıcılar ve departmanlarla birlikte Smart360 yönetim panelinden yönetilir; raporda çıkan bir eksikliği düzeltirken ayrı bir araca gitmeniz gerekmez.
- Raporlar için ortak kutu:
ruaadresini SmartMail'de bir ortak posta kutusu olarak açıp yalnızca BT ekibine görüntüleme izni verebilirsiniz. Silme yetkisi yeni atamalarda kapalı gelir; raporlar yanlışlıkla kaybolmaz. - Gelen tarafta aynı mantık: SmartMail gelen her maili 12 sinyalle değerlendirir; bunların başında kendi SPF/DKIM/DMARC ve PTR doğrulaması gelir. Benzer alan adı, görünen ad taklidi ve Reply-To uyuşmazlığı da hesaba katılır; DMARC'tan geçen ama size benzeyen bir alan adından gelen mail de işaretlenir. Sonuç gerekçesi yazılı bir rapordur.
Kimlik doğrulama ve alan adı kontrolleri yazılımla yürür; yapay zeka kullanım hakkı dolsa bile çalışır. Kullanıcı tarafında şüpheli maili fark etmenin ipuçları için oltalama maili nasıl anlaşılır yazısına bakabilirsiniz.
Sonraki adım
rua adresinize son bir ayda gelen raporları toplayın ve yukarıdaki yedi adımın ilk üçünü uygulayın; bilinmeyen kaynak listesi kısaldıkça reject kararı kolaylaşır. Alan adını sıfırdan yapılandırıyorsanız alan adlı e-posta kurulumu doğru sırayı gösteriyor; kurumsal e-posta hizmetinizi yeniden seçiyorsanız kurumsal e-posta nasıl seçilir rehberine bakın. Raporlarınızı birlikte ayrıştırıp p=reject takvimi çıkarmak için bizimle iletişime geçin. Konunun diğer başlıkları Kurumsal E-posta ve Belge merkezimizde bir arada.