SPF "PermError: Too Many DNS Lookups" Hatası Nasıl Çözülür?

SPF kaydınız geçerli olsa bile alıcı sunucular PermError: too many DNS lookups hatasıyla e-postalarınızı reddedebilir. Bu hata, RFC 7208'in belirlediği 10 DNS sorgu sınırını aşmanın kaçınılmaz sonucudur. Nedenini ve nasıl düzeltileceğini adım adım ele alıyoruz.

SPF ve DNS Sorgu Sınırı Nedir?

Sender Policy Framework (SPF), bir alan adı adına hangi IP adreslerinin e-posta gönderebileceğini tanımlayan bir e-posta kimlik doğrulama protokolüdür. RFC 7208 (Ocak 2014, IETF) bu protokolün teknik spesifikasyonunu belirler ve Bölüm 4.6.4'te açıkça şunu söyler: "SPF kaydını değerlendiren taraf, include, a, mx, ptr, exists mekanizmaları ve redirect değiştiricisi dahil olmak üzere toplam 10'dan fazla DNS sorgusu yapmamalıdır. Sınır aşılırsa sonuç PermError olmalıdır."

PermError, "kalıcı hata" anlamına gelir; geçici bir ağ sorunu değil, kayıt yapılandırmanızda kalıcı bir sorun olduğunu gösterir. Google Postmaster Tools ve Microsoft'un Exchange Online Posta Koruma (EOP) altyapısı dahil büyük alıcılar bu kurala sıkı biçimde uymaktadır.

Hangi Mekanizmalar DNS Sorgusu Tüketir?

SPF kaydındaki her mekanizma aynı DNS maliyetini taşımaz. Aşağıdaki tablo RFC 7208 Bölüm 5'e göre hangi mekanizmaların DNS sorgusu tükettiğini özetlemektedir:

Neden 10 Sınırına Bu Kadar Kolay Ulaşılıyor?

Modern e-posta altyapısı onlarca üçüncü taraf servisi bünyesinde barındırır: CRM araçları, pazarlama otomasyon platformları, destek yazılımları, ERP sistemleri ve daha fazlası. Her servis, kendi SPF kaydınıza bir include: satırı eklemenizi ister. Örneğin:

• include:_spf.google.com — Google Workspace (kendi içinde birden fazla sorgu tüketir)
• include:sendgrid.net — SendGrid
• include:spf.protection.outlook.com — Microsoft 365
• include:amazonses.com — Amazon SES
• include:_spf.salesforce.com — Salesforce
• include:connect365.com.tr — Connect365 gibi toplu posta platformları

Bu örnekte henüz 6 include direktifi var; ancak her birinin kendi iç kayıtlarında ek sorgular yaptığını hesaba kattığınızda toplam kolaylıkla 15-20 sınırına dayanır.

Hatayı Teşhis Etme

Aşağıdaki ücretsiz araçlar SPF kaydınızdaki toplam DNS sorgu sayısını gerçek zamanlı analiz eder:

• MXToolbox SPF Record Checker (mxtoolbox.com/spf.aspx): Her mekanizma için sorgu sayısını ayrı ayrı gösterir.
• dmarcian SPF Surveyor: Ağaç görünümüyle iç içe include zincirlerini görselleştirir.
• Google Admin Toolbox — Check MX: Google altyapısından SPF doğrulama testi yapmanızı sağlar.
• dig / nslookup: Komut satırından dig TXT alanadiniz.com komutuyla ham SPF kaydını görüntüleyebilirsiniz.

Terminal üzerinden hızlı bir kontrol için:

dig +short TXT alanadiniz.com | grep "v=spf1"

Bu komut mevcut SPF kaydınızı döndürür. Ardından her include hedefini özyinelemeli olarak sorgulayarak toplam sayıyı elle de hesaplayabilirsiniz; ancak yukarıdaki araçlar bunu otomatik yapar.

Adım Adım Çözüm Yöntemleri

1. Kullanılmayan Servisleri Temizleyin

En hızlı kazanım, artık kullanmadığınız servisler için eklediğiniz include satırlarını kaldırmaktır. E-posta gönderme altyapınızı envantere alın: hangi servisler gerçekten alan adınız üzerinden e-posta gönderiyor? Kullanılmayan SaaS entegrasyonları, eski ESP (E-posta Servis Sağlayıcısı) kalıntıları ve test ortamı kayıtları bu kategoriye girer.

2. IP Adreslerini Doğrudan Kullanın

Bir include mekanizmasının arkasındaki nihai IP aralığı sabitse, DNS sorgusu tüketen mekanizma yerine doğrudan ip4: veya ip6: bloğu kullanabilirsiniz. Örneğin bazı küçük ESP'lerin include kaydı tek bir /24 bloğuna işaret ediyorsa:

# Öncesi (1 DNS sorgusu tüketir)
include:mail.example-esp.com

# Sonrası (0 DNS sorgusu tüketir)
ip4:203.0.113.0/24

Uyarı: ESP, IP aralığını değiştirirse kaydınızı manuel güncellemeniz gerekir. Bu yöntemi yalnızca IP aralıklarını nadiren değiştiren servisler için tercih edin.

3. SPF Kaydını Düzleştirme (Flattening)

SPF düzleştirme, tüm iç içe include zincirlerini otomatik olarak çözerek yalnızca nihai IP adreslerini içeren tek bir SPF kaydı üretir. AutoSPF, PowerSPF ve dmarcian gibi araçlar bu işlemi yönetilen bir DNS servisi olarak sunar: DNS sorgularınızı kendi altyapıları üzerinden proxy'leyerek görünür sorgu sayısını 1-3 arasında tutar.

Bu çözümün dezavantajı, nihai SPF kararının üçüncü taraf bir servise bağımlı hale gelmesidir. Servis kesintisi yaşanırsa SPF doğrulaması da etkilenir.

4. SPF Makrolarını Kullanın

RFC 7208 Bölüm 7, %{d}, %{i}, %{s} gibi makro değişkenleri tanımlar. exists mekanizmasıyla makrolar birleştirilerek tek bir DNS sorgusuyla çok sayıda IP kontrolü yapılabilir. Bu yöntem ileri düzey yapılandırma gerektirir ve genellikle büyük ölçekli e-posta altyapılarında tercih edilir.

5. Alt Alan Adı Göndericisi Stratejisi

Pazarlama e-postalarını bilgi@haber.alanadiniz.com, destek yazışmalarını destek@alanadiniz.com gibi farklı alt alan adları üzerinden göndermek, her alt alan adına ayrı ve daha az mekanizma içeren bir SPF kaydı atamanıza olanak tanır. Bu yaklaşım hem SPF hem de DMARC (RFC 7489) yönetimini basitleştirir.

Çözüm Sonrası Doğrulama

SPF kaydını güncellendikten sonra DNS TTL süresi dolmadan değişiklikler yayılmaz. TTL süreniz 3600 saniye (1 saat) ise güncellemeden 1 saat sonra test yapın. Doğrulama için:

• MXToolbox üzerinden SPF sorgu sayısını yeniden kontrol edin; 10'un altında olduğunu teyit edin.
• Google Admin Toolbox ile gerçek bir doğrulama testi çalıştırın.
• Bir test e-postası gönderin ve alıcı sunucunun döndürdüğü Authentication-Results başlığında spf=pass yazdığını kontrol edin.

DMARC raporlarını (RFC 7489 kapsamında) etkinleştirdiyseniz, rua adresine gelen XML raporlarda spf alanındaki result değerini de izleyin.

Sık Sorulan Sorular