E-posta Kimlik Doğrulama: SPF, DKIM ve DMARC ile Alan Adı Koruma
E-posta, kurumların müşterileri, iş ortakları ve çalışanlarıyla kurduğu iletişimin temel kanallarından biridir. Bu kanalın güvenilirliği, iletinin gerçekten iddia ettiği alan adından gönderildiğinin doğrulanabilmesine bağlıdır. Basit Posta Aktarım Protokolü (SMTP) ilk tanımlandığında gönderen kimliğini doğrulayan bir mekanizma içermiyordu; bu nedenle bir göndericinin From başlığına herhangi bir alan adını yazması teknik olarak mümkündü. Bu durum, e-posta sahteciliği (spoofing), kimlik avı (phishing) ve sahte fatura ya da ödeme talebi içeren iletilerin yaygınlaşmasına zemin hazırladı. SPF, DKIM ve DMARC olarak bilinen üç teknik standart, tam olarak bu açıklığı kapatmak ve alan adı itibarını korumak amacıyla geliştirilmiştir.
E-posta Sahteciliğinin Temel Mekaniği
SMTP, iletilerin sunucular arasında aktarılmasını sağlar ancak aktarım sırasında gönderenin kimliğini kriptografik olarak kanıtlamaz. Bir saldırgan, kendi sunucusundan çıkan bir iletinin başlık bilgilerine kurbanın alan adını yazarak alıcı tarafında güvenilir bir kaynaktan geliyormuş izlenimi oluşturabilir. Alıcı posta sunucusu, gelen iletinin gerçekten o alan adından gönderilme yetkisine sahip bir sunucudan gelip gelmediğini ancak ek doğrulama kayıtları aracılığıyla kontrol edebilir. Bu nedenle alan adı sahiplerinin, kendi adlarına kimlerin e-posta gönderebileceğini DNS üzerinde açıkça tanımlaması gerekir.
SPF: Gönderim Yetkisinin Tanımlanması
Sender Policy Framework (SPF), bir alan adı adına e-posta göndermeye yetkili sunucuların IP adreslerini listeleyen bir DNS kaydıdır. Alıcı sunucu, gelen iletinin zarf göndericisi (envelope sender, teknik olarak Return-Path ya da MAIL FROM alanı) ile ilişkili SPF kaydını sorgular ve iletinin kaynak IP adresinin bu listede yer alıp almadığını denetler. Sonuç, ileti başlıklarına eklenen bir doğrulama satırında raporlanır.
SPF Kaydının Söz Dizimi
Bir SPF kaydı, alan adının TXT kaydı olarak yayımlanır ve her zaman v=spf1 ile başlar. Ardından gelen mekanizmalar, hangi kaynakların yetkili sayılacağını belirtir. Yaygın mekanizmalar şunlardır:
- a: Alan adının A veya AAAA kaydında tanımlı IP adreslerini yetkilendirir.
- mx: Alan adına tanımlı MX kayıtlarındaki sunucuları yetkilendirir.
- ip4 ve ip6: Belirli bir IP adresini veya blok aralığını doğrudan yetkilendirir.
- include: Başka bir alan adının SPF kaydındaki yetkileri devralır; genellikle üçüncü taraf gönderim hizmetleri için kullanılır.
- all: Listenin sonunda yer alır ve diğer tüm kaynakların nasıl değerlendirileceğini belirler.
Her mekanizmanın önüne bir nitelik işareti gelebilir: + geçiş (Pass), - başarısız (Fail), ~ yumuşak başarısız (SoftFail) ve ? nötr (Neutral). Örneğin -all ifadesi, listede yer almayan hiçbir sunucunun bu alan adı adına gönderim yapamayacağını bildirir.
SPF'nin Yapısal Sınırları
SPF, tek başına yeterli bir koruma değildir. Kaydın çözümlenmesi sırasında yapılabilecek DNS sorgusu sayısı sınırlıdır; include ve benzeri mekanizmaların zincirleme kullanımı bu sınırı aşabilir ve doğrulamanın geçici olarak başarısız olmasına yol açabilir. Ayrıca SPF, iletinin From başlığını değil zarf göndericisini denetler. İleti yönlendirildiğinde zarf bilgisi değişebileceği için, yalnızca SPF'ye dayanan bir doğrulama yanıltıcı sonuçlar üretebilir.
DKIM: İletinin Kriptografik Olarak İmzalanması
DomainKeys Identified Mail (DKIM), gönderen sunucunun iletiyi özel bir anahtarla imzalamasını ve alıcı sunucunun bu imzayı alan adının DNS kaydında yayımlanan açık anahtarla doğrulamasını sağlar. Böylece iletinin içeriğinin aktarım sırasında değiştirilmediği ve gerçekten ilgili alan adına ait bir anahtarla imzalandığı kanıtlanır.
Anahtar Çiftleri ve DNS Kaydı
DKIM yapılandırmasında bir açık, bir de özel anahtar içeren kriptografik anahtar çifti üretilir. Özel anahtar gönderim sunucusunda saklanır; açık anahtar ise DNS üzerinde seçici (selector) adı verilen bir etiketle TXT kaydı olarak yayımlanır. Kaydın adı genellikle selector._domainkey.alanadi biçimindedir. Birden fazla seçici tanımlanması, anahtar rotasyonu ve farklı gönderim sistemlerinin ayrı anahtarlar kullanması açısından esneklik sağlar.
İmzalama ve Doğrulama Akışı
Gönderim sırasında sunucu, iletinin seçili başlıklarını ve gövdesini özetleyerek bir karma değeri üretir ve bu değeri özel anahtarla imzalar. Oluşan imza, iletinin DKIM-Signature başlığına eklenir; bu başlıkta kullanılan alan adı, seçici ve imza değeri yer alır. Alıcı sunucu, ilgili seçiciyi DNS üzerinden sorgulayarak açık anahtarı elde eder ve imzayı doğrular. İmzalanan başlıklardan biri değiştirilmişse veya gövde aktarım sırasında bozulmuşsa doğrulama başarısız olur. Bu nedenle DKIM, iletinin bütünlüğünü ve kaynağını birlikte güvence altına alır.
DMARC: Politika, Hizalama ve Raporlama
Domain-based Message Authentication, Reporting and Conformance (DMARC), SPF ve DKIM sonuçlarını tek bir politika altında birleştirir ve alan adı sahibine, doğrulamadan geçemeyen iletilerin nasıl ele alınacağını belirleme imkânı sunar. DMARC kaydı, _dmarc.alanadi biçimindeki bir TXT kaydı olarak yayımlanır ve v=DMARC1 ile başlar.
Hizalama Kavramı
DMARC'nin ayırt edici özelliği, doğrulama sonucuna ek olarak bir hizalama (alignment) koşulu aramasıdır. SPF veya DKIM doğrulaması başarılı olsa bile, bu doğrulamada kullanılan alan adının iletinin From başlığındaki alan adıyla uyumlu olması gerekir. SPF tarafında bu, zarf göndericisi ile From alan adının; DKIM tarafında ise imzayı atan d= alan adının From ile eşleşmesi anlamına gelir. İki alan adı birebir aynıysa katı (strict), aynı kuruluş alan adının alt alanlarıysa gevşek (relaxed) hizalama söz konusudur. Bu koşul sayesinde, bir gönderim hizmetinin kendi alan adıyla SPF doğrulamasından geçmesi tek başına yeterli olmaz.
DMARC Politikaları
DMARC kaydındaki p etiketi, doğrulamadan geçemeyen iletiler için uygulanacak politikayı belirler:
- p=none: İleti normal şekilde teslim edilir; yalnızca izleme ve raporlama amaçlanır.
- p=quarantine: Doğrulamadan geçemeyen iletilerin spam klasörüne yönlendirilmesi istenir.
- p=reject: Doğrulamadan geçemeyen iletilerin reddedilmesi istenir.
Kayıtta ayrıca alt alan adları için ayrı politika tanımlayan sp etiketi, politikanın uygulanacağı ileti yüzdesini belirten pct etiketi ile SPF ve DKIM hizalamasını ayrı ayrı kontrol eden aspf ve adkim etiketleri bulunabilir.
Raporlama Mekanizmaları
DMARC, iki tür rapor üretir. Toplu (aggregate) raporlar, rua etiketiyle belirtilen adrese gönderilir ve belirli bir dönemde alan adı adına gönderilen iletilerin doğrulama sonuçlarını özetler. Adli (forensic) raporlar ise ruf etiketiyle tanımlanır ve doğrulamadan geçemeyen tek tek iletiler hakkında ayrıntı sunar. Bu raporlar, yetkisiz gönderim kaynaklarının tespit edilmesi ve yapılandırmanın iyileştirilmesi için veri sağlar.
Üç Standardın Birlikte İşleyişi
Protokoller birbirinin yerine geçmez; birbirini tamamlar. Tipik bir doğrulama akışı şu adımlardan oluşur:
- Alıcı sunucu, gelen iletinin zarf göndericisine karşılık gelen SPF kaydını sorgular ve kaynak IP adresini denetler.
- Aynı sunucu, iletide bulunan DKIM imzasını ve ilgili DNS kaydındaki açık anahtarı kullanarak imzayı doğrular.
- DMARC kaydı okunarak her iki sonucun From alan adıyla hizalanıp hizalanmadığı kontrol edilir.
- Hizalı bir SPF veya DKIM geçişi varsa ileti doğrulanmış sayılır; aksi hâlde DMARC politikası uygulanır.
- Sonuçlar, tanımlıysa raporlama adreslerine iletilir.
Bu yapıda SPF, yetkili gönderim altyapısını tanımlar; DKIM, iletinin bütünlüğünü ve kaynağını kriptografik olarak kanıtlar; DMARC ise her ikisini ortak bir politikaya bağlayarak alan adı sahibine denetim imkânı verir.
DNS Üzerinden Yapılandırma Süreci
Kimlik doğrulama kayıtları, alan adının yetkili DNS sunucularında metin (TXT) kaydı olarak tanımlanır. Yapılandırma genel olarak şu sırayla ilerler: önce alan adı adına gönderim yapan tüm sistemler belirlenir ve SPF kaydı hazırlanır; ardından gönderim sunucularında DKIM anahtar çiftleri üretilip açık anahtarlar DNS'e eklenir; son olarak DMARC kaydı yayımlanır. DMARC politikasının başlangıçta none olarak ayarlanması, raporların incelenmesi ve yetkisiz kaynakların düzeltilmesinin ardından daha katı politikalara geçilmesi yaygın bir yaklaşımdır. Bir alan adı için yalnızca tek bir SPF kaydının bulunması gerekir; birden fazla kayıt tanımlandığında doğrulama başarısız sonuç verebilir.
Alan Adı İtibarı ve İleti Teslim Edilebilirliği
Alıcı sunucular, gelen iletileri değerlendirirken gönderen alan adının geçmişini ve doğrulama durumunu dikkate alır. Kimlik doğrulama kayıtları eksik veya hatalı olan alan adlarından gönderilen iletiler, spam filtreleri tarafından daha yüksek riskli kabul edilebilir. Buna karşılık doğrulamadan tutarlı biçimde geçen iletiler, meşru gönderim akışının bir parçası olarak değerlendirilir. Dolayısıyla SPF, DKIM ve DMARC yalnızca sahteciliği sınırlayan bir önlem değil, aynı zamanda kurumsal yazışmaların güvenilir biçimde iletilmesini destekleyen bir altyapı unsurudur. Alan adı itibarı; gönderim hacmi, şikâyet oranları ve kimlik doğrulama sonuçları gibi birden çok değişkenden etkilendiği için bu kayıtların düzenli olarak gözden geçirilmesi gerekir.
Yaygın Yapılandırma Sorunları
Uygulamada sık karşılaşılan durumlar, doğrulama başarısızlıklarının başlıca nedenleri arasında yer alır:
- SPF kaydındaki include zincirinin DNS sorgu sınırını aşması.
- Alan adı adına gönderim yapan yeni bir hizmetin SPF kaydına eklenmemesi.
- DKIM seçicisinin DNS kaydı ile gönderim sunucusundaki yapılandırmanın uyuşmaması.
- Alt alan adları için ayrı politika tanımlanmaması ve bu alan adlarının korumasız kalması.
- DMARC politikasının, raporlar incelenmeden doğrudan reject olarak ayarlanması ve meşru iletilerin de reddedilmesi.
- İleti yönlendirme ve posta listeleri nedeniyle zarf bilgisinin değişmesi.
Bu sorunların çoğu, kayıtların düzenli olarak denetlenmesi ve DMARC raporlarının izlenmesi yoluyla tespit edilebilir. Kimlik doğrulama yapılandırması tek seferlik bir işlem değil, gönderim altyapısındaki değişikliklere paralel olarak güncellenmesi gereken sürekli bir süreçtir.
