SPF, DKIM ve DMARC: Kurumsal Mailleriniz Neden Spama Düşüyor?

"Mailinizi göremedik, spama düşmüş." Bu cümleyi bir kez duyan herkes, aynı sorunun başka hangi müşterilerde yaşandığını merak eder. Çünkü spama düşen her iletinin arkasında cevapsız kalmış bir teklif, gecikmiş bir fatura ya da kaçırılmış bir toplantı olabilir.

Alıcı taraftaki e-posta sunucuları, gelen her iletiye aynı soruyu sorar: Bu ileti gerçekten göründüğü yerden mi geliyor? Bu soruya cevap veremeyen iletiler, içerikleri ne kadar masum olursa olsun şüpheli kabul edilir. SPF, DKIM ve DMARC, alan adınızın bu soruya "evet" diyebilmesini sağlayan üç DNS kaydıdır. Büyük e-posta sağlayıcıları son yıllarda özellikle toplu gönderim yapanlardan bu kayıtları açıkça istemeye başladı; yani artık bir "iyi uygulama" değil, temel bir gereklilik sayılıyorlar.

Alıcı sunucu neye bakıyor?

Bir iletinin gelen kutusuna mı spam klasörüne mi gideceğine karar verilirken birçok sinyal birlikte değerlendirilir. Bunlar kabaca üç gruba ayrılır:

• Kimlik: Gönderen sunucunun alan adınız adına gönderim yetkisi var mı (SPF)? İleti alan adınız tarafından imzalanmış ve yolda değiştirilmeden mi gelmiş (DKIM)? Bu kontroller iletinin görünen gönderen adresiyle uyumlu mu (DMARC)?
• İtibar: Gönderen IP adresi ve alan adı daha önce spam göndermekle anılmış mı, bir kara listede yer alıyor mu?
• İçerik ve davranış: İleti yalnızca görselden mi oluşuyor, kısaltılmış bağlantılar mı içeriyor, alıcılar bu göndericinin iletilerini sık sık spam olarak mı işaretliyor?

Kimlik kısmı eksikse diğer sinyaller ne kadar iyi olursa olsun ileti dezavantajlı başlar. Bu yüzden işe SPF, DKIM ve DMARC'tan başlamak gerekir.

SPF: alan adınız adına kim gönderebilir?

SPF (Sender Policy Framework), alan adınız adına e-posta göndermeye yetkili sunucuların listesidir ve alan adınıza eklenen bir TXT kaydıyla yayımlanır. Aşağıdaki örneklerde alan adı ve adresler yalnızca örnek amaçlıdır:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.saglayici.example -all"

Bu kayıt, 203.0.113.10 adresindeki sunucunun ve e-posta sağlayıcınızın listelediği sunucuların gönderim yapabileceğini, bunların dışındaki her yerden gelen iletilerin ise SPF kontrolünden kalması gerektiğini söyler. Sondaki -all kesin başarısızlığı, ~all ise "şüpheli say" anlamına gelen yumuşak başarısızlığı belirtir.

SPF'te sık yapılan hatalar

• Birden fazla SPF kaydı: Bir alan adında yalnızca bir SPF kaydı bulunmalıdır. İki ayrı v=spf1 kaydı kontrolün hata vermesine yol açar; yeni bir gönderici mevcut kayda eklenmelidir.
• 10 DNS sorgusu sınırı: include, a, mx gibi mekanizmaların her biri DNS sorgusu gerektirir ve toplam sınır 10'dur. Hizmet ekledikçe bu sınır aşılırsa SPF geçersiz sayılır.
• Unutulan göndericiler: Web sitenizin iletişim formu, fatura ya da muhasebe yazılımı, bülten hizmeti, doğrudan internete gönderim yapan tarayıcılı yazıcılar alan adınız adına e-posta gönderiyor olabilir. Listeye eklenmeyen göndericilerin iletileri kontrolden kalır.
• +all kullanmak: Bu ifade herkese gönderim yetkisi verir ve SPF'i anlamsız kılar.

SPF'in iki sınırı daha var. Kontrol, iletinin görünen "Kimden" adresine değil, zarf adresine (Return-Path) bakar. Ayrıca bir ileti başka bir adrese yönlendirildiğinde, yönlendiren sunucu SPF listenizde olmadığı için kontrol başarısız olabilir. Bu eksikleri DKIM ve DMARC kapatır.

DKIM: iletiye eklenen dijital imza

DKIM (DomainKeys Identified Mail), gönderen sunucunun her iletiyi özel bir anahtarla imzalamasıdır. İmzayı doğrulamak için gereken açık anahtar, DNS'te seçici (selector) adı verilen bir ön ekle yayımlanır:

secici1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(açık anahtar)"

Alıcı sunucu, ileti başlığındaki imzayı bu açık anahtarla doğrular. İmza geçerliyse iki şey kanıtlanmış olur: ileti, imzayı atan alan adının yetkili sunucusundan çıkmıştır ve imzalanan kısımlar yolda değiştirilmemiştir. DKIM, SPF'ten farklı olarak yönlendirmede de çoğu zaman geçerliliğini korur; ancak iletiye alt bilgi ekleyen e-posta listeleri gibi aracılar imzayı bozabilir.

• Anahtar uzunluğu: Bugün 2048 bitlik RSA anahtar önerilir; 1024 bit alt sınır kabul edilir.
• Üçüncü taraf göndericiler: Bülten hizmeti ya da fatura yazılımı gibi göndericilerin de alan adınızla imza atacak şekilde yapılandırılması gerekir. Bu hizmetlerin çoğu, eklemeniz gereken DNS kayıtlarını size verir.
• Anahtar yenileme: Anahtarları belirli aralıklarla yeni bir seçiciyle değiştirmek, eski bir anahtarın ele geçirilmesi riskini azaltır.

DMARC: kontrol başarısız olursa ne olacak?

SPF ve DKIM tek başına alıcı sunucuya ne yapması gerektiğini söylemez; yalnızca bir sonuç üretir. DMARC (Domain-based Message Authentication, Reporting and Conformance) bu sonuçları iletinin görünen "Kimden" adresine bağlar ve alan adı sahibinin politikasını bildirir. Kayıt _dmarc ön ekiyle yayımlanır:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapor@example.com"

Hizalama

DMARC'tan geçmek için SPF ya da DKIM'den en az birinin başarılı olması ve kontrol edilen alan adının, iletinin "Kimden" adresindeki alan adıyla uyumlu olması gerekir. Örneğin bülten hizmetiniz iletiyi kendi alan adıyla imzalıyorsa DKIM geçer ama hizalanmaz; DMARC açısından bu imza işe yaramaz.

Politika: none, quarantine, reject

• p=none: Yalnızca izle. Kontrolden geçemeyen iletiler için bir işlem istenmez ama raporlar gelir.
• p=quarantine: Kontrolden geçemeyen iletiler spam klasörüne alınsın.
• p=reject: Kontrolden geçemeyen iletiler hiç kabul edilmesin.

Raporlar

rua etiketiyle belirtilen adrese, alıcı sunuculardan alan adınız adına gönderilen iletilerin özet raporları gelir. Bu raporlar XML biçimindedir ve okunması zahmetlidir, ama değerli bir bilgi taşır: alan adınız adına kimlerin, hangi sunuculardan e-posta gönderdiğini gösterir. Unuttuğunuz meşru göndericileri de, adınızı taklit eden sahte gönderimleri de burada görürsünüz.

Üç kaydın kısa karşılaştırması

Kayıtlar doğru ama hâlâ spama düşüyorsa

SPF, DKIM ve DMARC geçiyor ama iletiler hâlâ spam klasörüne gidiyorsa şu başlıklara bakın:

• Ters DNS (PTR) kaydı: Kendi mail sunucunuzu çalıştırıyorsanız, gönderen IP adresinin ters DNS kaydı sunucunun adını göstermeli ve bu ad da aynı IP adresine çözülmelidir. Ters DNS kaydını IP adresinin sahibi, yani barındırma firması ya da internet servis sağlayıcınız tanımlar.
• Sunucunun tanıtım adı (HELO/EHLO): Sunucunun bağlantı sırasında kendini tanıttığı ad, gerçek ve çözülebilir bir alan adı olmalıdır.
• Kara listeler: IP adresiniz ya da alan adınız bir kara listeye girmiş olabilir. Sebep çoğu zaman ele geçirilmiş bir kullanıcı hesabından yapılan spam gönderimidir; önce sebep giderilmeli, sonra listeden çıkma talebinde bulunulmalıdır.
• Paylaşılan IP itibarı: Aynı IP adresinden başka firmalar da gönderim yapıyorsa onların davranışı sizin teslim oranınızı etkileyebilir.
• İçerik: Yalnızca görselden oluşan iletiler, kısaltılmış bağlantılar, şifreli arşiv ekleri ve ani hacim artışları puanı düşürür. Toplu gönderimlerde abonelikten çıkma bağlantısı bulunmalıdır.

Ele geçirilmiş bir e-posta hesabı itibarınızı ve güvenliğinizi aynı anda tehdit eder. Kullanıcı hesaplarında çok faktörlü kimlik doğrulama ve oltalamaya karşı farkındalık bu yüzden teslim oranı için de önemlidir; bu konuyu fidye yazılımına karşı katmanlı savunma yazımızda da ele aldık.

Kendi alan adınızı nasıl kontrol edersiniz?

Kayıtlarınızın yayında olup olmadığını komut satırından görebilirsiniz. Windows'ta:

nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com
nslookup -type=txt secici1._domainkey.example.com

Linux ve diğer Unix benzeri sistemlerde aynı işi dig yapar:

dig +short TXT example.com
dig +short TXT _dmarc.example.com

DKIM seçicinizin adını bilmiyorsanız, gönderdiğiniz bir iletinin başlığındaki DKIM-Signature satırında s= etiketinin değerine bakın. En güvenilir test ise gerçek bir iletiyle yapılır: farklı bir sağlayıcıdaki bir test adresine e-posta gönderin, gelen iletinin başlıklarını açın ve Authentication-Results satırını okuyun. spf=pass, dkim=pass ve dmarc=pass ifadelerini görüyorsanız kimlik tarafı tamamdır.

Adım adım devreye alma planı

1. Alan adınız adına e-posta gönderen her şeyi listeleyin: mail sunucusu ya da hizmeti, web sitesi, fatura ve muhasebe yazılımları, bülten hizmeti, cihazlar.
2. Hepsini tek bir SPF kaydında toplayın ve 10 sorgu sınırını kontrol edin. İlk aşamada ~all ile başlayabilirsiniz.
3. Her gönderici için DKIM imzasını açın ve açık anahtarları DNS'e ekleyin.
4. DMARC kaydını p=none ve bir rapor adresiyle yayımlayın.
5. Birkaç hafta boyunca raporları inceleyin; eksik kalan meşru göndericileri SPF'e ve DKIM'e ekleyin.
6. Politikayı önce p=quarantine, raporlar temiz kaldığında p=reject düzeyine yükseltin.
7. E-posta göndermeyen alan adlarınız için de v=spf1 -all ve p=reject içeren kayıtlar yayımlayın; böylece bu alan adları sahte gönderimlerde kullanılamaz.

Kurumsal mail altyapınızı kurarken ya da taşırken bu kayıtları baştan doğru yazmak, sonradan yaşanacak teslim sorunlarının çoğunu önler. Kurumsal mail hizmetimizde SPF, DKIM ve DMARC yapılandırması ile ilk haftalardaki teslim ve DMARC rapor takibi kapsamın bir parçasıdır.

Sık sorulan sorular