SPF kaydı var, DKIM imzası da aktif; bu iki kaydı doğru yapılandırmış bir domain yöneticisinin "işim bitti" demek için bir nedeni var gibi görünür. Oysa bu ikisi, sahteciliği yalnızca tespit eder; ne yapılacağını söylemez. DMARC tam bu noktaya oturur: kimlik doğrulama başarısız olduğunda alıcı sunucunun nasıl davranacağını politika olarak tanımlar.
Tanımı kısa geçmek gerekirse: DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM sonuçlarını değerlendiren, politika uygulayan ve alan sahibine raporlama yapan bir e-posta kimlik doğrulama protokolüdür. DNS'e tek bir TXT kaydıyla eklenir.
E-posta kimlik doğrulama katmanları: SPF ve DKIM neden tek başına yetmez?
SPF, gönderen IP adresinin yetkili olup olmadığını kontrol eder. DKIM, mesaj içeriğinin bütünlüğünü doğrulayan bir imza taşır. Her ikisi de kendi sınırları içinde çalışır; ancak ne yapılacağına dair bir karar mekanizması içermez. Bir alıcı sunucu, SPF başarısız olsa bile mesajı teslim etmeyi seçebilir; bu tamamen sunucu politikasına kalmıştır.
DMARC bu boşluğu kapatır. Kimlik doğrulama başarısız olduğunda alıcı sunucunun mesajı kabul etmesini, spam klasörüne koymasını ya da reddetmesini domain sahibi belirler. Üstelik bu kararların ne olduğunu, hangi IP'lerden ne kadar mesaj geldiğini raporlar aracılığıyla geri alır.
DMARC olmayan bir domain, sahte gönderici adresiyle üretilmiş phishing mesajlarına karşı teknik olarak savunmasızdır. SPF ve DKIM aktif olsa bile (çünkü saldırgan kendi altyapısını kullanıyorsa SPF kendi sunucusunu geçer, DKIM ise farklı bir domain üzerinden imzalanabilir). DMARC hizalama kuralıyla bu açığı kapatır; ileride ele alınacak.
DMARC kaydının anatomisi: her alan ne anlama gelir?
DMARC kaydı, _dmarc.example.com adresine eklenen bir TXT kaydıdır. Temel bir kayıt şöyle görünür:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-raporlar@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=rHer alan ayrı bir karar içerir. v=DMARC1 zorunlu başlangıçtır. p politikayı belirler: none, quarantine veya reject. pct politikanın kaç yüzde mesaja uygulanacağını söyler; varsayılan 100'dür. rua aggregate (özet) raporların gönderileceği adresi, ruf forensic (olay bazlı) raporları alacak adresi tanımlar. adkim ve aspf hizalama modunu belirler.
p=none ile kayıt eklemek hiçbir şeyi engellemez.
Bu, sıkça gözden kaçan bir noktadır. p=none'da alıcı sunucular mesajlara dokunmaz; yalnızca raporlama aktif olur. Politika geçiş sürecinde başlangıç olarak kullanışlıdır; ancak burada kalmak, DMARC'ı yalnızca izleme aracına dönüştürür. Koruma yok, karar yok.
p=none, p=quarantine, p=reject: hangi politika ne zaman açılır?
reject moduna geçmeden önce söylemek gerekir: acele seçilen p=reject, meşru e-postaları teslim edilmeden düşürebilir. Birçok domain yöneticisi bu hatayı yapıyor. Nedeni basit: SPF veya DKIM yapılandırmasında eksik kalan bir gönderen (üçüncü taraf CRM, marketing platformu, ticket sistemi) DMARC doğrulamasından geçemez ve reject altında mesajları hiç teslim edilmez.
Geçiş sırası genellikle şöyle olur: önce p=none ile en az iki hafta raporları izleyin. Bu sürede hangi IP'lerin, hangi servislerle gönderim yaptığı netleşir. Eksik SPF kaydları ve DKIM yapılandırmaları düzeltilir. Ardından p=quarantine ile pct=10 ya da pct=25 gibi küçük bir yüzdeyle başlanır. Spam klasörüne düşen meşru mesaj var mı izlenir. Sorun yoksa pct kademeli artırılır. Son aşamada p=reject açılır.
Subdomain politikasını ayrıca belirtmek gerekir. sp parametresiyle sp=reject tanımlanmamışsa, subdomainler ana politikadan miras alır (bazı alıcı sunucular bu mirası farklı yorumlar). Özellikle aktif mail göndermeyen ancak phishing için kullanılma riski taşıyan subdomainlere ayrı bir politika atamak mantıklıdır.
Hizalama nedir? strict ve relaxed arasındaki fark
DMARC'ın SPF ve DKIM'den farkı yalnızca politika değil, hizalama kuralıdır. Hizalama, kimlik doğrulama sonucunun From: başlığındaki domain ile eşleşip eşleşmediğini kontrol eder.
strict seçmek güvenli değil, çoğu durumda relaxed yeterli.
SPF için relaxed hizalama (aspf=r), return-path domain'inin From domain'iyle tam eşleşmesini değil, üst domain paylaşımını arar. Yani mail.example.com üzerinden gönderim yapan bir servis, From: example.com ile SPF hizalamasını relaxed modda geçer. strict modda (aspf=s) tam eşleşme gerekir; bu çoğu üçüncü taraf servisin başarısız olmasına yol açar. DKIM hizalaması için de aynı mantık geçerlidir: adkim=r imzalayan domain'in From domain'i ile üst domain paylaşması yeterliyken, adkim=s tam eşleşme ister.
SPF veya DKIM'den en az biri hizalamayla geçerse DMARC doğrulaması başarılı sayılır. İkisi de başarısız olursa politika devreye girer. Alan adının DNS kayıtlarını sorgulamak için mevcut DMARC, SPF ve DKIM kayıtlarının hepsini tek yerden görebilirsiniz.
DMARC raporlarını okuma: aggregate rapor neyi gösterir?
rua adresine gelen aggregate raporlar XML formatındadır ve günlük periyotlarla gönderilir. Her rapor bir organizasyonun (Gmail, Outlook, Yahoo vb.) o gün işlediği mesajların özet istatistiğini taşır.
Raporun içinde şu başlıklar bulunur: policy_published (alıcı sunucunun okuduğu politika); record (her biri bir IP grubuna ait mesajları listeler); auth_results (SPF ve DKIM'in geçip geçmediği); policy_evaluated (DMARC kararının ne olduğu ve hangi politikanın uygulandığı).
XML'i elle okumak pratik değildir. Ücretsiz DMARC rapor işleme servisleri bu XML'leri görselleştirir; ancak raporun ham yapısını bilmek, otomatik ayrıştırmanın neyi kaçırdığını anlamak açısından değerlidir. Pratik öncelik şu: disposition değeri "none" dışına çıktığında, yani quarantine veya reject uygulandığında, bu mesajların kaynaklarını tanımlayıp SPF veya DKIM eksikliğini kapatmak öncelik alır.
ruf adresine gelen forensic raporlar ise bireysel başarısız teslimat olaylarını içerir. Gizlilik nedeniyle birçok büyük e-posta sağlayıcısı bu raporları artık göndermemektedir; aggregate raporlar pratikte daha güvenilir kaynaktır.
Yaygın DMARC hataları ve gözden kaçan durumlar
pct değerini 100'ün altında bırakıp quarantine veya reject ile uzun süre kalmak sık rastlanan bir durumdur. pct=25 ile başlamak akıllıca bir geçiştir; ancak mesajların %75'i politika dışında kalmaya devam eder, yani tam koruma yoktur. İzleme tamamlanınca pct kademeli artırılmalıdır.
E-posta gönderimi yapmayan domainler de DMARC kaydı gerektirir. Yalnızca bir web sitesi barındıran, hiç e-posta göndermediği düşünülen bir domain, sahte gönderici adresi olarak kullanılabilir. Bu domainler için p=reject ve pct=100 başlangıçta güvenlidir; çünkü meşru gönderi yoktur dolayısıyla kayıp riski de yoktur. Alan adının kayıt durumunu ve WHOIS bilgilerini kontrol etmek, domain'in aktif e-posta gönderimi yapıp yapmadığını teyit etmek açısından başlangıç noktasıdır.
Üçüncü taraf gönderim platformları (marketing otomasyon araçları, destek sistemleri, CRM servisleri) çoğunlukla SPF kaydına dahil edilmez ya da DKIM imzası doğru domain üzerinden yapılandırılmaz. Bu eksiklikler p=none aşamasında raporlarla görünür hale gelir; p=reject sonrasında ise sessiz teslimat sorununa dönüşür. Sertifika geçerliliğini ve zincirini periyodik olarak kontrol etmek gibi domain sağlığına dair kontroller yapılandırma eksiklerini bulmak için düzenli yapılmalıdır.
DMARC, SPF ve DKIM üzerinde çalışan bir üst katmandır; üçü birden doğru yapılandırıldığında domain sahteciliği önemli ölçüde kısıtlanır. Bununla birlikte hiçbiri, kötü niyetli gönderilerin tümünü engelleyen tam bir kalkan değildir: alıcı sunucuların politikayı uygulamayı seçmesi, kullanıcının phishing bağlantılarına tıklamaması ve DNS altyapısının güvenliği farklı katmanlardır. DMARC, e-posta güvenliğinin teknik temelinin en kritik parçalarından birini oluşturur; ancak güvenliğin tamamını değil.