SPF PermError Raporu: Yüzeysel Sayımların Gösterdiğinden 100× Daha Fazla Alan Adı 10 Sorgu Sınırını Aşıyor (2026)

Yayımlanma 2026-07-03

2026-06-29 itibarıyla rakamlar · metodoloji v7, ayrıca 2026-07-03 tarihinde çalıştırılan bir zincir-fiyatlama geçişi. 261 milyon derecelendirilmiş alan adından oluşan sayımdan yola çıkarak, 100 veya daha fazla kez referans verilen her SPF include: hedefini çözdük — tüm include referanslarının %95.2‘ini kapsayan 10,842 hedef — ve her alan adının korunan zincirini o haritaya karşı fiyatlandırdık. Çözülemeyen kuyruk hedefleri sıfır olarak sayıldı ve zincir içerikleri çözümleme gününü yansıtıyor; dolayısıyla ana başlık, muhafazakâr, tabana meyilli bir yaklaşıklamadır: “en az” diyoruz. Yalnızca toplu veri; asla tek bir işletmenin kaydı değil. Bkz. nasıl derecelendiriyoruz.

Kaç alan adı SPF 10 sorgu sınırını aşıyor?

En az 797,263 — çünkü SPF’in standardın içine yerleştirilmiş bir kendini imha mekanizması var ve tetikleyici, sahiplerin göremeyeceği bir yerde gizli. RFC 7208 §4.6.4, bir SPF kontrolünü 10 DNS sorgusuyla sınırlar; onun ötesinde alıcı durur ve PermError döndürür; PermError döndüren bir kayıt hiçbir şeyi korumaz. Yalnızca kaydın kendisinde görünen sorguları sayın — çoğu aracın yaptığı ve bu rapora kadar bizim kendi sayımımızın da yaptığı gibi — ve yaklaşık 8.000 ihlalci bulursunuz (tam olarak 7,958). O kayıtların gerçekte çektiği include: zincirlerini fiyatlandırın ve sayı 797,263‘e ulaşır: kabaca 100 kat daha büyük.

Sahipler neden bunun geldiğini göremiyor?

Çünkü bütçe başkalarının kayıtları tarafından harcanıyor. include:onetool.example.com, DNS panelinizde tek bir satır olarak okunur — ancak alıcının o kaydı da getirmesi ve onun içerdiği her sorgu mekanizmasını özyinelemeli olarak sayması gerekir. Üç include içeren bir kayıt on bir sorguya mal olabilir. Sınırı aştığınız gün kendi bölgenizde hiçbir şey değişmedi; bir sağlayıcı bir include daha yuvaladı ve SPF’iniz uyarı vermeden öldü.

Daha da kötüsü, DMARC bir PermError’ı SPF ayağında başarısızlık olarak değerlendirir — dolayısıyla SPF’ini bu şekilde bozan bir alan adı, artık kendi kimlik doğrulamasının yarısında başarısız oluyor.

Zincir-fiyatlaması ne buldu

Bulgu	Alan adları
10 sorgu sınırının üzerinde, zincirler fiyatlandırıldı	797,263
Yalnızca görünür mekanizmalar sayılarak sınırın üzerinde	7,958
Sınırın üzerinde ve katı `-all` ile bitiyorken	112,215
Tam olarak 9–10 sorguda — uçurumun kenarı	2,119,539

O tabloda iki hikâye var — üçüncüsü, uçurumun kenarı, aşağıda kendi bölümünü alıyor:

Yüzeysel sayımlar arızanın ~%99‘ini kaçırıyor. Görünür-mekanizma sayımı 7,958 buluyor; zincirlerin fiyatlandırılması 797,263 buluyor. Hasarın neredeyse tamamı, include’ların içerdiklerinden miras alınıyor.
Bozuk kayıtların 112,215‘i -all ile bitiyor. Sahipleri her şeyi doğru yaptı — duvara tırmandılar, katı sonlandırmayı seçtiler — ve fazladan bir include her şeyi geçersiz kıldı. Katı görünen ama bozuk olmak, e-posta güvenliğindeki en acımasız başarısızlık türüdür.

2.1 milyon alan adı uçurumdan bir araç uzakta

Şu anda sorunsuz olan okuyucuları endişelendirmesi gereken sayı: 2,119,539 alan adı tam olarak 9 veya 10 sorguya çözümleniyor — bugün sınırın altında, birisi bir platform daha bağladığı gün ölü. Bu, tüm SPF yayıncılarının kabaca 66‘te 1’i ve dağılımın şekliyle örtüşüyor: 99. yüzdelik dilimdeki SPF kaydı zaten 9 sorguda oturuyor. Bir pazarlama aracına daha kaydolun, onun “sadece bu include’ı ekleyin” satırını yapıştırın ve kahvaltıda sınırın altında olan bir kayıt öğle yemeğine kadar geçersiz olur.

Kimin suçu? Giderek artan biçimde, yığının

En büyük sağlayıcılar SPF’lerini sessizce düzleştirdi — Google’ın _spf.google.com’u ve Microsoft’un spf.protection.outlook.com’u artık sıfır dahili sorguya mal olan düz IP listelerine genişliyor (bu analiz sırasında her ikisini de canlı DNS’e karşı doğruladık). Patlamalar başka yerlerden geliyor: üç kat derine yuvalanan barındırma-paneli zincirleri, include’ı tek başına 7–10 sorguya mal olan bölgesel sağlayıcılar ve SaaS’ın dürüst birikimi — posta kutusu artı bülten artı CRM artı yardım masası, her biri “sadece bir include”. Neredeyse hiç kimse on birinci sorguyu bilerek eklemiyor. O, makul kararların toplamı olarak gelir.

Kendinizinkini nasıl kontrol edip düzeltirsiniz — ücretsiz

Gerçek toplamınızı sayın — ücretsiz kontrolümüz zincirinizi çözer ya da herhangi bir SPF sorgu sayacı kullanın.
Ölü ağırlığı budayın: kullanmayı bıraktığınız araçlar, mükerrer include’lar ve kullanımdan kaldırılmış ptr mekanizması.
Yalnızca kontrol ettiğinizi düzleştirin. Derin bir include’ı onun IP bloklarıyla değiştirmek kendi altyapınız için işe yarar; üçüncü taraf IP’ler haber verilmeden değişir.
Toplu göndericilere bir alt alan adı verin. news.yourdomain.com’dan gönderilen bültenler kendi kaydını ve kendi 10 sorgu bütçesini alır.

Sıkça sorulan sorular

SPF 10 DNS sorgu sınırı nedir? RFC 7208 §4.6.4, tek bir SPF kaydını değerlendirmek için en fazla 10 DNS sorgusuna izin verir — her include: içindeki sorguları özyinelemeli olarak sayarak. Bunu aşmak PermError döndürür: kayıt geçersiz kabul edilir ve hiçbir koruma sağlamaz.

SPF PermError ne anlama gelir? Kalıcı bir değerlendirme hatası — alıcı kaydınızı işleyemedi (çok fazla sorgu, birden fazla kayıt veya bozuk sözdizimi) ve alan adınızı kullanılabilir bir SPF’i yokmuş gibi değerlendirir. DMARC bunu SPF ayağında başarısızlık olarak sayar.

Kaç alan adı SPF sorgu sınırını aşıyor? Zincir-fiyatlama geçişimize göre 139 milyon SPF yayıncısından en az 797,263‘i — zincirler çözülmeden görünen 7,958‘in yaklaşık 100× katı. Ek olarak 2,119,539 alan adı 9–10 sorguda, sınırdan bir include uzakta oturuyor.

Bir PermError e-postamın teslim edilmesini durdurur mu? Genellikle hayır — alıcılar SPF olmadan devam eder ve postanız DKIM ile itibar üzerinden yol alır. Çalışmayı durduran şey korumadır: sahtecilere artık ret uygulanmaz ve postanızın her DMARC kontrolü SPF ayağını kaybeder. Pahalıya patlayana kadar görünmezdir.

SPF sorgu sayımı nasıl azaltırım? Kullanılmayan include’ları ve ptr’yi kaldırın, kendi altyapınızı ip4:/ip6:’ya düzleştirin, toplu göndericileri alt alan adlarına taşıyın ve her yeni araçtan sonra yeniden sayın. Düzeltme kılavuzu bunu adım adım anlatıyor.

Gerçek sayınızı öğrenin

Görebildiğiniz mekanizmalar sizin sorgu sayınız değildir — çözülen sayı, alıcıların hesapladığı sayıdır ve bu 30 saniyelik bir kontroldür.

Alan adınızı kontrol edin → · SPF’i düzeltin → · SPF olgunluk modeli → · İki SPF kaydı = hiçbiri → · ptr tuzağı → · Yalnızca toplu veri. Veriler AB’de saklanır ve işlenir.