SPF, DKIM ve DMARC birlikte nasıl çalışır

SPF ne yapar

SPF, bir domain adına hangi e-posta sistemlerinin gönderim yapabileceğini yayınlar. Alıcı sunucular bir iletiyi değerlendirirken bu politikayı sinyallerden biri olarak kullanabilir.

Politika, doğru bir gönderen envanteri gerektirir. Meşru bir platformu dışarıda bırakan bir kayıt geçerli e-postayı etkileyebilir. Fazla geniş bir politika ise sinyalin değerini düşürebilir.

DKIM ne yapar

DKIM, gönderen sistemin eklediği bir imzayı ve DNS'teki bir açık anahtar kaydını kullanır. Seçici (selector), belirli bir imzalayan için hangi açık kaydın kullanılacağını belirtir.

Bir DKIM kaydı, sağlayıcının gerçekten kullandığı seçici için kontrol edilmelidir. Farklı bir seçiciye ait bir kayıt, ilgili gönderenin doğru yapılandırıldığını kanıtlamaz.

DMARC ne ekler

DMARC, DMARC kontrollerinden geçemeyen iletiler için bir politika yayınlar ve SPF ile DKIM'i hizalamayı merkeze alan bir çerçevede bir araya getirir. p=none, p=quarantine ve p=reject politikaları farklı uygulama aşamalarını yansıtır.

p=none içeren bir DMARC kaydı izleme için yararlıdır, ama quarantine ya da reject düzeyinde uygulama ile aynı şey değildir.

1. Tüm meşru gönderim servislerini belirleyin.
2. Tek ve geçerli bir SPF politikası olduğunu kontrol edin ve içindeki gönderenleri gözden geçirin.
3. Her sağlayıcının kullandığı DKIM seçicisini kontrol edin.
4. DMARC'ın var olup olmadığını ve hangi politikayı yayınladığını kontrol edin.
5. DNS değişikliklerini kontrollü biçimde yapın, ardından herkese açık sinyalleri yeniden kontrol edin.

Soruya uygun kontrolü kullanın

CloudSpex E-posta Güvenlik Kontrolü, MX, SPF ve DMARC'ın herkese açık bir özetini sunar. Ayrı SPF, DKIM ve DMARC araçları ise kendi herkese açık sinyallerine odaklanır.

Bu araçlar salt okunurdur ve bilinçli olarak ham DNS kayıtlarını göstermez. Bir incelemeyi önceliklendirmeye yardımcı olurlar. Bir yapılandırmayı değiştirirken esas alınacak kaynak yine sağlayıcının dokümantasyonudur.

Tek ileti, üç kontrol

Tek bir iletiyi izlemek konuyu anlamayı kolaylaştırır. Bir e-posta sunucusu iletiyi aldığında işin içinde üç farklı domain olabilir. Dönüş yolu (return path) olarak da bilinen zarf göndereni, geri dönen iletilerin gittiği yerdir ve gönderen sistem tarafından belirlenir. DKIM imzalama domaini, iletiyi hangi domainin anahtarı imzaladıysa odur. From adresi ise alıcının gördüğü adrestir. Bunlar üç farklı domain olabilir ve üçüncü taraf bir servis üzerinden gönderilen e-postada çoğu zaman öyledir.

SPF zarf gönderenini kontrol eder. DKIM imzayı kontrol eder. DMARC ise diğer ikisinin hiç sormadığı soruyu sorar: Bu sonuçlardan herhangi biri, okurun gerçekten gördüğü From adresindeki domaine ait mi?

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.example.com;
  dkim=pass header.d=example.com header.s=s1;
  dmarc=pass (p=reject) header.from=example.com

Üç kayıt yan yana

Her mekanizma farklı bir adda TXT kaydı olarak yayınlanır. Onları bir arada görmek, birbirinin yerini tutmayan ayrı parçalar olduklarını netleştirir.

example.com.                TXT  "v=spf1 include:_spf.google.com ~all"
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com.         TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Hizalama: gözden kaçan kısım

SPF ve DKIM, DMARC'tan önce tasarlanmıştır ve ikisi de görünen From adresine bakmaz. Bir ileti, bu sonuçların hiçbiriyle ilgisi olmayan bir domainden geldiğini öne sürerken ikisinden de geçebilir. DMARC bu boşluğu hizalama ile kapatır: Bir SPF ya da DKIM geçişi, ancak domaini From domainiyle eşleşiyorsa sayılır.

Varsayılan olan gevşek hizalamada kurumsal domainlerin eşleşmesi gerekir. Bu yüzden mail.example.com, example.com ile hizalıdır. Katı hizalamada domainler birebir aynı olmalıdır. DMARC'ın geçmesi için iki mekanizmadan yalnızca birinin hizalı olarak geçmesi yeterlidir.

Pratikteki sonucu şudur: Üçüncü taraf bir gönderen, yalnızca sizin adınıza gönderecek şekilde değil, sizin domaininizi kullanacak şekilde kurulmalıdır. Kendi domainiyle imzalayan ve kendi dönüş yolunu kullanan bir servis SPF ve DKIM'den geçer, DMARC'tan ise geçemez.

Neden hem SPF'e hem DKIM'e ihtiyacınız var

DMARC yalnızca tek bir hizalı geçişe ihtiyaç duyar, bu yüzden tek bir mekanizmayı yapılandırıp bırakmak cazip gelir. Ancak ikisi farklı durumlarda bozulur. İkisine de sahip olmaya değmesinin nedeni budur.

SPF, bir ileti iletildiğinde (yönlendirildiğinde) bozulur, çünkü iletimi yapan sunucu kaydınızda yoktur. DKIM iletmeden sağ çıkar, çünkü imza iletiyle birlikte taşınır. Ancak bazı e-posta listelerinin ve güvenlik ağ geçitlerinin yaptığı gibi arada bir şey içeriği değiştirdiğinde bozulur. İkisi de devredeyken, birini kaybeden bir ileti genellikle diğerini korur.

Kurulum sırası

Sıra önemlidir, çünkü her adım bir sonraki için gereken bilgiyi üretir.

1. Domaini kullanarak e-posta gönderen her sistemi listeleyin.
2. Domaininizi dönüş yolu olarak kullanan sistemleri kapsayan ve ~all ile biten tek bir SPF kaydı yayınlayın.
3. Destekleyen her sistemde kendi domaininizle DKIM imzalamayı açın ve her seçiciyi yayınlayın.
4. DMARC'ı p=none ve bir rua adresiyle yayınlayın.
5. Toplu raporları birkaç hafta boyunca okuyun ve hizalamadan geçemeyen her meşru kaynağı düzeltin.
6. DMARC'ı önce quarantine, sonra reject düzeyine taşıyın.
7. Raporlar hiçbir meşru hata göstermediğinde SPF'i -all ile sıkılaştırın.

Üçüncü taraf gönderenler

Hizalama sorunlarının çoğu, sizin adınıza gönderim yapan servislerden kaynaklanır. Her biri, farklı adlar altında iki ayarın bir bileşimini sunar. Bazen domain kimlik doğrulaması ya da gönderen kimlik doğrulaması olarak adlandırılan özel DKIM domaini, servisin sizin domaininizle imzalamasını sağlar. Genellikle seçici adlarında CNAME ya da TXT kayıtları yayınlamanızı ister. Bazen özel geri dönüş domaini (bounce domain) ya da MAIL FROM domaini olarak adlandırılan özel dönüş yolu ise SPF'in hizalanmasını sağlar. Genellikle bir alt domainde CNAME ya da MX kaydı ister.

Özel DKIM domainini sunulduğu her yerde etkinleştirin. İkisi arasında daha sağlam olanıdır ve DMARC için tek başına yeterlidir. İkisini de sunmayan bir servis, domaininiz için hizalı e-posta gönderemez ve uygulayan bir politika altında iletileri karantinaya alınır ya da reddedilir. Bu durumda seçenekler, daha zayıf politikalı bir alt domainden göndermek ya da servisi değiştirmektir.

Kimlik doğrulamanın yapmadıkları

Bu kayıtlar, bir iletinin geldiğini öne sürdüğü domain tarafından yetkilendirildiğini kanıtlar. İletinin istenen, güvenli ya da dürüst olduğunu kanıtlamaz. Spam gönderenler de kendi domainlerini kusursuz biçimde doğrular.

Benzer görünümlü domainleri de durdurmazlar. Kendine ait geçerli bir DMARC kaydı olan examp1e.com adresinden gelen bir ileti her kontrolden geçer. Görünen ad hakkında da hiçbir şey söylemezler. Oysa birçok e-posta istemcisi görünen adı adresten daha belirgin biçimde gösterir. Kimlik doğrulama, tam olarak sizin domaininizi taklit edilmekten korur. İnsanları benzer görünen adlardan korumak ise ayrı bir sorundur.

DMARC'tan sonra ne gelir

Bir domain uygulayan bir DMARC politikasına ulaştığında, bunun üzerine kurulan üç standart daha vardır. MTA-STS, bir domainin kendisine gönderilen e-postanın doğrulanmış TLS üzerinden teslim edilmesini şart koşmasını sağlar. TLS-RPT, gönderen sunuculardan şifreli teslimat başarısız olduğunda rapor göndermelerini ister. BIMI, e-posta sağlayıcılarının kimliği doğrulanmış iletilerin yanında bir marka logosu göstermesini sağlar ve quarantine ya da reject düzeyinde bir DMARC politikası gerektirir.

Bunların hiçbiri SPF, DKIM ya da DMARC'ın yerini tutmaz. Teslimat güvenliğini ve sunumu ele alırlar ve her biri temellerin yerinde olmasına ve yerinde kalmasına bağlıdır.

Yaygın yanılgılar

Yanlış yapılandırılmış domainlerin çoğunun arkasında bir avuç hatalı inanış vardır.

1. SPF'in From adresini koruduğu sanılır. SPF, okurun hiç görmediği zarf gönderenini kontrol eder.
2. p=none içeren bir DMARC kaydının domaini koruduğu sanılır. Bu kayıt yalnızca rapor üretir.
3. SPF ve DKIM'den geçmenin DMARC'tan geçmek anlamına geldiği sanılır. Hizalama olmadan gelmez.
4. Her servisi SPF'e eklemenin zararsız olduğu sanılır. Her include, on sorguluk bütçenin bir kısmını harcar.
5. Kimlik doğrulamanın bir kez kurulduğu sanılır. Sürekli yeni gönderenler eklenir ve sağlayıcılar kayıtlarını değiştirir.

Bir domaini kontrol etmek

Herkese açık DNS, üç kaydın var olup olmadığını ve geçerli olup olmadığını gösterir. Yalnızca gerçek iletilerde var olan hizalamayı göstermez. Bu yüzden tam bir kontrolün iki bölümü vardır: Kayıtları okuyun, ardından denetiminizdeki bir posta kutusuna bir ileti gönderin ve Authentication-Results başlığını okuyun. CloudSpex E-posta Güvenlik Kontrolü, bir alıcı sunucunun göreceği MX, SPF ve DMARC kayıtlarını okur. Ayrı SPF, DKIM ve DMARC araçları her birine ayrıntılı bakar. DMARC toplu raporları ise gerçek e-postaya ne olduğunu gösterir.

Alt domainler üzerine bir not

Üç mekanizma alt domainleri farklı biçimde ele alır ve bu kafa karışıklığına yol açar. SPF asla devralınmaz: Her alt domainin kendi kaydına ihtiyacı vardır. DKIM anahtarları, hangi domain imzalıyorsa onun altında seçici bazında yayınlanır ve ana domain altındaki bir anahtar bir alt domainden gelen e-postayı imzalayabilir. DMARC devralınır: Ana domaindeki bir kayıt, kendi kayıtlarını yayınlamadıkları sürece alt domainleri de kapsar ve sp etiketi onlar için ayrı bir politika belirler.