DMARC Nasıl Eklenir? DMARC Protokolü, DNS TXT Yapılandırması ve BIMI Entegrasyon Rehberi

DMARC Protokolü Nedir ve SPF ile DKIM Neden Tek Başına Yetersizdir?

Kurumsal siber güvenlik mimarisinde en sık yanlış anlaşılan konulardan biri, SPF (Sender Policy Framework) ve DKIM (DomainKeys Identified Mail) kayıtlarının tanımlanmasıyla alan adının e-posta sahteciliğine (domain spoofing) karşı tamamen korunduğu varsayımıdır. Oysa SMTP protokolü iki farklı gönderici kimliği barındırır: sunucular arası yönlendirmede kullanılan RFC 5321 Zarf Göndericisi (MAIL FROM / Return-Path) ve son kullanıcının e-posta istemcisinde (Outlook, Gmail, Apple Mail) gördüğü RFC 5322 Başlık Göndericisi (From:).

DMARC (Domain-based Message Authentication, Reporting, and Conformance — RFC 7489) devreye alınmadığında, kötü niyetli bir saldırgan kendi kontrolündeki saldirgan-sunucu.net alan adı üzerinden SPF ve DKIM doğrulamasını başarıyla geçebilir, ancak görünür From: başlığına ceo@sirketiniz.com yazabilir. Alıcı sunucu SPF ve DKIM'i saldirgan-sunucu.net için geçerli bulduğundan mesajı gelen kutusuna teslim eder. DMARC protokolü, son kullanıcının gördüğü From: alan adı ile SPF ve DKIM tarafından doğrulanan alan adlarının birbirini tutmasını (Kimlik Hizalaması / Identifier Alignment) zorunlu kılarak bu güvenlik açığını kökten kapatır.

1. DMARC Kimlik Hizalaması (Identifier Alignment): aspf ve adkim

Bir e-postanın DMARC kontrolünden geçebilmesi için yalnızca SPF veya DKIM'in "Pass" (Başarılı) dönmesi yetmez; doğrulanan alan adının From: başlığındaki alan adıyla hizalanması gerekir. DMARC iki farklı hizalama modu sunar:

• Esnek Hizalama (Relaxed Alignment — r, Varsayılan): Görünür From: başlığındaki organizasyonel kök alan adı ile SPF (Return-Path) veya DKIM (d=) alan adının kök kısmı eşleşmelidir. Örneğin From: bilgi@sirketiniz.com iken Return-Path: bounce@notify.sirketiniz.com ise esnek hizalama başarılı kabul edilir.
• Katı Hizalama (Strict Alignment — s): Görünür From: başlığındaki tam nitelikli alan adı (alt alan adı dahil) ile SPF veya DKIM alan adı birebir aynı olmalıdır. Katı modda (adkim=s; aspf=s), sirketiniz.com ile notify.sirketiniz.com eşleşmez ve doğrulama reddedilir.

2. DMARC DNS TXT Kaydı Etiketleri ve Teknik Parametre Tablosu

DMARC politikası, alan adınızın DNS yönetim panelinde _dmarc.alanadiniz.com ana bilgisayarı (host) altında bir TXT kaydı olarak yayınlanır. Aşağıdaki tablo, kurumsal bir DMARC kaydında yer alan tüm parametrelerin teknik işlevlerini göstermektedir:

3. Adım Adım DMARC Nasıl Eklenir? 3 Aşamalı Üretim Geçiş Planı

Aktif çalışan bir kurumsal alan adında doğrudan p=reject politikasını devreye almak, henüz DKIM veya SPF hizalaması tamamlanmamış meşru servislerin (örneğin muhasebe yazılımı, İK portalı veya harici CRM) gönderdiği e-postaların anında kesilmesine yol açabilir. Bu nedenle Kling Digital standartlarında DMARC geçişi üç kontrollü fazda uygulanır:

Faz 1: Gözlem ve Envanter Keşfi (p=none)

İlk aşamada hiçbir e-posta engellenmez; yalnızca alan adınız adına dünyadaki tüm sunuculardan çıkan trafiğin günlük XML raporları (rua) toplanır. DNS panelinizde aşağıdaki TXT kaydını oluşturun:

_dmarc.alanadiniz.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rapor@alanadiniz.com; fo=1;"

Bu aşamada 2 hafta boyunca gelen XML raporları incelenir. Şirket içinde habersiz kullanılan "Shadow IT" e-posta servisleri tespit edilir ve her birinin 2048-bit DKIM anahtarları ile özel Return-Path alt alan adları yapılandırılır.

Faz 2: Kontrollü Karantina ve Yüzdesel Uygulama (p=quarantine)

Tüm meşru gönderim kaynakları DKIM ve SPF hizalamasından %100 geçmeye başladığında, doğrulamadan geçemeyen şüpheli mesajların spam klasörüne yönlendirilmesi için p=quarantine aşamasına geçilir. İlk hafta pct=25 ile başlanıp sorun görülmediğinde pct=100 değerine çıkarılır:

_dmarc.alanadiniz.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r; rua=mailto:dmarc-rapor@alanadiniz.com; fo=1;"

Faz 3: Tam Koruma ve Alt Alan Adı Kilitleme (p=reject)

Karantina aşamasında meşru hiçbir e-postanın etkilenmediği doğrulandıktan sonra, sahte e-postaların alıcıya hiç ulaşmadan SMTP katmanında reddedilmesi için p=reject ve alt alan adları için sp=reject politikası mühürlenir:

_dmarc.alanadiniz.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rapor@alanadiniz.com; ruf=mailto:dmarc-forensic@alanadiniz.com; fo=1;"

Yukarıdaki üretim kaydında adkim=s (katı DKIM hizalaması) ve aspf=r (esnek SPF hizalaması, çünkü AWS SES veya SendGrid gibi servisler genellikle bounce.alanadiniz.com gibi bir alt alan adı kullanır) birlikte kullanılarak hem maksimum güvenlik hem de bulut MTA uyumluluğu sağlanmıştır.

4. DMARC XML Toplu Raporlarının (RUA) Teknik Analizi

rua etiketinde belirttiğiniz adrese Google, Microsoft ve Yahoo tarafından her gün sıkıştırılmış (.xml.gz) dosyalar gönderilir. Bu XML dosyaları insan gözüyle okunmak için değil, makine ayrıştırması için tasarlanmıştır. Tipik bir DMARC XML kaydı şu yapıdadır:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>1420</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>alanadiniz.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>alanadiniz.com</domain>
      <selector>kling2026</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>notify.alanadiniz.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Raporları incelerken dikkat etmeniz gereken kritik fark <auth_results> ile <policy_evaluated> bölümleri arasındadır: <auth_results> ham SPF/DKIM sonucunu gösterirken, <policy_evaluated> içindeki <dkim> ve <spf> düğümleri hizalama (alignment) sonucunu gösterir. Eğer ham SPF pass olduğu halde policy_evaluated altında fail görünüyorsa, üçüncü parti gönderici servisiniz kendi Return-Path alan adını kullanıyor demektir; özel geri dönüş alt alan adı (Custom Return-Path / CNAME) tanımlayarak hizalamayı düzeltmelisiniz.

5. Harici Alan Adına Rapor Gönderimi ve DNS Yetkilendirmesi (_report._dmarc)

Birden fazla alan adını tek bir merkezi güvenlik alan adında (örneğin alanadi-a.com raporlarını dmarc@guvenlik-merkezi.com adresinde) toplamak istediğinizde, RFC 7489 gereği alıcı sunucular rapor göndermeden önce hedef alan adının bu raporları kabul etmeye razı olup olmadığını DNS üzerinden denetler. Bunun için raporları alacak olan alan adında şu TXT kaydının oluşturulması zorunludur:

alanadi-a.com._report._dmarc.guvenlik-merkezi.com. 3600 IN TXT "v=DMARC1"

Bu yetkilendirme kaydı eklenmezse, Google ve Microsoft dış alan adına ait rua adreslerini güvenlik nedeniyle sessizce yok sayar.

6. BIMI (Brand Indicators for Message Identification) ve VMC Entegrasyonu

DMARC protokolünü zorlama (enforcement) seviyesine taşımanın en büyük kurumsal avantajlarından biri BIMI desteğidir. BIMI, alıcının gelen kutusunda (Gmail, Apple Mail, Yahoo) e-postanızın yanında şirketinizin doğrulanmış resmi marka logosunun ve mavi onay rozetinin görüntülenmesini sağlar.

BIMI aktivasyonu için teknik ön koşullar şunlardır:

1. Alan adınızın DMARC politikası mutlaka p=quarantine; pct=100 veya p=reject seviyesinde olmalıdır (p=none ile BIMI kesinlikle çalışmaz).
2. Marka logonuz SVG Tiny Portable/Secure (SVG P/S) profilinde dışa aktarılmalı ve HTTPS üzerinden sunulmalıdır.
3. Gmail ve Apple Mail üzerinde doğrulanmış onay işareti için DigiCert veya Entrust gibi sertifika otoritelerinden VMC (Verified Mark Certificate) veya CMC (Common Mark Certificate) alınarak PEM dosyası yüklenmelidir.

default._bimi.alanadiniz.com. 3600 IN TXT "v=BIMI1; l=https://alanadiniz.com/bimi/logo.svg; a=https://alanadiniz.com/bimi/vmc.pem;"

7. E-Posta Yönlendirme (Forwarding) Sorunu ve ARC (RFC 8617)

Katı bir p=reject DMARC politikasında karşılaşılan en önemli kenar durum (edge case) otomatik e-posta yönlendirmeleridir. Bir kullanıcı e-postasını kendi mezuniyet veya dernek adresinden (ör. mezun@universite.edu) kişisel Gmail hesabına otomatik yönlendirdiğinde, ara sunucu mesajı yeniden gönderdiği için kaynak IP değişir ve SPF kırılır. Ayrıca e-posta listeleri (mailing lists) konu başlığına [Liste] etiketi veya altbilgi eklerse DKIM imzası da bozulur.

Bu nedenle kurumsal yapılandırmada her zaman DKIM imzalaması eksiksiz yapılmalı (çünkü basit yönlendirmelerde içerik değişmediği için DKIM sağlam kalır ve DMARC tek bir hizalanmış mekanizma ile geçer) ve kendi posta sunucularınızda ARC (Authenticated Received Chain — RFC 8617) doğrulama zinciri desteklenmelidir.