Defaults.Exposed › Raporlar
SPF ~all ve -all: Softfail mı Hardfail mi — 139 Milyon Kayıt Neyi Seçti (2026)
Yayımlanma 2026-07-03
Rakamlar 2026-06-29 itibarıyladır · metodoloji v7. 261 milyon notlandırılmış alan adı genelinde toplu census verileri. Tüm rakamlar toplamdır — bireysel bir işletmenin kaydını asla yayımlamayız. Bkz. nasıl notlandırdığımız.
Her SPF kaydı bir “all” mekanizmasıyla biter — listenizde olmayan herhangi bir yerden gelen postaya ilişkin karar — ve internet ezici bir çoğunlukla yumuşak olanı seçti: SPF yayımlayan 139 milyon alan adının %55.8‘i ~all (softfail) ile biterken, %39.3‘i -all (hardfail) ile bitiyor. “Sahtekârlıkları reddet” ile “muhtemelen bir sahtekârlık — yine de teslim et” arasında tek bir karakter var. Hangisinin sizin için doğru olduğu, çoğu sahibinin asla yapılandırmadığı ikinci bir ayara bağlı.
~all ve -all bir alıcıya aslında ne söyler?
-all(hardfail): “Başka herhangi bir yerden gelen postayı reddet.” Kesin bir hayır.~all(softfail): “Başka bir yerden gelen posta muhtemelen meşru değil — kabul et, belki işaretle.” Bir omuz silkme.?all(neutral): “Görüşüm yok.” Yayımcıların %3.0‘i tarafından seçildi; yalnızca adı korumadır.+all: “Herkes benim adıma gönderebilir.” 36,014 alan adı tarafından yayımlandı ve hiç kayıt olmamasından daha kötü — paspas problemi kendi raporuna sahip.
Peki ~all yanlış mı? Yalnızca tek başınaysa — ve neredeyse her zaman öyle
Softfail’in savunulabilir modern bir gerekçesi var: Google’ın gönderen yönergeleri ve onlarla birlikte çoğu teslim edilebilirlik uygulaması, zorlayıcı bir DMARC politikası (p=reject) ile eşleştirilmiş ~all üzerinde birleşiyor. Bu eşleşme, DMARC değerlendiren her alıcıda — ki artık tüm büyük posta kutusu sağlayıcılarını içeriyor — -all kadar iyi koruma sağlar; hem de meşru iletilen postayı sert bir şekilde geri döndürmeden, ki bu klasik -all kurbanıdır. Bu yapılandırmada omuz silkmenin dişleri vardır: DMARC, SPF’nin vermeyi reddettiği kararı sağlar.
Ama asıl mesele bu eşleşme ve census’un kurulum kılavuzlarının yapamayacağı şekilde eklediği şey şu: internetteki 77,484,057 softfail kaydından yalnızca 7.1 milyonunun — yaklaşık her 11‘de 1’inin — arkasında zorlayıcı bir DMARC politikası var. Diğer 70.4 milyon alan adı için ~all tam olarak kulağa geldiği gibidir. Kayıtları sahtekârlığı tespit eder ve onu geçirir.
2024 zorunlulukları bunu düzeltmedi mi?
Hayır — ve bu ayrım çoğu haberin öne sürdüğünden daha önemli. Google ve Yahoo, Şubat 2024’te toplu gönderenlerden kimlik doğrulama istemeye başladı, Mayıs 2025’te de Microsoft izledi: geçen, hizalanmış SPF veya DKIM, artı en az p=none düzeyinde bir DMARC kaydı. Zorunluluklar zorlama istemekten geri durur — ~all, bir p=none kaydı ve hizalanmış DKIM’e sahip bir alan adı tamamen uyumludur ve tamamen taklit edilebilir kalır. Zorunluluklar korumayı değil, evrak işlerini normalleştirdi. O zorlanmayan orta zemin — uyumlu, yayımlanmış, taklit edilebilir — tam olarak bu census’un ölçtüğü boşluktur ve e-posta güvenliğindeki en büyük nüfustur.
Peki kaydınız ne ile bitmeli?
- Posta gönderiyorsanız ve iletme önemliyse (haber bültenleri, posta listeleri, takma adlar): arkasında DMARC
p=rejectolan~all— yukarıda önerilen eşleşme. - Sıkı bir şekilde kontrol edilen bir kurulumdan posta gönderiyorsanız:
-allişe yarar ve politikayı kaydın kendisinde belirtir. Önce göndericilerinizi eşleyin — eşlenmemiş bir kayıtta sıkı bir bitiş gerçek postayı bozar, ya da daha kötüsü. - Alan adı hiç göndermiyorsa: bugün
-allartıp=reject. Korunacak meşru bir şey yok, dolayısıyla bozulacak bir şey de yok.
Hangi bitişi seçerseniz seçin, census’un tek satırlık dersi geçerlidir: niteleyici, yalnızca onu zorlayan şey kadar önemlidir. Bu merdivende nerede durduğunuz ölçülebilir.
Sıkça sorulan sorular
SPF ~all mı yoksa -all mı daha iyi?
Evrensel olarak hiçbiri. Zorlayıcı bir DMARC politikasıyla birlikte ~all, Google’ın yönergelerinin önerdiği kalıptır — DMARC değerlendiren alıcılarda eşit koruma, iletilen postayı bozmadan. -all, sıkı bir şekilde kontrol edilen göndericilere uygundur. Tek başına ~all — her 11 softfail alan adından 1’i hariç hepsinin durumu — zayıf seçenektir.
SPF softfail ne anlama gelir?
~all, alıcılara listelenmemiş sunuculardan gelen postanın muhtemelen gayrimeşru olduğunu ama yine de kabul edilmesi gerektiğini söyler, genellikle şüpheyle. Ancak bir DMARC politikası başarısızlık üzerine harekete geçtiğinde gerçek bir korumaya dönüşür; bkz. DMARC olmadan SPF.
Hardfail -all iletilen e-postamı bozar mı?
Bozabilir: iletme, postanızı SPF’nizin listelemediği ileticinin sunucusundan yeniden gönderir ve bir hardfail, DKIM veya DMARC devreye girmeden önce reddi davet eder. Bu risk, ~all + p=reject eşleşmesinin var olma nedenidir.
Google ve Microsoft artık -all istiyor mu?
Hayır. Toplu gönderen zorunlulukları, hizalanmış, geçen kimlik doğrulama ve en az p=none düzeyinde bir DMARC kaydı ister — zorlama yok, belirli bir niteleyici yok. Google’ın uyumsuz toplu postayı reddetmesi yürürlükte; Microsoft başarısızlıkları çöp kutusuna atıyor ve doğrudan reddetmeye doğru ilerliyor. Uyum, koruma değildir.
Kaydınızın ne ile bittiğini — ve arkasında ne durduğunu — kontrol edin
İki sorgu, ücretsiz olarak, 30 saniyede ikisini de söyler. 70.4 milyon zorlanmayan omuz silkmeden biriyseniz, çözüm bir satın alma değil, bir DNS kaydıdır.
Alan adınızı kontrol edin → · SPF’yi düzeltin → · DMARC’ı düzeltin → · SPF olgunluk modeli → · +all haritası → · Yalnızca toplu veriler. Veriler AB’de depolanır ve işlenir.