SPF Softfail Hardfail Farkı Nedir? ~all mı -all mı?

SPF softfail hardfail farkı, SPF kaydının sonundaki all mekanizmasının önüne konan niteleyiciden doğar: -all (hardfail), listede olmayan sunucuların kesinlikle yetkisiz olduğunu; ~all (softfail), muhtemelen yetkisiz olduğunu; ?all (neutral) ise hiçbir iddiada bulunulmadığını bildirir. Alıcı sunucular fail sonucunda iletiyi reddedebilir, softfail sonucunda ise genellikle kabul edip şüpheli olarak puanlar. DMARC açısından ise ikisi de SPF'nin geçmediği anlamına gelir.

SPF niteleyicileri ve sonuçları

SPF kaydı soldan sağa değerlendirilir ve hiçbir mekanizma eşleşmezse sondaki all devreye girer. all önündeki niteleyici, listede olmayan IP adresleri için hangi sonucun üretileceğini belirler. RFC 7208 bu sonuçları şöyle tanımlar:

Bunlara ek olarak kayıt hiç yoksa none, geçici bir DNS sorunu varsa temperror, kayıt yorumlanamıyorsa permerror sonucu üretilir. Niteleyiciler teorik olarak her mekanizmanın önüne konabilir, ancak pratikte neredeyse yalnızca all ile kullanılır.

Alıcı sunucular softfail ve hardfail sonucunu nasıl yorumlar?

RFC 7208 iki sonuç için farklı davranışlar önerir:

• Fail: Alıcı iletiyi işaretleyebilir veya SMTP aşamasında doğrudan reddedebilir. Ret durumunda 550 yanıt kodunun kullanılması önerilir; RFC 7372 bu amaçla "SPF validation failed" anlamındaki 5.7.23 gelişmiş durum kodunu tanımlar.
• Softfail: Alıcı iletiyi yalnızca bu sonuca dayanarak reddetmemelidir; ancak iletiyi normalden daha sıkı incelemeye alabilir.

Pratikte davranış alıcının yerel politikasına bağlıdır. Bazı sunucular fail sonucunda iletiyi hemen reddeder, bazıları yalnızca spam puanını yükseltir. SpamAssassin tabanlı filtrelerde SPF_FAIL ve SPF_SOFTFAIL ayrı kurallardır ve farklı ağırlıkta puan ekler. Softfail alan iletiler çoğunlukla teslim edilir, ancak başka olumsuz sinyallerle birleştiğinde spam klasörüne düşebilir.

Neutral ve +all neden önerilmez?

?all eşleşmeyen sunucular için nötr sonuç üretir ve RFC 7208'e göre alıcılar neutral sonucu kayıt hiç yokmuş gibi değerlendirmelidir. Yani alan adınızı taklit edenlere karşı pratik bir koruma sağlamaz; yalnızca kısa süreli testlerde anlamlıdır. +all ise tüm internete sizin adınıza gönderim izni verir ve kaydın varlık nedenini ortadan kaldırır. Hiçbir senaryoda kullanılmamalıdır.

DMARC ile softfail ve hardfail nasıl etkileşir?

DMARC için SPF sonucu ikiye ayrılır: hizalı pass ve geri kalan her şey. Yani DMARC değerlendirmesinde fail ile softfail arasında fark yoktur; ikisi de SPF'nin geçmediği anlamına gelir. Bu durumda DMARC'ın sonucu, DKIM imzasının hizalı geçip geçmediğine bağlıdır.

Burada -all kullanımının gözden kaçan bir riski vardır. DMARC'ın güncel tanımı olan RFC 9989 bölüm 7.1'de (eski RFC 7489'da bölüm 10.1) belirtildiği gibi, bazı alıcılar SPF denetimini DMARC'tan önce yapar ve fail sonucunda iletiyi DMARC değerlendirmesine fırsat vermeden reddeder. Yönlendirilen bir iletide SPF bozulur ama DKIM imzası çoğu zaman geçerli kalır; -all ile bu ileti, aslında DMARC'tan geçebilecekken erken aşamada reddedilebilir. Bu şekilde reddedilen iletiler toplu DMARC raporlarında da görünmez. ~all bu riski azaltır, çünkü softfail tek başına ret gerekçesi sayılmaz.

Yönlendirme kaynaklı SPF hatalarını azaltmanın yolu yalnızca niteleyici seçimi değildir. İletiyi ileten sunucu, zarf adresini kendi alan adıyla yeniden yazan SRS (Sender Rewriting Scheme) yöntemini kullandığında SPF denetimi yönlendiren sunucunun alan adı üzerinden geçer. RFC 8617 ile tanımlanan ARC ise aracı sunucuların, iletiyi aldıkları andaki doğrulama sonuçlarını imzalı olarak sonraki alıcıya aktarmasını sağlar. Sizin tarafınızda yapılabilecek en etkili adım, tüm iletileri DKIM ile imzalamaktır; imza, yönlendirmeden genellikle zarar görmeden çıkar.

Hangisini ne zaman kullanmalı?

İki niteleyici de meşru bir tercihtir; büyük sağlayıcılar bile farklı yaklaşır: Microsoft 365 belgeleri -all, Google Workspace belgeleri ise ~all kullanılmasını önerir. Belirleyici olan, gönderim kaynaklarınızı ne kadar iyi tanıdığınız ve DMARC'ı ne ölçüde uyguladığınızdır.

Softfail'den hardfail'e geçiş adımları

1. Alan adınızla gönderim yapan tüm sistemleri listeleyin: posta sunucusu, bulut posta hizmeti, CRM, fatura, destek ve bülten araçları.
2. SPF kaydını ~all ile yayımlayın ve rua adresi içeren bir DMARC kaydı ekleyin.
3. En az iki ila dört hafta boyunca DMARC raporlarını inceleyip SPF'den geçemeyen meşru kaynakları belirleyin.
4. Eksik kaynakları kayda ekleyin ve DNS sorgusu gerektiren terimlerin toplamının 10'u aşmadığını doğrulayın.
5. Geçişten önce TXT kaydının TTL değerini düşürün, ardından ~all ifadesini -all ile değiştirin.
6. Sonraki günlerde geri dönen iletileri ve DMARC raporlarını izleyin; sorun çıkarsa hızla eski kayda dönün.

Permerror ve temperror nedir?

Bu iki sonuç, SPF kaydının hiç değerlendirilemediğini gösterir ve niteleyici seçimi ne olursa olsun SPF'yi işlevsiz bırakabilir.

Permerror (kalıcı hata), kaydın yorumlanamadığı anlamına gelir. Başlıca nedenleri şunlardır:

• Aynı alan adında birden fazla v=spf1 kaydı bulunması.
• DNS sorgusu gerektiren terimlerin 10 sınırını aşması.
• Yazım hataları ya da SPF kaydı olmayan bir alan adının include ile eklenmesi.

RFC 7208, permerror nedeniyle ret yapılırsa 550 yanıt kodunun kullanılmasını önerir. DMARC açısından permerror, SPF'nin geçmediği anlamına gelir; bu da kaydınızı fiilen devre dışı bırakır.

Temperror (geçici hata) genellikle DNS zaman aşımı gibi geçici sorunlardan kaynaklanır. Alıcı iletiyi 451 gibi geçici bir hata koduyla erteleyebilir ve gönderen sunucu daha sonra yeniden dener. Sürekli temperror görüyorsanız DNS sunucularınızın erişilebilirliğini kontrol edin. Ret ve erteleme kodlarının ayrıntıları için e-posta bounce hata kodları yazımıza bakabilirsiniz.

Sık yapılan hatalar

• -all kullanırken bir gönderim kaynağını kayda eklemeyi unutmak ve meşru iletilerin reddedilmesine yol açmak.
• ?all ile koruma sağlandığını sanmak.
• all mekanizmasından sonra terim eklemek; all her IP adresiyle eşleştiği için sonrasındaki terimler hiç değerlendirilmez.
• Softfail sonucunu zararsız sayıp SPF'den geçemeyen kaynakları düzeltmemek.

İpucu: Bir iletinin aldığı SPF sonucunu görmek için alıcı taraftaki Received-SPF veya Authentication-Results başlığına bakın; sonuç, değerlendirilen IP adresi ve alan adıyla birlikte yazılır.

MXZilla'in gelen posta filtresi, gelen iletilerde SPF sonucunu DKIM ve DMARC sonuçlarıyla birlikte değerlendirir; paneldeki alan adı DNS kontrolleri de kendi SPF kaydınızdaki sorunları görünür kılar.

Alan adınızın SPF kaydını ve diğer kimlik doğrulama kayıtlarını ücretsiz güvenlik kontrolü ile hemen görebilir, gelen ve giden posta korumasına yönelik paketlerimizi inceleyebilirsiniz.

Sık sorulan sorular

Softfail alan e-postalar spam klasörüne düşer mi?

Her zaman düşmez. Softfail tek başına genellikle ret veya spam kararı için yeterli sayılmaz, ancak spam puanını artırır. İletide başka olumsuz sinyaller de varsa spam klasörüne düşme olasılığı belirgin biçimde yükselir.

Hardfail kullanmak e-posta teslimatını riske atar mı?

Tüm gönderim kaynaklarınız kayıtta tanımlıysa risk düşüktür. Unutulmuş bir kaynak veya yönlendirilen iletiler söz konusu olduğunda ise bazı alıcılar iletiyi doğrudan reddedebilir. Bu yüzden geçişten önce DMARC raporlarıyla kaynaklarınızı doğrulamanız önerilir.

DMARC varken softfail mi hardfail mi kullanmalıyım?

DMARC yaptırımlıysa ve tüm kaynaklarınız DKIM ile hizalı imzalanıyorsa iki seçenek de kabul edilebilir. Yönlendirilen iletilerin erken aşamada reddedilme riskini azaltmak isteyenler ~all, DMARC uygulamayan alıcılara güçlü sinyal vermek isteyenler ise -all tercih eder. Önemli olan, seçiminizin sonuçlarını raporlarla izlemektir.

SPF permerror neden olur?

En sık nedenler aynı alan adında birden fazla SPF kaydı bulunması, DNS sorgusu sınırının aşılması ve yazım hatalarıdır. Permerror durumunda SPF kaydınız fiilen çalışmaz ve DMARC açısından SPF geçmemiş sayılır. Kaydınızı düzenli olarak bir denetim aracıyla kontrol etmek bu sorunu erken yakalamanızı sağlar.

Neutral sonuç ne anlama gelir?

Neutral, alan adı sahibinin ilgili IP adresi hakkında bir iddiada bulunmadığı anlamına gelir ve ?all ile üretilir. RFC 7208'e göre alıcılar neutral sonucu kayıt hiç yokmuş gibi değerlendirmelidir. Bu nedenle ?all pratikte koruma sağlamaz.