Defaults.Exposed

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?

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?

  1. Posta gönderiyorsanız ve iletme önemliyse (haber bültenleri, posta listeleri, takma adlar): arkasında DMARC p=reject olan ~all — yukarıda önerilen eşleşme.
  2. Sıkı bir şekilde kontrol edilen bir kurulumdan posta gönderiyorsanız: -all iş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ü.
  3. Alan adı hiç göndermiyorsa: bugün -all artı 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.