SPF 10 DNS Sorgu Limiti (PermError) Nedir? SPF Kaydını Düzeltme ve Sadeleştirme Rehberi

SPF kaydınız doğru görünüyor ama mailleriniz yine de SPF’ten kalıyor ve spam’e düşüyor olabilir. Sık rastlanan sessiz sebep: SPF’in 10 DNS sorgu limitini aşmak. Microsoft 365, Google Workspace, bir pazarlama aracı ve bir CRM’i aynı SPF kaydına include: ile eklediğinizde bu sınır kolayca aşılır ve SPF PermError döndürür — yani birçok alıcı için SPF’iniz geçersiz sayılır. Bu rehberde limitin ne olduğunu, PermError’ın sonuçlarını ve SPF kaydınızı nasıl sadeleştireceğinizi anlatıyoruz.

SPF 10 DNS Sorgu Limiti Nedir?

SPF standardı (RFC 7208), bir SPF kaydı değerlendirilirken yapılabilecek DNS sorgusu sayısını en fazla 10 ile sınırlar. Bu, sonsuz döngü ve kötüye kullanımı önlemek içindir. Şu mekanizmalar bu limite dahildir:

• include:, a, mx, ptr, exists ve redirect — her biri en az bir DNS sorgusu yapar.
• İç içe (nested) include’lar da sayılır: Bir include içinde başka include’lar varsa hepsi toplama eklenir. Örneğin tek bir sağlayıcı include’ı arka planda 3-4 sorgu tüketebilir.

Buna karşılık ip4:, ip6: ve all mekanizmaları DNS sorgusu yapmaz, dolayısıyla limite dahil değildir.

PermError Ne Anlama Gelir?

10 sorgu limiti aşıldığında SPF değerlendirmesi permerror (kalıcı hata) sonucu üretir. Birçok alıcı sunucu bunu “SPF geçersiz/başarısız” gibi ele alır. Sonuçları ağırdır:

• Meşru, kendi sunucunuzdan giden mailler bile SPF’ten kalabilir.
• SPF başarısız olunca DMARC hizalaması (alignment) de bozulur; DMARC politikanız reject/quarantine ise mailler reddedilir veya spam’e düşer.
• Gönderici itibarınız ve teslim oranınız zamanla düşer.

Limiti Neler Tüketir?

En büyük tüketici, çok sayıda include: zinciridir. Tek başına birkaç popüler sağlayıcı bile limiti doldurabilir; çünkü her biri arka planda birden fazla sorgu yapar (örneğin bir e-posta güvenlik/pazarlama sağlayıcısı 3-5 sorguya kadar çıkabilir). Buna bir de a, mx ve (asla kullanılmaması gereken) ptr mekanizmalarını eklerseniz sınır hızla aşılır.

Nasıl Kontrol Ederim?

SPF kaydınızın kaç DNS sorgusu tükettiğini ve geçerli olup olmadığını SPF sorgulama aracımızla kontrol edebilir; SPF, DKIM, DMARC ve gönderici itibarını birlikte görmek için ise e-posta sağlık kontrolünü kullanabilirsiniz.

Çözüm Yolları

1. Gereksiz include’ları kaldırın. Artık kullanmadığınız servislerin (eski pazarlama araçları, denenip bırakılmış CRM’ler) include’larını silin. En hızlı kazanç budur.
2. ptr mekanizmasını asla kullanmayın. Hem yavaş hem güvenilmezdir; birçok alıcı zaten yok sayar.
3. Gereksiz mx mekanizmasını kaldırın. MX kaydınız yalnızca posta alan (gönderici olmayan) bir sunucuysa SPF’te mx tutmak boşuna sorgu harcar. Gönderici IP’lerinizi doğrudan ip4 ile yazın.
4. Alt alan adıyla ayrıştırın. Farklı servisleri farklı alt alan adlarından gönderin (ör. pazarlama mail.alanadi.com, işlemsel tx.alanadi.com); her alt alanın kendi, daha yalın SPF’i olur.
5. SPF flattening (düzleştirme) uygulayın — dikkatle. Include’ların çözümlediği IP’leri statik ip4 olarak yazarak sorgu sayısını sıfıra indirebilirsiniz. Ancak sağlayıcı IP’leri değişebileceği için bu yöntem düzenli bakım gerektirir; otomatik güncellenmiyorsa zamanla mailleriniz kalmaya başlar.

Gönderim altyapınızı sadeleştirmek ve kendi IP’lerinizi netleştirmek için yönetilen bir Exchange mail sunucusu ya da cPanel hosting çözümleri işinizi kolaylaştırır.

SPF’i Doğru Tutmanın İlkeleri

• Tek bir SPF kaydı bulundurun. Aynı alan adında birden fazla v=spf1 kaydı SPF’i geçersiz kılar.
• Kaydı -all (veya ~all) ile bitirin. Yetkisiz göndericilere karşı koruma sağlar (bkz. SPF/DKIM/DMARC rehberi).
• Düzenli denetleyin. Servis ekleyip çıkardıkça SPF’inizi tekrar kontrol edin; 10 sorgu sınırına yaklaşıyorsanız sadeleştirin.

Sık Sorulan Sorular

ip4 eklemek limiti artırır mı?

Hayır — tam tersi işinize yarar. ip4 ve ip6 mekanizmaları DNS sorgusu yapmadığı için 10’luk limite dahil değildir. Bu yüzden mümkün olduğunda include: yerine doğrudan gönderici IP’lerinizi ip4 ile yazmak limiti rahatlatır.

SPF flattening güvenli mi?

Sorgu sayısını düşürür ama risklidir: sağlayıcı (ör. M365) IP bloklarını değiştirdiğinde statik listeniz güncel kalmazsa meşru mailleriniz SPF’ten kalar. Flattening kullanacaksanız, IP’leri otomatik güncelleyen bir çözümle veya düzenli manuel bakımla yapın.

Limit içindeysem yine de bir sorun olabilir mi?

Evet. Birden fazla SPF kaydı, +all gibi tehlikeli mekanizmalar veya eksik hizalama da SPF/DMARC sorunlarına yol açar. Bu yüzden yalnızca sorgu sayısına değil, kaydın bütününe bakın; en pratik yol düzenli olarak e-posta sağlık kontrolü çalıştırmaktır.

Özet: SPF’in 10 DNS sorgu limitini aşmak, PermError’a ve sessiz teslimat kayıplarına yol açar. Gereksiz include ve mekanizmaları temizleyin, ptr‘den kaçının, mümkün olduğunda ip4 kullanın ve alt alan adlarıyla ayrıştırın. Değişiklik sonrası kaydınızı SPF aracıyla doğrulayın ve genel teslim edilebilirliğinizi düzenli izleyin.