SPF, DKIM, DMARC ile E-posta Sahteciliğini Önleme

SPF, DKIM ve DMARC genelde "mailim spam'e düşmesin" bağlamında konuşulur, ama asıl işlevleri bundan daha temel: kimin senin domainin adına mail gönderebileceğini kriptografik olarak kanıtlamak. Bu yazı bu üç protokolün marka sahteciliğini (domain spoofing) ve phishing saldırılarını nasıl engellediğini, ve B2B alıcıların doğrulanmamış şirket e-postalarına neden güvenmediğini anlatıyor.

Neden sadece deliverability değil, güvenlik meselesi

SPF, DKIM ve DMARC genelde pazarlama/gönderim ekiplerinin "mailim gelen kutusuna düşsün" derdiyle anılır, ama bu üç protokolün ortaya çıkış nedeni aslında güvenliktir: e-posta protokolü (SMTP) tasarımı gereği, gönderen adresinin gerçekten iddia ettiği kişi/domain olduğunu doğrulamaz. Herhangi biri, teknik olarak, "From" alanına istediği bir domaini yazıp mail gönderebilir — buna e-posta sahteciliği (spoofing) denir.

Bu açık, B2B dünyasında özellikle tehlikelidir: bir saldırgan bir tedarikçi veya ortak şirketin domainini taklit ederek fatura değişikliği, ödeme yönlendirmesi veya kimlik bilgisi talep eden bir phishing maili gönderebilir. Alıcı, "From" alanında tanıdığı bir domaini gördüğü için güvenir — oysa o mail gerçekten o domainden gönderilmemiştir.

SPF, DKIM ve DMARC, alıcı sunucuya "bu mail gerçekten iddia ettiği domainden mi geldi" sorusunu teknik olarak cevaplama imkânı verir. Bu koruma sağlandığında yan etki olarak deliverability de iyileşir (çünkü alıcı sunucular kimliği doğrulanmış maile daha çok güvenir), ama asıl amaç kimlik doğrulamadır.

IT ekipleri için bu ayrım önemlidir, çünkü bütçe ve öncelik tartışmalarında bu protokoller genelde pazarlama/gönderim ekibinin talebi olarak gündeme gelir ve güvenlik ekibinin gündemine hiç girmeyebilir. Oysa bir domainin SPF/DKIM/DMARC'ı zayıfsa, o domain hem kendi gönderdiği maillerin teslim sorununu hem de üçüncü tarafların o domaini taklit etme riskini aynı anda taşır — bu ikinci risk saf bir güvenlik meselesidir ve deliverability tartışmasından bağımsız ele alınmalıdır.

SPF, DKIM, DMARC nasıl çalışır (teknik özet)

SPF (Sender Policy Framework), domainin DNS'inde bir TXT kaydıdır (örneğin v=spf1 include:... ~all veya -all ile biter) ve o domain adına hangi sunucuların/servislerin mail göndermeye yetkili olduğunu listeler. Alıcı sunucu, gelen mailin zarf gönderen (Return-Path) adresindeki IP'nin bu listede olup olmadığını kontrol eder. SPF'in bilinen bir teknik sınırı vardır: bir domainin SPF kaydında en fazla 10 DNS lookup (include/redirect zinciri) yapılabilir; bu sınır aşılırsa SPF permerror ile başarısız olur — CRM, ESP, fatura sistemi gibi birden fazla gönderim aracı eklendikçe bu limit kolayca aşılabilir.

DKIM (DomainKeys Identified Mail), maile domain sahibinin özel anahtarıyla kriptografik bir imza ekler (mail başlığında DKIM-Signature görünür); açık anahtar ise selector._domainkey.domain.com formatında bir DNS TXT kaydında yayınlanır. Alıcı sunucu bu açık anahtarla imzayı doğrular — mail yolda değiştirilmemişse ve gerçekten o domainden imzalanmışsa doğrulama geçer. DKIM'in SPF'den farkı, mailin içeriğinin bütünlüğünü de garanti etmesidir; SPF sadece gönderen sunucuyu doğrular.

DMARC (Domain-based Message Authentication, Reporting & Conformance), _dmarc.domain.com altında bir DNS TXT kaydıdır ve SPF ile DKIM sonuçlarını "alignment" (uyum — From başlığındaki domain ile SPF/DKIM'in kontrol ettiği domainin eşleşmesi) ile birleştirir. DMARC kaydı alıcı sunucuya bu kontroller başarısız olursa ne yapılacağını söyler: p=none (sadece izle, hareket yok), p=quarantine (spam'e koy), p=reject (reddet). rua= etiketiyle toplu (aggregate) rapor, ruf= ile adli (forensic) rapor adresleri belirtilebilir.

Alignment kavramı burada kritik bir ayrıntıdır: SPF'in kontrol ettiği domain (Return-Path'teki domain) ile DKIM imzasındaki domain, kullanıcının gördüğü "From" alanındaki domain ile birebir veya alt-domain ilişkisiyle eşleşmelidir. Bu eşleşme olmazsa, SPF veya DKIM teknik olarak "pass" dese bile DMARC alignment açısından başarısız sayılabilir — bu yüzden bir domainin SPF/DKIM/DMARC durumunu test ederken üçünü ayrı ayrı değil, birlikte ve alignment gözeterek değerlendirmek gerekir.

DMARC olmadan SPF/DKIM neden yeterli değil

Bir domainde sadece SPF ve DKIM kurulu olup DMARC kaydı yoksa (veya p=none ile sadece izleniyorsa), bir saldırgan hâlâ o domaini "From" alanında taklit edip kendi sunucusundan mail gönderebilir. SPF ve DKIM o sahte mail için başarısız olacaktır, ama DMARC bir zorlayıcı politika (quarantine/reject) tanımlamadığı sürece, alıcı sunucu bu başarısızlığı görse bile maili yine de gelen kutusuna teslim edebilir — çünkü kendi başına ne yapması gerektiğine dair bir talimat yoktur.

DMARC, bu üçlünün asıl güvenlik gücünü ortaya çıkaran parçadır: SPF/DKIM "bu mail sahte" bilgisini üretir, DMARC ise "sahteyse reddet" talimatını verir. p=reject politikası olmadan, marka sahteciliği ve phishing koruması teoride var ama pratikte etkisizdir.

Bu yüzden IT ekipleri için DMARC kaydını sadece kurmak yeterli değildir — politikasını p=none'dan p=reject'e taşımak gerekir. Ama bu geçiş aceleyle yapılırsa risklidir: henüz SPF/DKIM ile hizalanmamış meşru gönderim araçları (örneğin yeni eklenen bir CRM veya pazarlama aracı) da reddedilmeye başlar.

Bir başka pratik nokta: DMARC politikası domain sahibinin kendi domaini için ne yapılacağını belirler, ama bu talimata uyup uymamak alıcı sunucunun kararıdır. Büyük sağlayıcıların (Gmail, Outlook/Microsoft 365) neredeyse tamamı DMARC talimatına uyar, ama bazı küçük veya eski mail sunucuları DMARC'ı hiç desteklemeyebilir — bu durumda p=reject bile o alıcılar için bir garanti oluşturmaz, sadece DMARC'ı destekleyen sağlayıcılar için işler.

DMARC raporlarını okumak: kim domain adına mail gönderiyor

DMARC kaydına eklenen rua= adresi, alıcı sunuculardan (Gmail, Outlook gibi büyük sağlayıcılar dahil) periyodik olarak aggregate (toplu) rapor almanı sağlar. Bu raporlar, hangi IP adreslerinin domain adına mail gönderdiğini, bunların SPF/DKIM/DMARC'tan geçip geçmediğini XML formatında listeler.

IT ekipleri için bu raporlar kritik bir görünürlük aracıdır: bazen şirket içinde unutulmuş eski bir gönderim aracı (örneğin yıllar önce kurulmuş bir pazarlama entegrasyonu) hâlâ domain adına mail atıyor olabilir, ya da daha ciddisi, bir saldırgan gerçekten domaini taklit etmeye çalışıyor olabilir. Raporları düzenli incelemeden bu ayrımı yapmak mümkün değildir.

Ham XML raporlarını elle okumak pratik değildir; çoğu ekip bu raporları görselleştiren bir DMARC analiz aracı (domain spf dkim dmarc checker) kullanır. Bu araçlar hangi kaynakların meşru, hangilerinin şüpheli olduğunu özetler ve p=none'dan p=reject'e geçiş kararını veri temelli almayı sağlar.

Bir güvenlik olayı örneği: bir İstanbul merkezli B2B lojistik firmasının IT ekibi, DMARC raporlarını incelerken kendi domainleri adına, hiç tanımadıkları bir IP bloğundan günde yüzlerce mail gönderildiğini fark eder. SPF/DKIM her ikisi de bu kaynak için başarısız görünüyordur — bu, bir saldırganın firmanın domainini taklit ederek muhtemelen tedarikçilere sahte fatura maili gönderdiğinin işaretidir. DMARC raporu olmadan bu saldırı muhtemelen fark edilmeyecek, sadece mağdur olan üçüncü taraflardan şikâyet geldiğinde ortaya çıkacaktı.

IT ekipleri için kurulum ve test checklist

Bu protokolleri güvenlik amacıyla doğru kurmak isteyen bir IT ekibi için önerilen sıra aşağıdaki gibidir.

• SPF kaydını kur, tüm meşru gönderim kaynaklarını (mail sunucusu, CRM, fatura sistemi, ESP) include ile listele; 10 lookup sınırını aşmamaya dikkat et.
• DKIM'i her gönderim kaynağı için ayrı ayrı etkinleştir ve DNS'te doğru selector kaydını yayınla.
• DMARC kaydını p=none ile başlat, rua= adresini kendi ekibinin izleyebileceği bir kutuya veya analiz aracına yönlendir.
• En az birkaç hafta raporları izleyerek hangi kaynakların SPF/DKIM'den geçtiğini, hangilerinin geçmediğini (ve neden — meşru mü, şüpheli mi) belirle.
• Tüm meşru kaynaklar hizalandıktan sonra politikayı kademeli olarak p=quarantine'e, ardından p=reject'e yükselt.
• Bir domain spf dkim dmarc checker aracıyla periyodik olarak (özellikle yeni bir gönderim aracı eklendiğinde) kayıtların hâlâ doğru ve hizalı olduğunu doğrula.
• B2B outreach için ayrı bir gönderim alt-domaini kullanıyorsan, o alt-domain için de aynı SPF/DKIM/DMARC disiplinini uygula; ana kurumsal domain güvenli olsa bile, izole edilmemiş bir outreach alt-domaini saldırganlar için daha kolay bir hedef olabilir.

Sık sorulan sorular