"SPF Softfail" ile "SPF Hardfail" Arasındaki Fark

E-posta altyapınızda SPF kaydı tanımlamak artık bir tercih değil, bir zorunluluk. Ancak SPF kaydının sonunda yer alan ~all ile -all direktifleri arasındaki fark, teslim edilebilirlik, kimlik avı koruması ve DMARC uyumu açısından kritik sonuçlar doğurur. Bu yazıda iki direktifin teknik farklarını, RFC 7208 çerçevesinde nasıl işlendiğini ve hangi koşulda hangisinin tercih edilmesi gerektiğini ele alıyoruz.

SPF Nedir ve Neden Önemlidir?

Sender Policy Framework (SPF), RFC 7208 ile standartlaştırılmış, alan adı sahiplerinin hangi IP adreslerinin kendi adlarına e-posta gönderebileceğini DNS TXT kaydı aracılığıyla bildirdiği bir e-posta kimlik doğrulama protokolüdür. Alıcı posta sunucusu, gelen bir iletinin zarfındaki MAIL FROM adresi (RFC 5321 terminolojisiyle "return-path") ile DNS'teki SPF kaydını karşılaştırarak doğrulama yapar.

SPF kaydı, meşru göndericileri listeleyen çeşitli mekanizmalar (ip4, ip6, include, a, mx vb.) içerir ve bir "all" direktifiyle sonlandırılır. Bu son direktif, kayıtta listelenmeyen tüm göndericiler için ne yapılacağını tanımlar.

SPF Sonuç Durumları: RFC 7208 Perspektifi

RFC 7208, Bölüm 8'de SPF değerlendirmesinin üretebileceği sonuçları tanımlar. Bu sonuçlar arasında en sık karıştırılan ikisi Softfail ve Fail (Hardfail) durumlarıdır:

Softfail (~all) Ayrıntılı İnceleme

Softfail, RFC 7208 Bölüm 8.5'te şöyle tanımlanır: "Etki alanı sahibi, IP adresinin yetkili olmadığını düşünür, ancak bu sonucu ilke ihlali olarak ele almak için yetersiz güven duyuyor." Bu tanım, softfail'in ne zaman kullanılması gerektiğine dair en önemli ipucunu içerir: geçiş dönemi ve test aşaması.

Softfail durumunda alıcı sunucu teknik olarak iletiyi reddermek zorunda değildir. Gmail, Microsoft 365 ve diğer büyük sağlayıcılar genellikle softfail alan iletileri spam klasörüne yönlendirir ya da X-Spam-Status başlığına puan ekler. Ancak bu davranış garantili değildir; bazı sunucular softfail iletilerini doğrudan gelen kutusuna iletebilir.

Öte yandan Google Postmaster Tools verileri, ~all kullanan alan adlarından gelen kimlik avı e-postalarının önemli bir bölümünün teslimata ulaştığını göstermektedir. Bu durum, softfail'in uzun vadeli bir güvenlik politikası olarak kullanılmaması gerektiğinin somut kanıtıdır.

Hardfail (-all) Ayrıntılı İnceleme

Hardfail, RFC 7208 Bölüm 8.4'te "etki alanı sahibi, IP adresinin ilgili kimliği göndermek için yetkili olmadığını kesinlikle ifade ediyor" biçiminde tanımlanır. -all direktifi, kayıtta yer almayan her gönderici IP adresinin sahte (spoofed) olduğunu açıkça beyan eder.

Alıcı sunucu, hardfail alan bir iletiyi SMTP düzeyinde reddedebilir (550 5.7.1 hatası) veya spam klasörüne yönlendirebilir. Microsoft 365 belgelerine göre Exchange Online Protection (EOP), SPF hardfail durumunu yüksek güven skorlu spam sinyali olarak değerlendirir ve iletiyi BCL:9 puanıyla işaretleyebilir.

DMARC ile Etkileşim: Kritik Fark Burada Ortaya Çıkıyor

SPF'nin tek başına çok sınırlı bir yaptırım gücü vardır çünkü her alıcı sunucu softfail veya hardfail sonucunu farklı yorumlayabilir. Gerçek yaptırım gücü, RFC 7489 ile standartlaştırılan DMARC (Domain-based Message Authentication, Reporting, and Conformance) ile birleştiğinde ortaya çıkar.

DMARC, SPF ve DKIM sonuçlarını "identifier alignment" kuralıyla değerlendirir: MAIL FROM alanındaki alan adı ile From: başlığındaki alan adı örtüşüyorsa ve SPF pass döndürüyorsa, DMARC uyumu sağlanmış sayılır. Softfail (~all) bir SPF sonucu, DMARC açısından fail anlamına gelir; hardfail (-all) da aynı şekilde DMARC fail'e yol açar.

Bu noktada kritik soru şudur: DMARC politikanız p=reject ise, gelen ileti zaten reddedilir. Dolayısıyla DMARC kullanan alan adları için ~all ile -all arasındaki pratik fark azalır. Ancak DMARC'ı henüz devreye almamış alan adları için -all çok daha güçlü bir ilk savunma hattı oluşturur.

SPF Lookup Sınırı: 10 DNS Sorgusu Kuralı

RFC 7208, Bölüm 4.6.4 gereğince bir SPF kaydının değerlendirilmesi sırasında yapılabilecek maksimum DNS araması sayısı 10 ile sınırlıdır. include, a, mx ve redirect mekanizmalarının her biri bu sayacı tüketir. 10 sınırı aşıldığında SPF sonucu otomatik olarak PermError döner; bu durumda hem softfail hem de hardfail direktifinin önemi kalmaz çünkü kayıt hiç değerlendirilemez.

MXToolbox, dmarcian veya EasyDMARC gibi araçlarla periyodik SPF analizi yapmak, lookup sayısını kontrol altında tutmanın en pratik yoludur.

Hangi Direktifi Kullanmalısınız?

Direktif seçimi, alan adının e-posta altyapısının olgunluk düzeyine ve risk toleransına bağlıdır:

• Yeni alan adları veya SPF geçiş dönemi: ~all ile başlayın; tüm meşru gönderici kaynaklarını (CRM, ESP, transactional mail servisi vb.) kayda ekledikten sonra -all'a geçin.
• Kararlı üretim ortamı: -all kullanın. Tüm meşru göndericiler kayıtta tanımlıysa, yetkisiz göndericilerin teslim edilmesi için hiçbir neden yoktur.
• DMARC p=reject politikası aktif alan adları: Teknik olarak ~all yeterli olsa da -all ek güvenlik katmanı sağlar ve SPF'nin DMARC bağımsız çalıştığı edge-case senaryolarda koruyucudur.
• E-posta göndermeyen alan adları (parked domain): v=spf1 -all ile hiçbir göndericiyi yetkilendirmeyin. Bu yaklaşım, alan adınızın kimlik avı kampanyalarında kullanılmasını önemli ölçüde zorlaştırır.

Gerçek Dünya Senaryosu: Hata Ayıklama

Bir müşterinin posta sunucusu gelen bir iletide aşağıdaki Authentication-Results başlığını üretiyorsa:

Authentication-Results: mx.example.com;
  spf=softfail (domain of sender@ornek.com does not designate 203.0.113.45 as permitted sender)
    smtp.mailfrom=sender@ornek.com

Bu başlık, gönderen IP adresinin (203.0.113.45) ornek.com'un SPF kaydında yer almadığını ve kaydın ~all ile bittiğini gösterir. İleti teslim edilmiş, ancak SPF kontrolünden geçememiştir. Eğer kayıt -all ile bitmiş olsaydı başlık spf=fail şeklinde görünecek ve iletinin reddedilme olasılığı çok daha yüksek olacaktı.

Sorunun kaynağını bulmak için şu adımlar uygulanabilir: önce dig TXT ornek.com komutuyla mevcut SPF kaydı kontrol edilir; ardından 203.0.113.45 adresinin hangi servis tarafından kullanıldığı araştırılır (üçüncü taraf ESP, SMTP röle vb.); son olarak ilgili IP veya include: mekanizması kayda eklenerek -all'a geçilir.

Sık Sorulan Sorular