SPF Kaydı Çalışmıyor: 10 DNS Lookup Limiti ve PermError Çözümü

Bir SPF doğrulama aracına alan adınızı yazdınız ve karşınıza kırmızı bir satır çıktı: "Too many DNS lookups" ya da doğrudan permerror. Oysa SPF kaydınız yerinde duruyor, sözdiziminde bir hata yok, hatta yıllardır aynı kayıt kullanılıyor. Değişen tek şey, geçen ay pazarlama ekibinin yeni bir bülten aracı istemesi ve sizin kaydın sonuna bir include: daha eklemenizdi.

Bu hatanın en can sıkıcı yanı sessiz olmasıdır. SPF limiti aşıldığında kayıt "yok" sayılmaz; geçersiz sayılır. Alıcı sunucu doğrulamayı yarıda kesip permerror döndürür ve o andan itibaren SPF sonucunuz pass değildir — meşru sunucularınızdan çıkan mailler dahil. DMARC devredeyse SPF hizalaması da çöker; ayakta kalan tek dayanağınız DKIM olur. DKIM'i de kurmadıysanız p=quarantine veya p=reject politikanız kendi maillerinizi vurmaya başlar.

Bu yazıda limitin neyi saydığını, hangi mekanizmaların bedava olduğunu, gerçek sağlayıcı kayıtlarıyla bir SPF ağacının nasıl sayıldığını ve dört çözüm yolunu — en ucuzundan en riskli olanına — ele alacağız. Sondaki flattening bölümü özellikle önemli: çoğu kaynak onu ilk çözüm gibi sunar, oysa doğru yerde son çaredir.

SPF'te "Too Many DNS Lookups" Hatası Tam Olarak Ne Demek#

SPF'i tanımlayan RFC 7208'in 4.6.4 numaralı bölümü, bir SPF kontrolü sırasında yapılabilecek DNS sorgusu gerektiren terim sayısını 10 ile sınırlar. Bu bir öneri değil, "MUST" ifadesiyle yazılmış bir zorunluluktur; yani standarda uyan her alıcı sunucu 11'inci sorguya geldiğinde değerlendirmeyi keser.

Limitin nedeni güvenliktir. include: iç içe geçebildiği için, kötü niyetli biri derin bir SPF ağacı kurup her maili yüzlerce DNS sorgusuna dönüştürebilir ve alıcı sunucuyu amplifikasyon aracına çevirebilir. 10'luk tavan bu maliyeti sabitler.

Limit aşıldığında dönen sonuç permerror'dur ve bu, "kalıcı hata" anlamına gelir. temperror gibi tekrar denenmez, none gibi "kayıt yok" olarak da yorumlanmaz. Alıcı tarafında pratik karşılığı şudur:

Authentication-Results: mx.google.com;
       spf=permerror (google.com: too many DNS lookups for domain ornek.com.tr)
       dkim=pass [email protected] header.s=google
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ornek.com.tr

Bu örnekte DMARC yine de pass görünüyor, çünkü DKIM hizalı ve geçerli. DKIM olmasaydı bu satır dmarc=fail olurdu. SPF, DKIM ve DMARC'ın birbirini nasıl tamamladığını SPF, DKIM ve DMARC rehberimizde bulabilirsiniz.

Belirti → Sebep → Sonuç zinciri şudur: "too many lookups" uyarısı → SPF ağacı 10 sorguyu aşıyor → SPF asla pass dönmez → DMARC yalnızca DKIM'e dayanır → DKIM de zayıfsa mailler karantinaya gider.

Hangi Mekanizmalar Sorgu Sayıyor, Hangileri Saymıyor#

Buradaki en yaygın yanılgı, "kaydımda 6 tane include var, limitin altındayım" diye düşünmektir. Sayılan şey yazdığınız terim sayısı değil, değerlendirme sırasında yapılan DNS sorgusu sayısıdır. Bir include, işaret ettiği kaydın içindeki tüm sorguları da sizin bütçenizden düşer.

Tablodan üç pratik sonuç çıkar. ip4 ve ip6 bedavadır — yüz tane IP bloğu yazsanız bütçeniz azalmaz. exp= limitin dışındadır, çünkü yalnızca mail reddedildiğinde açıklama metni üretmek için sorgulanır. ptr ise RFC 7208'in 5.5 numaralı bölümünde açıkça "kullanmayın" denilerek işaretlenmiştir: hem yavaştır hem de ters DNS kayıtları çoğu ortamda güvenilmezdir.

mx mekanizmasının ikinci bir tuzağı var: mekanizmanın kendisi 1 sorgu sayılır, ancak dönen MX kayıtlarının her biri için ayrıca A/AAAA çözümlemesi yapılır ve standart bu sayıyı da 10 ile sınırlar. 12 MX kaydı olan bir alan adında mx mekanizması tek başına permerror üretebilir.

Gerçek Bir Kaydın Lookup'larını Tek Tek Sayalım#

Aşağıdaki kayıt uydurma değil; üç yılda organik olarak büyümüş tipik bir kurumsal SPF'in birebir aynısı. Şirket Google Workspace ile başlamış, uygulama maillerini SendGrid'e vermiş, bülten için Mailchimp eklemiş, CRM olarak HubSpot kurmuş, destek sistemi Zoho'ya taşınmış, arada Mailjet ve Mailgun denenmiş ama kayıttan hiç silinmemiş:

ornek.com.tr. 3600 IN TXT "v=spf1 a mx include:_spf.google.com include:sendgrid.net include:_spf.hubspot.com include:servers.mcsv.net include:zoho.com include:spf.mailjet.com include:mailgun.org ~all"

Gözle bakınca 7 include görünüyor ve "limit 10, sorun yok" diye düşünmek çok kolay. Şimdi her terimin arkasındaki ağacı açalım. Aşağıdaki sayılar 18 Ağustos 2026'da dig ile canlı kayıtlardan çıkarılmıştır:

Limit 10, gerçek maliyet 18. Kayıt değerlendirme sırasında 11'inci sorguda kesilir ve permerror döner. Dikkat edilmesi gereken nokta, kesilme noktasının sıraya bağlı olmasıdır: zoho.com kayıtta beşinci sırada olduğu için ondan sonrası hiç okunmaz. Yani Mailjet ve Mailgun kayıtta yazıyor olsa bile fiilen yok hükmündedir.

Bir başka çarpıcı ayrıntı: include:_spf.google.com bugün yalnızca 1 sorgu. Yıllarca bu include 4 sorgu maliyetindeydi, çünkü içinde _netblocks, _netblocks2 ve _netblocks3 alt kayıtları vardı. Google bunları tek kayda topladı. Bu iyi haber gibi görünse de asıl dersi verir: include maliyetleri sizin haberiniz olmadan değişir. Bugün rahat olan bir kayıt, sağlayıcı yeni bir bölge eklediğinde altı ay sonra limiti aşabilir.

Lookup Sayısını Komut Satırından Nasıl Ölçersiniz#

Online araçlar hızlıdır ama sonucu "18" diye verir, nerede patladığını göstermez. Ağacı kendiniz gezmek hem daha öğreticidir hem de değişiklikten sonra doğrulama yapmanızı sağlar. Önce tek bir kaydı okumak için:

# Alan adının SPF kaydını oku
dig +short TXT ornek.com.tr | grep -i "v=spf1"

# Bir include hedefinin içine bak
dig +short TXT zoho.com | tr -d '"' | grep -i "v=spf1"

dig ve nslookup kullanımının ayrıntıları için DNS sorgulama araçları yazımıza bakabilirsiniz. Ağacın tamamını özyinelemeli olarak saymak içinse şu betik işinizi görür:

#!/usr/bin/env bash
# spf-say.sh — bir alan adının SPF ağacını gezip DNS sorgu sayısını sayar
# Kullanım: ./spf-say.sh ornek.com.tr

COUNT=0

gez() {
  local hedef="$1" derinlik="$2" kayit terim
  kayit=$(dig +short TXT "$hedef" | tr -d '"' | grep -i '^v=spf1' | head -1)

  if [ -z "$kayit" ]; then
    printf '%*s%s  <-- KAYIT YOK (void lookup)\n' $((derinlik * 2)) '' "$hedef"
    return
  fi

  printf '%*s%s\n' $((derinlik * 2)) '' "$hedef"

  for terim in $kayit; do
    case "$terim" in
      include:*)
        COUNT=$((COUNT + 1)); gez "${terim#include:}" $((derinlik + 1)) ;;
      redirect=*)
        COUNT=$((COUNT + 1)); gez "${terim#redirect=}" $((derinlik + 1)) ;;
      a|mx|ptr|a:*|mx:*|ptr:*|a/*|mx/*|exists:*)
        COUNT=$((COUNT + 1))
        printf '%*s[%s] +1\n' $(((derinlik + 1) * 2)) '' "$terim" ;;
    esac
  done
}

gez "$1" 0
echo "----------------------------------------"
echo "TOPLAM DNS SORGUSU: $COUNT   (limit: 10)"

Betiği chmod +x spf-say.sh ile çalıştırılabilir yapıp alan adınızla çağırdığınızda, hangi include'ın kaç sorgu getirdiğini girintili bir ağaç olarak görürsünüz — en pahalı dalı bulmanın en hızlı yolu. Betik yaygın mekanizma yazımlarını kapsar; makro içeren egzotik kayıtlarda sonucu bir doğrulama aracıyla teyit edin.

Az Bilinen İkinci Limit: 2 Void Lookup#

10 sorgu limitine takılmadığı hâlde permerror dönen kayıtlar görürsünüz. Sebebi genellikle ikinci ve çok daha az bilinen sınırdır: void lookup limiti. RFC 7208, NXDOMAIN dönen ya da hiç yanıt içermeyen sorguların sayısını 2 ile sınırlar. Üçüncüsünde değerlendirme yine permerror ile biter.

Bu limit şu senaryoda patlar: kapattığınız bir servisin include'ı kayıtta durur ve sağlayıcı o alan adını silmiştir. Sözdizimi kusursuzdur, sorgu sayınız 6'dır, ama iki ölü include artı yanlış yazılmış bir a:mail.eskisunucu.com sizi limite taşır.

Ölü include avlamak için yukarıdaki betiğin KAYIT YOK satırlarına bakmanız yeterlidir. Tek tek kontrol etmek isterseniz:

# Yanıtın NOERROR mı NXDOMAIN mı olduğunu göster
dig TXT eski-servis.example +noall +comment | grep status

# Boş yanıt da void sayılır: status NOERROR ama ANSWER: 0
dig TXT baska-servis.example +noall +comment | grep -E "status|ANSWER"

Kural basit: SPF kaydında NXDOMAIN dönen veya boş yanıt veren terim bırakmayın. Bunlar bütçe harcamakla kalmaz, ikinciden sonrasında kaydı geçersiz kılar.

Çözüm 1: Kullanılmayan include'ları Temizleyin#

Uygulanacak ilk adım her zaman budur, çünkü bedava, geri alınabilir ve çoğu vakada tek başına yeterlidir. Yukarıdaki 18 sorgunun 4'ü (Mailjet + Mailgun) artık kullanılmayan servislerden geliyordu; onları silmek maliyeti anında 14'e indirir.

Zor kısım "hangisi gerçekten kullanılıyor" sorusudur. Tahmin etmeyin, ölçün: p=none politikasıyla iki hafta DMARC raporu topladığınızda, alan adınız adına mail gönderen her IP raporlarda source_ip olarak görünür. Hiç görünmeyen bir include silinmeye adaydır.

Şu sırayı izleyin:

1. DMARC kaydınıza rua=mailto: ekleyin ve en az 14 gün rapor biriktirin.
2. Raporlardaki source_ip değerlerini whois ile hangi sağlayıcıya ait olduklarını görmek için çözün.
3. Kayıttaki her include için "bu sağlayıcıdan son 14 günde mail geldi mi" sorusunu yanıtlayın.
4. Gelmeyenleri silin, ama önce ilgili ekibe sorun — yılda bir çalışan bir fatura entegrasyonu 14 günlük pencereye düşmeyebilir.
5. Silme işlemini tek seferde değil, birer birer ve arada 24 saat bekleyerek yapın.

Beşinci adımdaki temkin önemli: yanlış silinen bir include'ın etkisi anında görünmez, ama o servisten çıkan tüm mailler SPF'ten kalır.

Çözüm 2: Gönderenleri Alt Alan Adlarına Ayırın#

Bu, uzun vadede en sağlıklı çözümdür ve şaşırtıcı biçimde en az kullanılanıdır. 10 sorgu limiti kayıt başına uygulanır, alan adı ailesi başına değil. Yani ornek.com.tr için 10, bulten.ornek.com.tr için ayrı bir 10, bildirim.ornek.com.tr için yine ayrı bir 10 bütçeniz vardır.

Yapılması gereken, her gönderen sistemi kendi alt alan adından mail atacak şekilde yapılandırmak ve SPF'i oraya taşımaktır:

; Ana alan adı: yalnızca insanların yazdığı mailler
ornek.com.tr.          3600 IN TXT "v=spf1 include:_spf.google.com -all"

; Bülten: Mailchimp
bulten.ornek.com.tr.   3600 IN TXT "v=spf1 include:servers.mcsv.net -all"

; Uygulama bildirimleri: SendGrid
bildirim.ornek.com.tr. 3600 IN TXT "v=spf1 include:sendgrid.net -all"

; CRM: HubSpot
crm.ornek.com.tr.      3600 IN TXT "v=spf1 include:_spf.hubspot.com -all"

Ana kayıt 18 sorgudan 1 sorguya düşer ve ~all yerine güvenle -all yazabilirsiniz. Her alt alan da kendi bütçesinde rahat rahat oturur.

Buradaki kritik ayrıntı DMARC hizalamasıdır. Varsayılan gevşek (relaxed) hizalamada — aspf=r — zarf gönderici alan adının kurumsal alan adı (organizational domain) ile eşleşmesi yeterlidir. bulten.ornek.com.tr ile ornek.com.tr aynı kurumsal alan adına ait olduğundan hizalama geçer. Yalnızca aspf=s (katı) kullanıyorsanız bu yapı hizalamayı bozar; o durumda ya katı hizalamadan vazgeçin ya da her alt alan için ayrı DMARC kaydı yazın.

İkinci ayrıntı: ayrımı yaptıktan sonra sağlayıcı panelinde gönderen alan adını da değiştirmelisiniz. Mailchimp'te "verified domain" hâlâ ornek.com.tr ise SPF'i alt alana taşımak işe yaramaz — kontrol edilen, zarftaki alan adıdır. Bu ayrım itibar yönetimi açısından da faydalıdır: bir kampanya şikâyet alırsa kara listeye düşen alt alan olur, fatura maillerini gönderen ana alan adı değil.

Çözüm 3: a, mx ve ptr Yerine Doğrudan ip4 Yazın#

Kendi kontrolünüzdeki sunucular için mekanizma kullanmak gereksiz bir lükstür. a ve mx her biri 1 sorgu harcar; oysa kendi sunucunuzun IP'si zaten sabittir ve ip4 bedavadır.

; ÖNCE — 2 sorgu harcıyor
"v=spf1 a mx include:_spf.google.com -all"

; SONRA — 1 sorgu (yalnızca include)
"v=spf1 ip4:203.0.113.25 ip4:203.0.113.26 include:_spf.google.com -all"

Bu değişiklik iki sorgu kazandırır ve kaydı hızlandırır: alıcı sunucu iki ek DNS turu beklemez. Ayrıca a mekanizması sinsi bir hataya açıktır — web sunucunuzun A kaydını bir CDN'e yönlendirdiğinizde, farkında olmadan CDN'in tüm IP havuzunu yetkili gönderici yapmış olursunuz.

Takas açıktır: sunucu IP'niz değişirse SPF kaydını elle güncellemeniz gerekir. Kendi kolokasyon veya kiralık sunucunuzda IP yıllarca değişmez, dolayısıyla bu takas mantıklıdır. Bulut sağlayıcısında dinamik IP kullanıyorsanız a mekanizmasında kalın.

ptr mekanizmasına gelince: kaydınızda varsa koşulsuz silin. Standart tarafından önerilmez, birçok alıcı zaten yok sayar ve tek başına 1 sorgu harcar. Ters DNS'in doğru yeri SPF değil, PTR kaydının kendisidir.

Son Çare: SPF Flattening ve Gizli Bedeli#

Flattening, tüm include ağacını çözüp elde edilen IP bloklarını tek kayda ip4:/ip6: olarak yazmaktır. ip4 sorgu saymadığı için lookup maliyeti sıfıra iner:

; Flatten edilmiş kayıt — 0 lookup, ama bakım borcu yüksek
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip4:167.89.0.0/17 ip4:149.72.0.0/16 ip4:205.201.128.0/20 ip4:198.2.128.0/18 -all"

Sorun şu ki bu kayıt, yazıldığı andaki fotoğraftır. Sağlayıcılar IP havuzlarını haber vermeden değiştirir — zaten include mekanizmasının varlık sebebi tam olarak budur. Google yeni bir /17 bloğu eklediğinde include:_spf.google.com kullananlar hiçbir şey yapmaz, flatten etmiş olanların ise o bloktan çıkan mailleri sessizce SPF'ten kalır. Ne hata mesajı gelir ne uyarı; sadece teslimat oranı düşer.

Flattening'in üç somut bedeli vardır:

Boyut da dikkat ister: tek bir TXT dizesi en fazla 255 karakter olabilir, daha uzun kayıtlar tırnaklı parçalara bölünür ve doğrulayıcı bunları birleştirir. Bu mekanik için TXT kaydı yazımıza bakın; parçalara ayırırken mekanizmayı ortadan bölmek sık görülen bir hatadır.

Otomatik flattening hizmetleri bu bakımı üstlenir: SPF kaydınızı include:spf.hizmetsaglayici.com yapar, o kayıt düzenli yeniden üretilir. Bu sorunu çözmez, taşır — kimlik doğrulamanızın geçerliliği artık üçüncü bir tarafın çalışma süresine bağlıdır. Bunun bilinçli bir devretme olduğunun farkında olun.

Pratik tavsiye: flattening'i yalnızca kendi kontrolünüzdeki statik bölümlere uygulayın. Kendi sunucularınızı ip4 yazın, büyük sağlayıcıların include'larını olduğu gibi bırakın — yani çözüm 3'ü uygulayın, kaydın tamamını dondurmayın.

Değişiklikten Sonra Doğrulama ve İzleme#

Kaydı düzelttiğinizde iş bitmiş olmaz. TTL süresi boyunca eski kayıt önbelleklerde yaşamaya devam eder; testi hemen yapıp "olmadı" demeyin. Kontrol sırası şöyle:

# 1) Yeni kayıt yayılmış mı — TTL'i de göster
dig TXT ornek.com.tr +noall +answer

# 2) Lookup sayısını yeniden ölç
./spf-say.sh ornek.com.tr

# 3) Kayıtta birden fazla v=spf1 var mı (varsa permerror üretir)
dig +short TXT ornek.com.tr | grep -ci "v=spf1"

Üçüncü kontrol atlanmaması gereken bir tanedir. Bir alan adında yalnızca bir tane v=spf1 kaydı bulunabilir. İkinci bir kayıt (örneğin hosting paneli otomatik eklediyse) tek başına permerror üretir ve 10 lookup limitiyle hiç ilgisi yoktur. Sayı 1 dönmelidir.

Ardından gerçek bir mail göndererek başlıkları okuyun. Gmail'de maili açıp Orijinali göster dediğinizde spf=pass satırını görmelisiniz. Kalıcı izleme içinse DMARC raporlarınızı düzenli okumaya devam edin: SPF sonucunun rapordaki policy_evaluated bölümünde pass görünmesi, kaydınızın gerçekten çalıştığının tek nesnel kanıtıdır. Toplu gönderim yapıyorsanız Gmail ve Yahoo'nun gönderici kurallarını da gözden geçirmekte fayda var; SPF'i düzeltmek o listenin yalnızca bir maddesidir.

Son olarak bir alışkanlık edinin: SPF kaydına dokunan herkes, değişiklikten sonra lookup sayısını ölçsün. Bu hata kaydı bozarak değil, kayda bir satır daha ekleyerek oluşur; önlemi de ekleme anında almak gerekir.

Sıkça Sorulan Sorular#

SPF permerror hatası mailimin gitmesini tamamen engeller mi?#

Doğrudan engellemez, ama korumasız bırakır. permerror alan bir mail SPF'ten geçmemiş sayılır; alıcı sunucu kararını DKIM, alan adı itibarı ve içerik analizine göre verir. DKIM kuruluysa mail çoğunlukla teslim edilir. DKIM yoksa ve DMARC politikanız quarantine veya reject ise mailleriniz karantinaya alınır ya da doğrudan reddedilir.

Kaydımda 6 include var ama araç 13 lookup diyor, nasıl oluyor?#

Çünkü sayılan şey yazdığınız include sayısı değil, değerlendirme sırasında yapılan toplam DNS sorgusudur. Her include, işaret ettiği kaydın içindeki include, a ve mx terimlerini de sizin bütçenizden düşer. Örneğin include:zoho.com içinde dört ayrı include barındırdığı için tek başına 5 sorguya mal olur. Ağacı gezmeden gerçek maliyeti göremezsiniz.

SPF flattening yapmak güvenli mi?#

Teknik olarak geçerli bir kayıt üretir ama bakım borcu yaratır. Sağlayıcılar IP havuzlarını haber vermeden değiştirdiğinde flatten edilmiş kaydınız eksik kalır ve bunu hata mesajından değil, düşen teslimat oranından anlarsınız. Kendi statik sunucu IP'lerinizi doğrudan yazmak güvenlidir; büyük sağlayıcıların include'larını dondurmak ise düzenli yeniden üretim gerektirir.

Alt alan adına ayırma DMARC hizalamasını bozar mı?#

Varsayılan gevşek hizalamada (aspf=r) bozmaz. bulten.ornek.com.tr ile ornek.com.tr aynı kurumsal alan adına ait olduğu için hizalama geçer. Yalnızca aspf=s yani katı hizalama kullanıyorsanız sorun çıkar; bu durumda ya katı hizalamadan vazgeçin ya da her alt alan adı için ayrı bir DMARC kaydı tanımlayın.

Aynı alan adına iki ayrı SPF kaydı yazabilir miyim?#

Hayır. Standart bir alan adı için yalnızca tek bir v=spf1 kaydına izin verir. İki kayıt bulunduğunda doğrulayıcı hangisinin geçerli olduğunu belirleyemez ve doğrudan permerror döndürür. Bu, lookup limitinden bağımsız bir hatadır. Yeni bir gönderici eklemeniz gerekiyorsa mevcut kaydın içine include olarak ekleyin, ikinci kayıt açmayın.

SPF kaydını değiştirdim ama araç hâlâ eski kaydı gösteriyor, ne yapmalıyım?#

Kaydın TTL süresi boyunca eski değer önbelleklerde kalır. TTL değerini dig TXT alanadiniz +noall +answer çıktısındaki sayıdan görebilirsiniz; genellikle 3600 saniyedir. O süre dolmadan tüm doğrulayıcıların yeni kaydı görmesini beklemeyin. Değişiklik yapmayı planlıyorsanız bir gün önceden TTL'i 300 saniyeye düşürmek geçiş süresini belirgin şekilde kısaltır.