SPF (Sender Policy Framework) Nedir?
Kısa tanım
SPF (Sender Policy Framework), bir alan adı adına hangi sunucuların e-posta göndermeye yetkili olduğunu DNS'te bir TXT kaydıyla ilan eden e-posta kimlik doğrulama yöntemidir (RFC 7208). Alıcı sunucu, iletiyi gönderen IP adresinin bu listede olup olmadığını kontrol eder. SPF, görünür Kimden (From) adresini değil zarf göndereni (MAIL FROM) denetler; bu yüzden tek başına değil DKIM ve DMARC ile birlikte anlam kazanır.
Diğer adları: Sender Policy Framework, SPF kaydı, SPF record, v=spf1
Bir SPF kaydının anatomisi
SPF politikası alan adının köküne bir TXT kaydı olarak yazılır ve soldan sağa okunur:
example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.eposta-ornek.net include:bulten-ornek.com -all"v=spf1: kaydın SPF olduğunu belirtir; başka sürüm yoktur.ip4/ip6: belirli bir adresi veya aralığı yetkilendirir.a/mx: alan adının A veya MX kayıtlarındaki sunuculara izin verir.include: başka bir alan adının SPF politikasını içeri alır; e-posta sağlayıcıları ve bülten servisleri bu şekilde eklenir.all: önceki hiçbir mekanizmayla eşleşmeyen her şeyi yakalar; bu yüzden en sonda durur.
Mekanizmaların önündeki niteleyici sonucu belirler: + geçer (varsayılan), - başarısız (fail), ~ yumuşak başarısız (softfail), ? nötr.
SPF tam olarak neyi kontrol eder?
Alıcı sunucu SPF'yi SMTP konuşması sırasında, zarf göndereni denilen MAIL FROM adresinin alan adı (ve HELO/EHLO adı) için uygular. Kullanıcının e-posta programında gördüğü From: başlığı bu kontrolün parçası değildir. Bir sahtekâr kendi alan adını zarf gönderen olarak kullanıp From: başlığına sizin adresinizi yazarsa SPF geçebilir. Bu boşluğu kapatan, iki alan adının uyumlu olmasını isteyen DMARC'tır.
SPF'nin ikinci zayıf noktası yönlendirmedir (forwarding): ileti bir aracı sunucu tarafından başka bir adrese aktarıldığında gönderen IP artık aracınınkidir ve SPF başarısız olur. Yönlendirmeye dayanıklı olan DKIM imzası bu yüzden SPF'nin tamamlayıcısıdır.
10 DNS sorgusu sınırı
RFC 7208, değerlendirme sırasında DNS sorgusu gerektiren terimlerin toplamını 10 ile sınırlar: include, a, mx, ptr, exists ve redirect bu sayıya dahildir, iç içe include'lar da sayılır. Sınır aşılırsa sonuç permerror olur ve alıcının gözünde SPF hiç yokmuş gibi davranılabilir. Her yeni SaaS aracı kendi include'unu istediğinde bu sınıra fark etmeden ulaşılır. Çözüm yolları:
- Artık kullanılmayan servislerin include'larını silmek.
- Yavaş ve standart tarafından önerilmeyen
ptrmekanizmasından kaçınmak. - Toplu gönderimleri ayrı bir alt alan adından yapmak; her alt alan adının kendi SPF kaydı ve kendi sınırı olur.
Include'ları IP listesine çeviren “SPF flattening” yöntemi de vardır; ancak sağlayıcı IP'lerini değiştirdiğinde liste eskir, bu yüzden otomatik güncellenmiyorsa risklidir.
Tek kayıt kuralı ve -all tercihi
Bir alan adında yalnızca bir v=spf1 kaydı olabilir; iki kayıt varsa değerlendirme permerror ile biter. Yeni servis eklerken mevcut kayda include ekleyin. Sonun ~all mı -all mı olacağı ise gönderim envanterinize güvenmenize bağlıdır. Tüm meşru kaynakları bildiğinizden emin olduğunuzda -all daha net bir beyandır; günümüzde alıcıların çoğu nihai kararı DMARC politikasıyla birlikte verir.
Büyük posta sağlayıcılarının beklentisi
Google ve Yahoo, Şubat 2024'ten itibaren gönderici şartlarını sıkılaştırdı. Her iki şirketin belgelerine göre tüm göndericilerin en azından SPF veya DKIM kullanması gerekir; Google'ın tanımıyla kişisel Gmail hesaplarına günde 5.000'den fazla ileti gönderen toplu göndericilerden ise SPF ve DKIM'in birlikte, ayrıca DMARC kaydı ve alan adı uyumu beklenir. Bu şartlar teslim edilebilirliği etkiler; SPF kaydı olması tek başına postanın gelen kutusuna düşeceğini garanti etmez.