SPF SoftFail ve HardFail Farkı

SPF kaydınızı yazarken en sona geldiğinizde bir karar vermeniz gerekiyor: ~all mı -all mı? İnternette bu konuda birbiriyle çelişen tavsiyeler dolaşıyor — kimi "güvenlik için mutlaka -all kullanın" diyor, kimi "-all yüzünden yönlendirilen mailleriniz kaybolur" diyor. İkisi de kısmen doğru ve ikisi de eksik. SPF SoftFail ve HardFail arasındaki fark, teknik olarak tek bir karakterden ibaret ama sonuçları alan adınızın kimlerden mail alabileceğini ve sahte gönderimlerin nasıl karşılanacağını doğrudan belirliyor.

Bu yazıda all mekanizmasının ne yaptığını, SoftFail ile HardFail'in alıcı tarafında nasıl farklı değerlendirildiğini, SPF'in yönlendirme karşısında neden kırıldığını, DMARC devredeyken bu seçimin ne kadar önemli kaldığını ve kendi kurulumunuzda hangisini seçmeniz gerektiğini anlatacağım. Ayrıca SPF kayıtlarını sessizce geçersiz kılan tuzakları da ele alacağım.

SPF Kaydının Sonundaki all Ne Yapar#

Bir SPF kaydı, alan adınız adına mail göndermeye yetkili kaynakları soldan sağa sıralayan bir mekanizma listesidir. Alıcı sunucu, gönderen IP'yi bu listeyle karşılaştırır ve ilk eşleşen mekanizmada durur. all mekanizması her zaman eşleşir, dolayısıyla listenin en sonunda yer alır ve "yukarıdakilerin hiçbirine uymayan her şey" anlamına gelir.

all'ın önündeki karakter, o eşleşmenin nasıl yorumlanacağını söyleyen niteleyicidir (qualifier):

Tipik bir kayıt şöyle görünür:

; Kendi mail sunucumuz + kullandığımız gönderim servisi, gerisi yetkisiz
firmaniz.com.   3600  IN  TXT  "v=spf1 ip4:185.12.34.56 include:servis.net -all"

; Aynı kaydın yumuşak sürümü
firmaniz.com.   3600  IN  TXT  "v=spf1 ip4:185.12.34.56 include:servis.net ~all"

Kritik bir noktayı baştan netleştirelim: ~all ile -all arasındaki fark sizin sunucunuzda değil, alıcının filtresinde ortaya çıkar. Siz yalnızca bir politika beyan edersiniz; o politikayla ne yapılacağına alıcı karar verir. Standart (RFC 7208) alıcılara bağlayıcı bir davranış dayatmaz, yalnızca tavsiye eder.

SoftFail (~all) Nasıl Değerlendirilir#

SoftFail'in tasarım amacı, geçiş dönemleri için bir ara durum sunmaktı. Anlamı şudur: "Bu IP'nin benim adıma göndermeye yetkisi olmadığını düşünüyorum, ama tüm gönderim yollarımı listelediğimden yüzde yüz emin değilim; mesajı reddetme, kabul et ve şüpheli olarak işaretle."

Pratikte alıcı sunucular SoftFail'i çoğunlukla şöyle karşılar: mesaj kabul edilir, spam skoruna küçük bir puan eklenir ve nihai karar diğer sinyallerle birlikte verilir. Yani SoftFail tek başına mesajı ne teslim eder ne de reddeder; terazinin bir kefesine ufak bir ağırlık koyar. Mail başlığında sonucu şöyle görürsünüz:

Authentication-Results: mx1.ornek.com;
	spf=softfail (mx1.ornek.com: domain of transitioning
	 [email protected] does not designate 203.0.113.44 as permitted sender)
	 smtp.mailfrom=firmaniz.com

Buradaki transitioning kelimesi tesadüf değil; SoftFail'in "geçiş halinde" anlamını taşıdığını hatırlatır. SoftFail'in en büyük avantajı hoşgörülü olmasıdır: bir gönderim yolunuzu SPF kaydına eklemeyi unuttuysanız mailleriniz kaybolmaz, sadece biraz daha zor teslim edilir. En büyük dezavantajı da aynı yerden gelir — alan adınız adına sahte mail gönderen birine karşı da aynı hoşgörüyü gösterir.

HardFail (-all) Nasıl Değerlendirilir#

HardFail net bir beyandır: "Listelediğim kaynaklar dışında hiçbir IP benim adıma mail gönderemez. Aksini görürseniz o mesaj sahtedir." Alıcı sunucular bunu genellikle iki şekilde uygular. Bir kısmı mesajı SMTP oturumu sırasında doğrudan reddeder ve gönderene bir bounce döner; bir kısmı ise kabul edip spam klasörüne koyar veya DMARC politikanıza göre hareket eder.

Authentication-Results: mx1.ornek.com;
	spf=fail (mx1.ornek.com: domain of [email protected]
	 does not designate 203.0.113.44 as permitted sender)
	 smtp.mailfrom=firmaniz.com

HardFail'in avantajı açıktır: alan adınızı taklit eden mesajlar için en güçlü sinyali verirsiniz ve marka itibarınızı korursunuz. Dezavantajı da aynı derecede açıktır: listede olmayan meşru bir gönderim yolunuz varsa o yoldan çıkan mailler kaybolur. Ve bu kayıp sessiz olmaz, bounce döner — yani müşteriniz "faturamı alamadım" der ve siz de sebebini haftalar sonra fark edersiniz.

Bu yüzden -all'a geçmeden önce tüm gönderim yollarınızı envanterlemeniz gerekir. Tipik olarak gözden kaçanlar şunlardır: web sitesinin iletişim formundan çıkan mailler, fatura veya muhasebe yazılımı, CRM ve destek sistemi, işe alım platformu, pazarlama otomasyonu, ofisteki çok fonksiyonlu yazıcının tarama-mail özelliği ve eski bir sunucuda unutulmuş bir cron betiği. Bunların hepsini bulmanın en güvenilir yolu DMARC toplu raporlarıdır; nasıl okunacağını DMARC raporu nasıl okunur yazısında anlattım.

Yönlendirme Sorunu: SPF'in Kırıldığı Yer#

SPF'in en bilinen zaafı, mail yönlendirmede ortaya çıkar ve -all tartışmasının merkezinde tam olarak bu durur. Senaryo şöyle işler: Siz firmaniz.com adresinden bir müşteriye mail gönderirsiniz. Müşteri, kurumsal adresine gelen mailleri kişisel Gmail hesabına yönlendirmektedir. Yönlendiren sunucu mesajı alır ve Gmail'e teslim eder — ama zarftaki gönderen adresi hâlâ sizin alan adınızdır, gönderen IP ise artık yönlendiren sunucunun IP'sidir.

Gmail bu noktada SPF kontrolü yapar: firmaniz.com alan adının SPF kaydında yönlendiren sunucunun IP'si yoktur, çünkü olması için hiçbir sebep yoktur. Sonuç -all ile fail, ~all ile softfail olur. Aynı mekanizma posta listelerinde de çalışır: listeye gönderdiğiniz mesaj, liste sunucusu tarafından tüm abonelere yeniden dağıtılır ve o dağıtımda SPF sizin adınıza kalır.

Bu sorunun standart çözümü SRS (Sender Rewriting Scheme) adı verilen yeniden yazma yöntemidir: yönlendiren sunucu, zarftaki gönderen adresini kendi alan adına dönüştürür, böylece SPF kontrolü kendi kaydı üzerinden yapılır ve geçer. Ancak SRS'i uygulayacak olan yönlendiren taraftır, siz değil — yani kontrol sizde değildir.

İşte bu yüzden, DKIM devreye girdiğinde tablo tamamen değişir. DKIM imzası mesajın içinde taşınır ve yönlendirmeden etkilenmez (mesaj değiştirilmediği sürece). Yani yönlendirilen bir mesajda SPF fail verse bile DKIM pass verir ve DMARC değerlendirmesi geçer. Bu, -all kullanmayı güvenli hale getiren asıl mekanizmadır. DKIM imzanız düzgün çalışmıyorsa DKIM doğrulaması başarısız yazısındaki teşhis adımlarını uygulayın.

DMARC ile Birlikte: Hangisi Gerçekten Fark Eder#

Burası çoğu tartışmanın atladığı nokta ve kararı ciddi biçimde basitleştiriyor: DMARC değerlendirmesi açısından ~all ile -all arasında hiçbir fark yoktur. DMARC yalnızca "SPF geçti ve hizalandı mı" diye sorar; softfail de fail de bu sorunun cevabını "hayır" yapar. Yani p=reject politikanız varsa, sahte bir mesaj ~all ile de reddedilir.

O halde fark nerede kalır? İki yerde. Birincisi, DMARC'ı henüz devreye almadıysanız veya p=none modundaysanız: bu durumda alıcı sadece SPF sonucuna bakar ve -all ile ~all arasındaki fark doğrudan davranışa yansır. İkincisi, DMARC kaydını hiç okumayan veya bağlantı aşamasında SPF'e göre karar veren alıcılarda: bazı sunucular -all gördüğünde mesajı DATA aşamasına bile geçirmeden reddeder.

Üç senaryoyu yan yana koyalım:

Tablodan çıkan pratik sonuç şudur: sahteciliğe karşı asıl korumayı DMARC sağlar, SPF'in son karakteri değil. Bu yüzden enerjinizi ~all/-all tartışmasına değil, DMARC'ı p=none'dan p=reject'e taşımaya harcayın. Hizalama mekanizmasını anlamadan bu geçişi yapmayın; DMARC alignment nedir yazısı bu adımın ön koşulunu anlatıyor.

Hangisini Ne Zaman Kullanmalısınız#

Pratik tavsiyem aşamalı bir yol izlemektir. Yeni kurulan veya envanteri belirsiz bir alan adında doğrudan -all ile başlamak, henüz farkında olmadığınız gönderim yollarını kesmek demektir. Sırayla ilerleyin:

1. ~all ile başlayın ve aynı anda DMARC'ı p=none; rua=... olarak yayınlayın. Bu aşamada hiçbir mail kaybolmaz, ama rapor toplamaya başlarsınız.
2. En az iki hafta DMARC raporlarını okuyun. Raporlarda alan adınız adına gönderim yapan tüm IP'leri göreceksiniz; tanımadıklarınızı araştırın.
3. Meşru olan tüm kaynakları SPF kaydına ekleyin ve mümkün olan hepsinde DKIM imzasını da devreye alın. DKIM, -all'a geçişi güvenli kılan asıl güvence ağıdır.
4. Raporlarda hizalamayan meşru kaynak kalmadığında DMARC'ı önce p=quarantine, sonra p=reject'e taşıyın.
5. En son adımda SPF kaydını -all yapın. Bu noktada zaten envanteriniz tamdır ve DKIM devrededir; geçiş risksizdir.

Şu iki durumda -all neredeyse zorunludur: alan adınız markalaşmışsa ve taklit edilme riski varsa (banka, e-ticaret, kamu kurumu benzeri), ya da hiç mail göndermeyen bir alan adınız varsa. İkincisi özellikle önemli: yalnızca web sitesi barındıran veya park halinde duran alan adlarına kesinlikle katı bir SPF verin.

; Hiç mail göndermeyen bir alan adı için doğru kayıt seti
parkalan.com.        3600  IN  TXT  "v=spf1 -all"
_dmarc.parkalan.com. 3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"
*._domainkey.parkalan.com. 3600 IN TXT "v=DKIM1; p="

Bu üçlü, alan adınızın adına mail gönderilmesini fiilen imkânsız hale getirir. Spoofing riskini bütünüyle azaltma yöntemleri için e-posta spoofing önleme yazısına bakabilirsiniz.

Sık Yapılan Hatalar ve SPF Tuzakları#

En yaygın ve en sessiz hata, alan adında birden fazla v=spf1 kaydı bulunmasıdır. Standart bunu açıkça yasaklar; iki kayıt varsa değerlendirme permerror ile biter ve SPF'iniz hiç çalışmaz — -all da ~all da anlamsız hale gelir. Bu genellikle iki farklı servisin kurulum sihirbazının ayrı ayrı kayıt eklemesiyle olur. Doğru çözüm mekanizmaları tek kayıtta birleştirmektir:

# Kaç tane v=spf1 kaydı var? Cevap 1'den büyükse acil düzeltin
dig +short firmaniz.com TXT | grep -c "v=spf1"

# Kayıttaki DNS sorgusu gerektiren mekanizmaları say (limit 10)
dig +short firmaniz.com TXT | grep "v=spf1" | \
  grep -oE "(include|a|mx|ptr|exists|redirect)[:=]?" | wc -l

İkinci tuzak 10 DNS sorgusu limitidir. SPF değerlendirmesi sırasında include, a, mx, ptr, exists ve redirect mekanizmalarının her biri DNS sorgusu üretir ve toplam 10'u aşarsa sonuç yine permerror olur. Üç dört servis eklendiğinde bu sınır şaşırtıcı hızda dolar, çünkü bir include kendi içinde başka include'lar barındırabilir. Kullanmadığınız servisleri kayıttan çıkarmak en etkili çözümdür.

Üçüncü hata ptr mekanizmasını kullanmaktır. Bu mekanizma standartta açıkça önerilmez: yavaştır, DNS'e gereksiz yük bindirir ve bazı alıcılar tarafından tamamen yok sayılır. Kaydınızda ptr varsa çıkarın.

Dördüncüsü, +all yazmaktır — ki bu, dünyadaki herkesin alan adınız adına mail göndermeye yetkili olduğunu ilan etmek demektir. Genellikle "SPF yüzünden mailim gitmiyor" diye panikleyip niteleyiciyi denemeye başlayan birinin elinden çıkar ve SPF'i olmamasından daha kötü bir duruma sokar.

Beşincisi ise SPF'in From başlığını kontrol ettiğini sanmaktır. SPF, zarftaki gönderen adresini (Return-Path / MAIL FROM) kontrol eder; kullanıcının gördüğü From başlığını değil. Bu ikisi meşru biçimde farklı olabilir ve DMARC hizalamasının varlık sebebi tam olarak budur. Başlıklardan hangi alan adının kontrol edildiğini görmek için mail başlıklarını okuma ve analiz etme yazısındaki Authentication-Results bölümüne bakın.

Sıkça Sorulan Sorular#

~all mı -all mı kullanmalıyım#

Kısa cevap: DMARC'ı p=reject seviyesine taşıdıysanız ve tüm gönderim kaynaklarınızda DKIM imzası varsa -all kullanın. Henüz envanteriniz net değilse veya DMARC p=none modundaysa ~all ile başlayın. Aradaki fark yalnızca DMARC devrede olmadığı senaryolarda belirleyicidir; DMARC p=reject ile ikisi de aynı sonucu verir.

SPF SoftFail alan mailler spam'e mi düşer#

Genellikle doğrudan spam'e düşmez, ancak spam skoruna bir puan eklenir ve nihai karar diğer sinyallerle birlikte verilir. Yani SoftFail tek başına belirleyici değildir; DKIM imzanız geçiyorsa ve içeriğiniz temizse mail büyük olasılıkla gelen kutusuna ulaşır. Ama itibarınız zaten sınırdaysa SoftFail teraziyi spam tarafına çevirebilir.

-all kullanınca maillerim kaybolur mu#

Yalnızca SPF kaydında listelenmemiş bir kaynaktan mail gönderiyorsanız ve o mesajda geçerli bir DKIM imzası yoksa kaybolabilir. Bu yüzden geçişten önce tüm gönderim yollarınızı envanterlemek ve DKIM'i her yolda devreye almak gerekir. DKIM devredeyse yönlendirilen mailler bile güvendedir, çünkü imza mesajın içinde taşınır ve yönlendirmeden etkilenmez.

SPF kaydımın doğru olup olmadığını nasıl kontrol ederim#

Önce dig +short firmaniz.com TXT | grep spf1 ile kaydın tek olduğunu doğrulayın; birden fazla v=spf1 kaydı SPF'i tamamen devre dışı bırakır. Ardından DNS sorgusu üreten mekanizmaları sayarak 10 limitini aşmadığınızdan emin olun. Son olarak kendinize bir test maili gönderip başlıktaki Authentication-Results satırında spf=pass gördüğünüzü teyit edin — kaydın var olması çalıştığı anlamına gelmez.

SPF kaydı değişikliği ne kadar sürede etkili olur#

Kaydın TTL değeri kadar. TTL'iniz 3600 ise değişikliğin tüm çözümleyicilere yayılması en fazla bir saat sürer; 86400 ise bir güne kadar uzayabilir. SPF üzerinde çalışacaksanız değişiklikten en az bir gün önce TTL'i 300 seviyesine indirin, işiniz bittikten sonra tekrar yükseltin. Böylece bir hata yaparsanız dakikalar içinde geri alabilirsiniz.

Yönlendirilen mailler için ne yapmalıyım#

Yönlendirme SPF'i kaçınılmaz olarak kırar ve bunu düzeltmek yönlendiren tarafın işidir (SRS uygulaması). Sizin tarafınızdaki doğru çözüm DKIM'dir: mesajın içinde taşınan imza yönlendirmeden etkilenmez, dolayısıyla SPF fail verse bile DMARC DKIM üzerinden geçer. Yani yönlendirme sorununun pratik cevabı "~all kullan" değil, "DKIM'i her gönderim yolunda devreye al"dır.

Mail göndermeyen alan adım için SPF gerekli mi#

Kesinlikle gerekli, hatta en katı hâliyle. Hiç mail göndermeyen bir alan adı, sahtecilik için en cazip hedeftir çünkü kimse orada bir anormallik beklemez. Böyle bir alan adına v=spf1 -all kaydı, p=reject DMARC politikası ve boş bir DKIM joker kaydı vererek alan adınız adına mail gönderilmesini fiilen imkânsız hale getirebilirsiniz.

Kapanış#

SPF'in son karakteri küçük bir ayrıntı gibi görünse de arkasında bir envanter disiplini vardır. Aklınızda kalması gereken dört şey: ~all bir geçiş durumudur, -all ise bir taahhüt — ve taahhüde ancak tüm gönderim yollarınızı bildiğinizde geçin; DMARC p=reject devredeyken ikisi arasında fark kalmaz, asıl korumayı DMARC sağlar; yönlendirme SPF'i kırar ve bunun tek pratik çözümü DKIM'dir; alan adınızda tek bir SPF kaydı olmalı ve 10 DNS sorgu limitini aşmamalıdır.

Kendi mail sunucunuzu kurup bu kayıtları yönetmek isterseniz Postfix, Dovecot ve DKIM imzalama hazır gelen SMTP sunucu paketleri kurulum aşamasını atlatır; daha genel bir altyapı için tam root erişimli VDS sunucularına bakabilirsiniz. DNS kayıtlarını tek panelden yönetmek isterseniz alan adı hizmetimiz, kayıtların doğru kurulmasını bize bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer.