Adınıza gönderilmiş gibi görünen sahte e-postalar, müşterilerinizin güvenini sarsmakla kalmaz; kimlik avı saldırıları, veri sızıntıları ve doğrudan maddi kayıplarla sonuçlanabilir. DMARC (Domain-based Message Authentication, Reporting and Conformance), alan adınız üzerinden gönderilen e-postaların gerçekten size ait olup olmadığını doğrulayan ve sahtekârlara geçit vermeyen bir güvenlik protokolüdür. Bu yazıda DMARC'in SPF ve DKIM ile nasıl birlikte çalıştığını, politika seviyelerini nasıl kademeli olarak artıracağınızı, raporlama mekanizmalarından nasıl yararlanacağınızı, yapılandırma sırasında karşılaşılan yaygın hataları ve DMARC'in tek başına yetersiz kaldığı senaryoları ele alacağız. Amacımız, markanızı korumak için somut ve uygulanabilir bir yol haritası sunarak e-posta trafiğiniz üzerindeki kontrolü tamamen elinize almanızı sağlamaktır.
SPF ve DKIM Tek Başına Neden Yetersiz Kalır?
Çoğu işletme e-posta güvenliği denince SPF (Sender Policy Framework) ve DKIM (DomainKeys Identified Mail) kayıtlarını yapılandırıp işin bittiğini düşünür. Oysa bu iki protokol yalnızca "kimin göndermeye yetkili olduğunu" ve "mesajın yolda değiştirilip değiştirilmediğini" kontrol eder; alıcı sunucunun bu doğrulama sonuçlarıyla ne yapacağını belirlemez. SPF başarısız olduğunda mesaj yine de gelen kutusuna düşebilir veya DKIM imzası geçersiz çıkmasına rağmen uyarı bile gösterilmeyebilir. DMARC tam bu noktada devreye girer: SPF ve DKIM sonuçlarını bir politika katmanıyla birleştirir ve alıcı tarafa "bu mesajı reddet, karantinaya al ya da kabul et" talimatı verir.
Uzman bakış açısı: SPF ve DKIM olmadan DMARC kurmak, alarm sistemi takmadan güvenlik kamerası asmaya benzer; kayıt tutarsınız ama müdahale edemezsiniz. Üç protokol birlikte çalıştığında zincir tamamlanır.
Örnek: Bir e-ticaret şirketi yalnızca SPF kaydıyla yetinir. Saldırgan, "From" başlığını şirketin alan adını gösterecek şekilde düzenler ama gönderim IP'sini farklı bir sunucudan yapar. SPF doğrulaması başarısız olur ama alıcı sunucu bunu görmezden gelir. DMARC politikası "reject" olsaydı, bu mesaj hiç teslim edilmeyecekti.
Karar kuralı: DMARC'e geçmeden önce SPF ve DKIM'i eksiksiz yapılandırın. Her ikisi de doğru çalışmadan DMARC politikanızı "reject" seviyesine çıkarmak, meşru e-postalarınızın da engellenmesine yol açabilir.
Politika Seviyeleri: none, quarantine ve reject Arasındaki Fark
DMARC politikası, DNS kaydındaki p= etiketiyle belirlenir ve üç seviyeye sahiptir. none (p=none): mesajlar normal şekilde teslim edilir ama raporlama aktif çalışır; yalnızca izleme amaçlıdır. quarantine (p=quarantine): doğrulama başarısız mesajlar spam klasörüne düşürülür veya işaretlenir. reject (p=reject): başarısız mesajlar hiç teslim edilmez, sunucu düzeyinde reddedilir. Çoğu uzman "hemen reject yapın" dese de, bu yaklaşım aceleci yapılandırmalarda meşru e-postaların kaybolmasına yol açabilir.
Uzman bakış açısı: Kademeli geçiş, DMARC'in en az anlatılan ama en kritik stratejisidir. İlk haftalarda "none" ile başlayıp SPF/DKIM hatalarını raporlardan tespit etmek, "reject" seviyesine geçtiğinizde sürpriz yaşamamanızı sağlar.
Örnek: Bir SaaS şirketi tüm e-posta alt yapısını (pazarlama araçları, destek sistemi, fatura servisi) denetlemeden doğrudan "reject" politikasına geçti. Pazarlama e-postaları DKIM imzası taşımadığı için %40 oranında reddedildi ve kampanya sonuçları çöktü. İki haftalık "none" izleme süreci bu kaybı önleyecekti.
Karar kuralı: none → quarantine → reject geçişinde her adımda en az 2-4 hafta raporları inceleyin. "none" aşamasında SPF ve DKIM hata oranınız %2'nin altına düştüğünde bir sonraki seviyeye geçmek güvenlidir.
Raporlama Mekanizması: Gözünüz Kulağınız
DMARC'in en güçlü ama en çok ihmal edilen özelliği raporlama sistemidir. DNS kaydında tanımlanan rua= (toplu raporlar) ve ruf= (adli raporlar) etiketleri, e-posta ekosisteminizde neler olup bittiğini size bildirir. rua raporları, hangi IP adreslerinin sizin adınıza e-posta gönderdiğini ve bunların SPF/DKIM testlerinden geçip geçmediğini XML formatında sunar. Bu raporlar, meşru gönderim yapan üçüncü taraf araçlarınızı (Mailchimp, HubSpot, Zendesk vb.) tanımlamanız için tek yoldur.
Uzman bakış açısı: Ham XML raporlarını okumak zordur. Bu verileri görselleştiren DMARC analiz araçlarını kullanmak, saldırgan IP'leri veya yanlış yapılandırılmış servisleri dakikalar içinde tespit etmenizi sağlar.
Örnek: Bir şirket, raporlarını incelediğinde hiç bilmediği bir IP bloğundan kendi domain'i üzerinden binlerce e-posta gönderildiğini fark etti. Bu, bir saldırganın domain'inizi "spoofing" (taklit) ettiğinin doğrudan kanıtıydı. DMARC sayesinde bu durumun farkına vardılar ve hemen "reject" politikasına geçerek saldırıyı durdurdular.
Karar kuralı: Raporlarınızı mutlaka bir analiz platformuna yönlendirin. Raporları düzenli kontrol etmemek, sisteminizdeki bir güvenlik açığının aylarca fark edilmeden kalmasına neden olabilir.
Yapılandırma Sırasında Karşılaşılan Yaygın Hatalar
DMARC yapılandırmasında yapılan en yaygın hata, "alignment" (hizalama) kurallarını göz ardı etmektir. DMARC, yalnızca SPF ve DKIM'in geçmesini değil, aynı zamanda "From" adresindeki alan adı ile SPF/DKIM imzalarındaki alan adının eşleşmesini bekler. Eğer "From" adresiniz sirket.com iken, e-posta pazarlama.com üzerinden gönderiliyorsa, SPF geçse bile DMARC başarısız sayılır. Ayrıca, DNS kayıtlarında boşluk bırakmak veya yanlış karakter kullanmak kaydın geçersiz kalmasına neden olur.
Uzman bakış açısı: "Relaxed" (gevşek) ve "Strict" (sıkı) hizalama modları arasındaki farkı anlamak kritiktir. Çoğu durumda "relaxed" mod yeterlidir, ancak yüksek güvenlik gerektiren finansal kurumlarda "strict" mod tercih edilmelidir.
Örnek: Bir şirket, DKIM kaydını yanlış yapılandırdığı için e-postaları "fail" alıyordu. Sorunu çözmek yerine DMARC politikasını "none" seviyesinde bıraktılar. Bu, domain itibarının zamanla düşmesine ve e-postaların spam'e düşmesine neden oldu. DKIM anahtarının DNS'te doğru yayınlandığından emin olmak, DMARC başarısının anahtarıdır.
Karar kuralı: Her değişiklikten sonra dig veya nslookup komutlarıyla DNS kayıtlarınızın doğru yayıldığını doğrulayın. Yapılandırma hataları, DMARC'in koruma kalkanını tamamen devre dışı bırakabilir.
DMARC'in Tek Başına Yetersiz Kaldığı Senaryolar
DMARC, "From" başlığındaki sahteciliği durdurmak için mükemmeldir ancak "görünürdeki" sahtecilikleri (display name spoofing) veya "look-alike" (benzer) domain saldırılarını engelleyemez. Örneğin, saldırgan sirket.com yerine sırket.com (i yerine ı harfi ile) domain'i alıp e-posta gönderirse, DMARC bu mesajı meşru olarak doğrular çünkü o domain'in sahibi saldırgandır. Ayrıca, e-posta içeriğindeki linklerin güvenliği veya ekli dosyaların zararlı olup olmadığı DMARC'in kapsamı dışındadır.
Uzman bakış açısı: DMARC, e-posta kimlik doğrulamasının temelidir ancak tek başına bir güvenlik çözümü değildir. Güvenlik katmanlarını, e-posta ağ geçitleri (SEG) ve kullanıcı farkındalık eğitimleri ile desteklemelisiniz.
Örnek: Bir yönetici, CEO'sunun adını taşıyan ama farklı bir domain'den gelen bir e-posta ile dolandırıldı. DMARC bu mesajı "geçerli" olarak işaretledi çünkü saldırgan kendi domain'i için DMARC kurmuştu. Burada çözüm, e-posta sunucularında "Display Name" uyarıları ve gelişmiş tehdit algılama sistemleri kullanmaktır.
Karar kuralı: DMARC'i bir "kimlik doğrulama" katmanı olarak görün. "İçerik güvenliği" için mutlaka ek e-posta güvenlik çözümleri (phishing koruması, URL tarama) ile hibrit bir yaklaşım benimseyin.
Conclusion
DMARC, markanızın dijital itibarını korumak için sahip olduğunuz en güçlü araçtır. SPF ve DKIM ile temelleri atıp, "none" politikasından "reject" seviyesine kontrollü bir geçiş yaparak, sahtekarların alan adınızı kullanmasını imkansız hale getirebilirsiniz. Unutmayın ki DMARC bir "kur ve unut" sistemi değil, sürekli izlenmesi ve raporlanması gereken yaşayan bir güvenlik katmanıdır. Raporlarınızı düzenli analiz ederek meşru e-posta trafiğinizi optimize edebilir ve markanızı kimlik avı saldırılarına karşı zırhlayabilirsiniz. Bugün "none" politikasıyla başlayarak ilk adımınızı atın; birkaç hafta içinde elde edeceğiniz veriler, markanızın e-posta güvenliği için en doğru yol haritasını size sunacaktır. Güvenli bir e-posta ekosistemi, sadece teknik bir yapılandırma değil, müşterilerinize verdiğiniz değerin bir göstergesidir.
Etiketler: DMARC, e-posta güvenliği, SPF, DKIM, siber güvenlik, kimlik avı, domain koruması, e-posta kimlik doğrulama, phishing