DMARC Kaydı Kurulumu: Politika, Raporlama ve Geçiş

DMARC, e-posta kimlik doğrulama zincirinin politika katmanıdır. SPF ve DKIM size hangi sunucuların yetkili olduğunu ve iletinin imzalanıp imzalanmadığını söyler; DMARC ise bu iki sonucun alan adıyla gerçekten uyumlu olup olmadığını yorumlar ve başarısızlık halinde alıcıya ne yapmasını önerir. Bu nedenle DMARC kaydı, e-posta güvenliği tarafında en görünür ama en yanlış uygulanan DNS adımlarından biridir.

Yanlış kurulum genellikle iki uçta görülür: ya hiçbir rapor toplamadan doğrudan sert politika uygulanır ya da yıllarca p=none seviyesinde kalınıp gerçek korumaya hiç geçilmez. Sağlıklı yaklaşım ise raporları izleyerek kademeli ilerlemektir. SPF ve DKIM tarafını önce netleştirmek için SPF kaydı oluşturma ve DKIM kaydı kurulumu yazıları bu içerikle birlikte düşünülmelidir.

DMARC Kaydı Ne İşe Yarar?

DMARC, Domain-based Message Authentication, Reporting and Conformance ifadesinin kısaltmasıdır. Temel görevi, SPF ve DKIM sonuçlarını alan adı hizalamasıyla birlikte değerlendirip alıcı sunucuya öneri sunmaktır. Yani yalnızca “SPF geçti mi?” veya “DKIM var mı?” diye bakmaz; bu kontrollerin görünen gönderen alan adıyla gerçekten uyumlu olup olmadığına da bakar.

Bu yapı sayesinde sahte gönderici adresiyle yapılan kimlik taklitleri daha tutarlı biçimde yönetilir. Özellikle kurumsal alan adlarında DMARC olmadan SPF ve DKIM kurulu olsa bile, politikanın ne olacağı netleşmediği için alıcı taraf davranışı daha parçalı kalabilir.

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Bu örnekte kayıt, DMARC sürümünü tanımlar, henüz yaptırım uygulamayan p=none politikasını belirtir ve raporların hangi adrese gönderileceğini gösterir. Küçük gibi görünen bu satır, aslında bir alan adının dış dünyaya e-posta güvenlik politikası ilanıdır.

_dmarc Alt Alanı Neden Zorunludur?

DMARC kaydı doğrudan kök alan adına değil, _dmarc host adı altında oluşturulur. Microsoft Learn de temel sözdiziminde hostname alanını açık biçimde _dmarc olarak verir. Bu nedenle kök domain üzerine TXT ekleyip “DMARC çalışmıyor” sonucu almak sık rastlanan bir hatadır.

Pratikte kayıt adı çoğu panelde yalnızca _dmarc şeklinde girilir. Bazı paneller bunu otomatik olarak tam alan adına genişletir, bazıları ise tam host adı ister. TXT kayıtlarındaki genel host mantığını anlamak için TXT kaydı kullanımı yazısı burada da faydalı olur.

p=none, quarantine ve reject Farkı

DMARC politikasının kalbi p= alanıdır. Google Workspace yardım sayfası ve Microsoft Learn dokümanları, kademeli geçişin bu alan üzerinden kurulmasını önerir. p=none, başarısız iletiler için yaptırım önermeden yalnızca gözlem yapmanızı sağlar. Bu nedenle başlangıç için en güvenli seviyedir.

p=quarantine, başarısız iletilerin şüpheli kabul edilmesini önerir. Alıcı sistem bu iletileri spam klasörüne taşıyabilir veya daha sıkı filtre uygulayabilir. Bu seviye, raporları belli süre izledikten sonra gerçek dünyadaki etkileri kontrollü görmenizi sağlar.

p=reject ise en sert seviyedir. Alıcı sunucuya, DMARC başarısızlığı yaşayan iletileri reddetme önerisi verir. Bu politika güçlü koruma sağlar ama SPF, DKIM ve alignment tarafı yeterince temiz değilse meşru iletilerin de reddedilmesine yol açabilir. Bu yüzden doğrudan başlangıç politikası olarak seçilmesi genellikle tavsiye edilmez.

Kademeli Geçiş Neden Önerilir?

Google ve Microsoft, DMARC geçişini kademeli kurmanızı önerir. Bunun nedeni çok basittir: neredeyse her gerçek yapıda ilk bakışta unutulmuş bir gönderim kaynağı, eski bir bülten aracı, yanlış SPF kalıntısı veya imzası açılmamış alt alan bulunur. Bunlar raporlarla ortaya çıkmadan sert politikaya geçmek kullanıcı tarafında görünmeyen teslimat kayıpları yaratabilir.

Sağlıklı geçiş sırası genellikle şöyledir: önce p=none ile rapor toplanır, ardından sorunlar temizlendikçe p=quarantine uygulanır, son aşamada p=reject devreye alınır. Microsoft Learn bu geçişte pct= değerini kademeli artış için kullanabileceğinizi de açıkça belirtir.

v=DMARC1; p=none; pct=100; rua=mailto:[email protected]
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

Buradaki ikinci örnek, bütün başarısız iletileri değil belirli bir yüzdesini politikaya dahil ederek etkileri kontrollü test etmeye yarar. Özellikle çok kaynaklı kurumsal yapılarda bu geçiş, ani kesinti riskini ciddi biçimde azaltır.

rua ve Raporlama Alanı Neden Önemlidir?

DMARC'ın gerçek gücü sadece politika koymakta değil, raporları okumaktadır. Google yardım dokümanı, rua alanını her zaman eklemenizi önerir. Çünkü rua olmadan politikanın etkisini gözlemlemek zorlaşır ve yanlış pozitifleri yakalamak daha güç hale gelir.

rua, toplu DMARC raporlarının gönderileceği adresi belirtir. Bu raporlar genellikle günlük özetler halinde gelir ve hangi kaynakların SPF veya DKIM başarısızlığı yaşadığını, hangi IP'lerden gönderim yapıldığını ve hangi alanların alignment sorununa düştüğünü anlamaya yardım eder.

Google, doğrudan kişisel posta kutusu yerine bu raporlar için özel mailbox, grup veya üçüncü taraf analiz servisi kullanmanızı önerir. Çünkü rapor hacmi kısa sürede büyüyebilir. Bu öneri pratikte de çok yerindedir; aksi halde raporlar gelen kutusunda izlenemez hale gelir.

Alignment Neden Kritik?

DMARC'ın SPF ve DKIM'den ayrıldığı asıl nokta alignment, yani hizalamadır. İleti SPF'den geçebilir ama farklı bir domain üzerinden geçtiyse ve görünen From alanıyla eşleşmiyorsa DMARC başarısız olabilir. Aynı şekilde DKIM imzası varsa bile imzalayan domain From alanıyla yeterince hizalı değilse politika devreye girebilir.

Bu nedenle birçok ekip SPF geçiyor diye DMARC'ın da geçeceğini sanır ve sonuçta hata raporları karşısında şaşırır. Aslında sorun doğrulamanın yokluğu değil, doğrulamanın yanlış alan adına ait olmasıdır. DKIM selector ve domain eşleşmesini doğru okumak için DKIM kaydı kurulumu yazısı burada tamamlayıcıdır.

Alt Alanlar ve Miras Etkisi

Microsoft Learn, DMARC kaydının üst alan üzerinden alt alanları da etkilediğini özellikle belirtir. Yani ana domain üzerinde yayınlanan DMARC politikası, kendi ayrı DMARC kaydı olmayan alt alanlara da miras kalabilir. Bu özellik hem faydalı hem risklidir.

Faydalıdır; çünkü tüm alt alanlar için ayrı ayrı kayıt açmadan temel politika sağlayabilirsiniz. Risklidir; çünkü pazarlama, bildirim veya dış servisler için kullanılan alt alanlar ana alanla aynı seviyede koruma istemeyebilir. Bu yüzden yüksek hacimli veya üçüncü taraf gönderim kullanan sistemlerde alt alan stratejisi ayrıca düşünülmelidir.

Park Edilen ve Kullanılmayan Domain'lerde DMARC

Kullanılmayan ama size ait olan alan adlarında da DMARC düşünülmelidir. Microsoft Learn, e-posta göndermemesi gereken parked domain'lerde doğrudan v=DMARC1; p=reject; kullanılmasını önerir. Çünkü bu tür alan adlarında meşru e-posta akışı beklenmez; dolayısıyla sert politika güvenlik açısından daha mantıklıdır.

Bu yaklaşım, alan adınızın taklit gönderimlerde kullanılmasını azaltır. Aktif kullanılan ana domain'de yumuşak geçiş gerekirken, hiç kullanılmayan yan domain veya savunma amaçlı kayıtlı uzantılarda daha sert başlangıç güvenli olabilir.

Yaygın DMARC Hataları

En yaygın hata, SPF ve DKIM tam hazır olmadan DMARC açmaktır. Bu durumda kayıt teknik olarak doğru olsa bile meşru iletiler politika nedeniyle etkilenebilir. İkinci hata, rua tanımlamadan politika uygulamaktır; böylece hangi kaynakların başarısız olduğunu izlemek zorlaşır.

Üçüncü hata, tüm alanları tek politika altında düşünmektir. Oysa ana domain ile kampanya alt alanı, aynı itibara ve aynı gönderim modeline sahip olmayabilir. Özellikle dış servis kullanan yapılarda alt alan ayrıştırması, DMARC geçişini çok daha güvenli hale getirir.

Pratik DMARC Uygulama Sırası

Bu sıra, DMARC'ı kâğıt üzerinde aktif görünen ama pratikte yanlış çalışan bir kayıttan çıkarır ve gerçek güvenlik politikasına dönüştürür. Özellikle çok sayıda gönderim kaynağı olan yapılar için acele değil, izleme odaklı geçiş daha doğru sonuç verir.

DMARC tarafında asıl değer, politikayı yayınlamak kadar raporları okuyup kademeli ilerlemektir. p=none ile görünürlük kazanıp sorunlu kaynakları temizledikten sonra quarantine ve reject seviyelerine çıkmak, meşru trafiği riske atmadan korumayı güçlendirir.