Defaults.Exposed › Düzeltmeler › Guides

SPF PermError: E-Postanızı Bozmadan "Çok Fazla DNS Sorgusu" Nasıl Düzeltilir (2026)

Yayımlanma 2026-07-08

Veriler: 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan adı üzerinde toplam sayım verileri. Bkz. nasıl derecelendiriyoruz.

Defaults.Exposed”ın 261,086,232 alan adı sayımına göre en az 797,263 alan adı SPF”nin 10 DNS sorgusu sınırını aşıyor — 139 milyon SPF yayıncısından. On sorguyu geçince alıcı durur ve PermError döndürür: SPF”niz geçersizdir ve DMARC bir PermError”u başarısızlık olarak sayar.

Düzeltmenin kesin bir sırası vardır ve çoğu kılavuz bunu tersine almaktadır. Gerçek, çözümlenmiş sorgularınızı sayın; ölü ve kullanılmayan include”ları silin — bu tek başına çoğu kaydı düzeltir; toplu göndericileri kendi SPF bütçesiyle alt alan adlarına taşıyın; düzleştirmeyi yalnızca son çare olarak ve yalnızca otomatik yeniden düzleştirmeyle yapın, çünkü statik düzleştirme çürür ve sessizce iletimi bozar.

”SPF PermError: çok fazla DNS sorgusu” ne anlama gelir?

RFC 7208 §4.6.4, her SPF denetimini 10 DNS sorgusuyla sınırlar. On sorguyu geçince alıcı durur ve PermError döndürür — kaydın tamamı bozuk kabul edilir, yalnızca bütçeyi aşan kısım değil. Aynı bölüm daha az bilinen ikinci bir tavan ekler: en fazla 2 “boş sorgu” (cevap döndürmeyen veya NXDOMAIN veren sorgular), dolayısıyla iptal edilen hizmetlere ait birkaç ölü include: girişi tek başına SPF”nizi geçersiz kılabilir.

Sonuç “SPF yok”tan daha kötüdür: DMARC bir PermError”u SPF hatası olarak sayar, bu nedenle kendi SPF”sini bozan bir alan adı her DMARC değerlendirmesinin SPF ayağında kimlik doğrulaması yapamamış sayılır. DKIM kurulmamışsa veya iletimde bozulursa, o posta artık doğrudan DMARC”ta başarısız olur.

Bir sayım verisi bu başarısızlık modunun ne kadar acımasız olduğunu gösteriyor: 112,215 alan adı, sorgu taşması nedeniyle geçersiz olan katı -all kaydı yayınlıyor — -all yayımlayan 54,655,923 alan adından. Sahipleri zor kısmı yaptı — katı sonlandırmayı seçtiler — ve bir include fazlası kaydın tamamını kapattı. Katı görünüyorlar; bozuklar. Tam veri için bkz. SPF PermError raporu.

Hiçbir şeyi değiştirmediğimde SPF neden bozuldu?

Çünkü bütçe büyük ölçüde başkalarının kayıtları tarafından harcanıyor. Her include: yinelemeli olarak değerlendirilir ve içindeki her sorgu mekanizması on sınırınıza sayılır. DNS panelinizde bir satır çözümlendiğinde dört veya beş sorguya mal olabilir. Bir sağlayıcı bir include daha iç içe koyar ve SPF”niz bölgenizdeki tek bir değişiklik olmaksızın çöker.

Büyük platformlar sorun değil: Google ve Microsoft her ikisi de kendi SPF”lerini düzleştirdi — _spf.google.com ve spf.protection.outlook.com düz IP listelerine genişler, sıfır dahili sorgu maliyetiyle (Temmuz 2026 canlı DNS”e karşı doğrulandı). Gerçek dünyadaki patlamalar, birkaç katman derinliğe iç içe geçmiş hosting panel include zincirlerinden ve dürüst SaaS yığınlamasından kaynaklanıyor — posta kutusu artı bülten artı CRM artı yardım masası, her biri “sadece bir include”. Hiç kimse on birinci sorguyu kasıtlı olarak eklemez; makul kararların toplamı olarak gelir. Bu nedenle uçurum kenarı bu kadar kalabalıktır: 2,119,539 alan adı tam olarak 9-10 çözümlenmiş sorguda oturuyor — tüm SPF yayıncılarının yaklaşık 66‘inde biri, bugün iyi, biri daha fazla include yapıştırıldığında geçersiz. 99. yüzdelik SPF kaydı zaten 9 sorguya çözümleniyor. Yığınınız SaaS ağırlıklıysa, SaaS araçları için SPF başarısız oluyor kılavuzu satıcı bazında sürümü ele alıyor.

SPF kaydının hangi kısımları DNS sorgusu olarak sayılır?

Görünür satırları değil, çözümlenmiş toplamı sayın. Dört include dört veya on dört sorgu olabilir.

E-postayı bozmadan “çok fazla DNS sorgusu” nasıl düzeltilir?

1. DNS”e dokunmadan önce ücretsiz taramayı çalıştırın. Tam include zincirinizi çözümler ve gerçek sorgu sayınızı gösterir, böylece panelinizdeki göründüğü haliyle değil, gerçek sorunu düzeltirsiniz. (Hiç SPF”niz olmadığını söylüyorsa bu farklı bir başarısızlıktır — bkz. “SPF kaydı bulunamadı”.)
2. Önce ölü ve kullanılmayan include”ları silin. 2023”te bıraktığınız araç, bir geçişten sağ kurtulan eski hostun include”u, yinelemeler, ptr mekanizmaları. Ölü include”lar çift zehirlidir: sorgu bütçesi yakarlar ve genellikle boş sorguların kaynağıdır. Çoğu aşırı bütçeli kayıt yalnızca bu adımda 10”un altına iner. Kaydınız hâlâ önceki bir sağlayıcının mekanizmalarını taşıyorsa geçiş temizleme kılavuzunu izleyin.
3. Her kalan include”ın bir işe yarayıp yaramadığını kontrol edin. Alıcılar SPF”yi Return-Path (RFC5321.MailFrom) alanına karşı değerlendirir, From başlığına değil — ve pek çok SaaS aracı kendi geri dönüş alanını Return-Path”e koyar, bu nedenle kaydınızdaki include”ları hiçbir şey yapmaz, yalnızca bütçe harcar. Yalnızca alanınızı Return-Path olarak kullanan hizmetler için include tutun; diğerleri için bunun yerine satıcının özel alan adı DKIM”ini etkinleştirin.
4. Toplu göndericileri alt alan adlarına taşıyın. news.yourdomain.com”dan bültenler, mail.yourdomain.com”dan işlemsel postalar. Her alt alan adı kendi SPF kaydıyla taze 10 sorguluk bütçe alır ve bir akıştaki sorun diğerlerine sızmayı durdurur.
5. Yalnızca ardından düzleştirmeyi düşünün — ve yalnızca otomatik düzleştirme. Aşağıya bakın.
6. Doğrulamak için yeniden tarayın — 10”un rahatça altında olduğunuzdan emin olun; tam 10”u hedeflemeyin, yoksa uçurum kenarındaki 2.1 milyon alan adıyla aynı duruma düştünüz. Ardından SPF”yi düzeltin sayfasında taramanın işaretlediği diğer sorunları çözün.

SPF kaydımı düzleştirmeli miyim?

Düzleştirme, include”ları maliyetsiz ip4:/ip6: bloklarıyla değiştirir. İşe yarar — ve elle yapıldığında, gecikmeli teslim kesintisidir.

Sağlayıcılar gönderme IP”lerini rutin olarak döndürür ve bunu kimseye bildirmez. Statik bir IP listesi yapıştırdığınız gün doğrudur ve aylar içinde sessizce yanlış olur — başarısızlık başkalarının postanızı almaması şeklinde göründüğünden, geç öğrenirsiniz. Budama ve alt alan adları sınırın altında kalmanızı sağlıyorsa, orada durun; üçüncü taraf IP bloklarını kalıcı düzeltme olarak kaydınıza asla elle kopyalamayın.

Sık sorulan sorular

SPF PermError teslimi tamamen durdurur mu? Hemen değil — işte bu onu tehlikeli yapan şey. DMARC bir PermError”u SPF hatası sayar, dolayısıyla teslim tamamen DKIM”e dayanır; DKIM eksikse veya iletimde bozulursa, DMARC”ta başarısız olursunuz. Sayımımızdaki 139 milyon SPF yayıncısından (2026-06-29 itibarıyla) en az 797,263 tanesi bu durumdadır — çoğu farkında değildir.

Kaydımda yalnızca dört include var — nasıl 10”u aşabilir? Include”lar yinelemeli olarak sayılır: her include içindeki (ve onun include”larının içindeki) her şey bütçenize yüklenir, bu nedenle dört görünür satır on dört sorguya çözümlenebilir. Gözle değil, çözümleyici araçla sayın — zincirleri çözümlemek, PermError raporumuzun yüzey sayımlara göre yaklaşık 100× daha fazla bozuk alan adı bulmasının nedenidir.

Kaydımı -all ile bitiriyorum — kesinlikle korunuyorum, değil mi? Yalnızca kayıt değerlendirilirse. Sayımımız (2026-06-29 itibarıyla), katı -all kaydı sorgu taşması nedeniyle geçersiz olan 112,215 alan adı buldu. PermError kaydındaki katı niteleyici hiçbir şeyi korumaz.

Sınır her include başına mı yoksa tüm kayıt için mi 10 sorgudur? Tüm değerlendirme için: RFC 7208 §4.6.4 tam denetimi 10, artı en fazla 2 boş sorguyla sınırlar. Her alt alan adının kendi kaydı ve bütçesi vardır — bu nedenle adım 4 işe yarar.

ip4 ve ip6 girişleri sınıra dahil mi? Hayır — IP mekanizmalarının maliyeti sıfırdır, bu da düzleştirmenin sayıyı neden azalttığıdır.

Sahibine raporu gönderin

Bunu bir müşteri veya işvereniniz için düzeltiyorsanız, işi kanıtla kapatın. Değişikliklerinizden sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu işletme sahibine gönderin: sade bir dille, tarihli, PermError gitti. Bu, siber sigorta yenilemesinde ve bir sonraki müşteri güvenlik anketinde ihtiyaç duyacakları eserdir — “bazı DNS kayıtlarını değiştirdim” ile belgelenmiş bir öncesi-sonrası arasındaki farktır.

Alan adınızı ücretsiz kontrol edin

Gerçek, çözümlenmiş sorgu sayınızı — ve SPF, DKIM ve DMARC ile ilgili diğer her şeyi — gizli ve yalnızca sahibine görün.

Alan adınızı kontrol edin → · SPF”yi düzeltin → · SaaS araçları için SPF başarısız oluyor → · GoDaddy”de SPF kurulumu → · Nasıl derecelendiriyoruz → · Yalnızca toplu veriler. Veriler AB”de depolanır ve işlenir.