SPF PermError Nedir? 10 DNS Sorgusu Sınırı Nasıl Kontrol Edilir?

Başlıkta spf=permerror görüyorsanız alıcı sunucu SPF kaydınızı yorumlayamamış demektir. RFC 7208 bu sonucu, yayımlanan kaydın doğru okunamadığı ve düzeltmek için DNS yöneticisinin müdahalesi gereken durum olarak tanımlar. Nedeni çoğu durumda, değerlendirme sırasında DNS sorgusu gerektiren terimlerin (include, a, mx, ptr, exists ve redirect) toplamda 10'u aşmasıdır. Aynı adda iki SPF kaydı, söz dizimi hatası, kaydı olmayan bir include hedefi ve ikiden fazla boş yanıt da aynı sonucu verir. Çözüm, include ağacını dig ile sayıp kullanılmayan girdileri ayıklamak, sabit sunucular için ip4/ip6 yazmak ve gerekirse bazı göndericileri alt alan adına taşımaktır.

permerror başlıkta nasıl görünür?

Sorunlu bir postanın tam başlıklarını açın. İki satır işinize yarar: alıcının doğrulama özetini yazdığı Authentication-Results ve SPF denetleyicisinin eklediği Received-SPF. Aşağıdaki örnek varsayımsaldır, alıcı sunucu mx.ornek.com, gönderen alan adı ornek.com.tr:

Authentication-Results: mx.ornek.com;
       spf=permerror smtp.mailfrom=ornek.com.tr;
       dkim=pass header.d=ornek.com.tr;
       dmarc=pass header.from=ornek.com.tr
Received-SPF: permerror client-ip=192.0.2.25;
       envelope-from="bilgi@ornek.com.tr";
       helo=mail.ornek.com.tr; receiver=mx.ornek.com;
       identity=mailfrom

Burada ilk bakılacak alan smtp.mailfrom değeridir. SPF, postanın Kimden (From) satırındaki adrese göre değil, zarf göndericisine (Return-Path olarak da görürsünüz) göre denetlenir. Bülten servisinden çıkan bir postada bu alan servisin kendi alan adını gösteriyorsa bozuk kayıt onlarındır ve sizin kaydınızla uğraşmanıza gerek yoktur. client-ip ise postayı teslim eden sunucuyu söyler. Bazı alıcılar problem= anahtarıyla hatanın ayrıntısını da yazar.

Sonuçları birbirine karıştırmamak gerek. temperror geçici bir DNS sorunudur, örneğin zaman aşımı, ve bir sonraki denemede düzelebilir. fail ya da softfail kaydın okunduğunu ama gönderen IP'nin listede olmadığını gösterir. permerror ise kaydın kendisinin bozuk olduğunu söyler. Beklemekle geçmez.

RFC 7208'e göre hangi terimler sorgu harcar?

Sınırın amacı, tek bir postanın denetimi için DNS'e makul olmayan bir yük bindirilmesini önlemek. RFC 7208'in 4.6.4 bölümü sorgu yapan terimleri tek tek sayar ve toplamlarını 10 ile sınırlar. Sınır aşılırsa uygulama permerror döndürmek zorundadır.

Kendi kaydınızda dört include görmeniz, dört sorgu harcadığınız anlamına gelmez. Her include, hedefindeki kaydın değerlendirilmesini başlatır ve o kayıttaki include, a ya da mx terimleri de aynı 10'luk bütçeden düşülür. Büyük posta ve bülten sağlayıcılarının kayıtları sıklıkla kendi içinde birkaç include daha barındırır. Kaç sorgu harcadıkları sağlayıcıya göre değişir, üstelik zamanla değişebilir.

Gözden kaçan bir ayrıntı daha var. Mekanizmalar soldan sağa değerlendirilir ve ilk eşleşmede işlem biter. Yani sınır, o posta için gerçekten işletilen terimlere uygulanır. İlk ip4 girdisiyle eşleşen sunucunuzdan çıkan posta hiçbir zaman 11. terime ulaşmaz ve pass alır. Kaydın sonundaki bir include ile eşleşen fatura sisteminiz ise permerror alabilir. "Bazı postalarımız geçiyor, bazıları geçmiyor" şikâyetinin arkasında çoğu zaman bu vardır.

İşin can sıkıcı tarafı şu: listede olmayan, yani sizi taklit eden bir sunucu her zaman ağacın tamamını yürütür. Toplam 10'u aşıyorsa sahte postalar fail yerine permerror alır ve kaydın sonundaki -all hiç devreye girmez. Bu yüzden hedef, en kötü yolda bile toplamın 10'u geçmemesi olmalı.

mx ve ptr için ek alt sınır

mx mekanizması 10'luk toplama bir terim olarak girer. Buna ek olarak, MX kayıtlarındaki adların adreslerini bulmak için 10'dan fazla A veya AAAA sorgusu gerekiyorsa mx mekanizması tek başına permerror üretir. ptr için de aynı 10'luk alt sınır geçerlidir ama aşan kayıtlar hata üretmez, yalnızca ilk 10'u dikkate alınır. RFC farkı şöyle açıklıyor: MX kayıtları alan adı sahibinin denetimindedir, PTR kayıtları ise bağlantıyı yapan IP'nin sahibinin. Bizce ptr'yi kayıttan çıkarmak için başka gerekçe aramaya gerek yok, hem yavaş hem de standart onu önermiyor.

Boş yanıt (void lookup) sınırı

Bir sorgu hatasız döner ama cevap bölümü boştur ya da alan adı hiç yoktur (NXDOMAIN). RFC bunlara "void lookup" der ve uygulamaların bu tür yanıtları ikiyle sınırlamasını önerir (SHOULD). Sınır aşılırsa sonuç yine permerror olur. Tipik kaynak, yıllar önce silinmiş bir sunucuyu gösteren a:eski.ornek.com.tr gibi girdilerdir. "SHOULD" ifadesi alıcıların bu sınırı farklı uygulayabileceği anlamına gelir. Biz hedefi sıfır boş yanıt olarak koymanızı öneriyoruz.

Sayı aşılmadan da permerror alınır

Kaydınızda yalnız üç include var ve yine de permerror mı geliyor? O zaman sorunu kaydın biçiminde aramak gerekir. Tek kayıt kuralını ve temel söz dizimini SPF, DKIM ve DMARC kayıtlarının nasıl kurulduğunu anlattığımız rehberde ele aldık. Burada RFC'nin doğrudan permerror'a bağladığı durumları sıralıyoruz:

• Aynı adda v=spf1 ile başlayan iki TXT kaydı var. Yeni bir servis "şu TXT kaydını ekleyin" dediğinde mevcut kayda eklemek yerine ikinci bir kayıt açılması en yaygın örnek.
• Kaydın herhangi bir yerinde söz dizimi hatası var. ipv4: gibi tanımsız bir mekanizma adı, include: spf.ornek.com içindeki iki noktadan sonraki boşluk, ip4:192.0.2.0/33 gibi geçersiz bir ağ maskesi ya da bir metin düzenleyiciden kopyalanan akıllı tırnak bu sınıfa girer.
• Include hedefinde SPF kaydı yok. RFC, include'un gösterdiği alan adında kayıt bulunmamasını "eşleşmedi" diye değil, permerror olarak ele alır. Servis sağlayıcınız include adını değiştirdiğinde ya da aboneliği bitirdiğiniz servis kaydını kaldırdığında bu olur.
• redirect hedefinde kayıt yok, ya da redirect veya exp değiştiricisi kayıtta birden fazla kez geçiyor.
• Uzun kayıt DNS panelinde birkaç metin parçasına bölünmüş ve parçaların arasında boşluk kalmamış.

Son madde açıklamayı hak ediyor. RFC 7208'e göre bir TXT kaydı birden fazla metin parçasından oluşuyorsa parçalar araya boşluk eklenmeden birleştirilir. Şu kayıt iki parça hâlinde yayımlanmış olsun:

"v=spf1 ip4:192.0.2.10 include:spf.bulten.ornek.com"
"include:spf.crm.ornek.com ~all"

Alıcı bunu ...spf.bulten.ornek.cominclude:spf.crm.ornek.com diye okur ve kayıt bozulur. Boşluğu ilk parçanın sonuna ya da ikincinin başına koymak yeterlidir.

Elle sayım: dig ile include ağacını çıkarmak

Varsayımsal senaryo: ornek.com.tr alan adının SPF kaydı şöyle olsun.

v=spf1 a mx include:spf.ofis.ornek.com
  include:spf.bulten.ornek.com include:spf.crm.ornek.com
  include:spf.fatura.ornek.com ~all

Önce kökteki kaydı, sonra her include hedefini sorgulayın:

dig +short TXT ornek.com.tr
dig +short TXT spf.ofis.ornek.com
dig +short TXT spf.bulten.ornek.com

Çıktıda v=spf1 ile başlayan satıra bakın. Aynı satırda tırnak içinde birden çok parça görürseniz bunlar tek kaydın parçalarıdır. Her yeni hedefte include, a, mx, ptr, exists ve redirect terimlerini not edin ve iç içe include'ları da aynı şekilde açın. Varsayımsal örneğimizde ağaç şöyle çıkıyor:

ornek.com.tr
  a                                 1
  mx                                2
  include:spf.ofis.ornek.com        3
    include:k1.ofis.ornek.com       4
    include:k2.ofis.ornek.com       5
  include:spf.bulten.ornek.com      6
    include:ag.bulten.ornek.com     7
  include:spf.crm.ornek.com         8
    a:gonder.crm.ornek.com          9
    include:eu.crm.ornek.com       10
  include:spf.fatura.ornek.com     11  <- sınır aşıldı
    mx                             12

Bülten servisinin IP'lerinden gelen postalar yedinci terimde eşleşip geçer. Fatura sisteminden çıkan postalar ise 11. terimde permerror alır. Sahte postalar da öyle.

Boş yanıtları yakalamak için +short kullanmadan sorgulayın ve başlık satırındaki duruma bakın. status: NXDOMAIN ya da status: NOERROR ile birlikte ANSWER: 0 görüyorsanız o terim boş yanıt sayılır:

dig TXT eski.ornek.com.tr
dig A gonder.crm.ornek.com
dig +short MX ornek.com.tr

Son komut kaydınızdaki mx teriminin kaç ada çözüleceğini gösterir. 10'dan fazla ad listeleniyorsa mx mekanizması kendi alt sınırına takılır.

Çevrim içi denetleyiciler ne zaman yanıltır?

MxToolbox, dmarcian ve benzeri SPF denetleyicileri ağacı sizin yerinize çizer ve toplamı gösterir. Çoğu, ilk eşleşmede durmayan en kötü yolu sayar. Bu doğru bir yaklaşım ama tek bir postanın neden geçtiğini açıklamaz. Boş yanıtları kimi araç uyarı olarak gösterir, kimi hiç saymaz. İki araç farklı sayı veriyorsa dig ile kendiniz sayın. Bir de şunu unutmayın: üçüncü taraf kayıtları sizden habersiz değişir. Bugün 9 olan toplam, sağlayıcı kendi kaydına bir include eklediğinde yarın 11 olabilir. Ayda bir kontrol bizce makul bir aralık.

Kaydı 10'un altına indirmenin yolları

En az riskli adımdan başlayın. Aşağıdaki tablo, her yöntemin ne kazandırdığını ve neye mal olduğunu özetliyor:

Hangi servislerin gerçekten sizin adınıza posta gönderdiğini tahminle değil veriyle bulun. DMARC toplu raporlarında kaynak IP'leri ve SPF sonuçlarını okumak bu iş için en sağlam yoldur. Raporlarda aylardır hiç görünmeyen bir servisin include'u büyük olasılıkla artık gereksizdir.

İkinci kalem daha az bilinir. Pek çok bülten ve işlem postası servisi, zarf göndericisi olarak kendi alan adını kullanır. Bu durumda alıcı SPF'i onların kaydında denetler ve sizin kökteki include'unuz o postalar için hiç işletilmez. Servisten gelmiş bir postanın Return-Path satırına bakın. Orada sizin alan adınız yoksa include'un orada durması büyük olasılıkla işe yaramıyordur. Yine de servisin kendi kurulum belgesine göz atın, bazıları alan adı doğrulaması için bu kaydı arar.

Posta sunucunuzun IP'si sabitse a ve mx yerine doğrudan ip4:192.0.2.10 yazmak iki sorgu kazandırır. Bedeli, sunucu değiştiğinde kaydın kendiliğinden güncellenmemesidir. Hosting firmasını değiştirdikten sonra SPF'te eski IP'nin kalması, hosting değişikliğinin ardından e-postanın bozulmasının sık görülen nedenlerinden biridir.

Web sitesinin postaları da kendi girdisini ister. Sitenin bulunduğu sunucu doğrudan gönderim yapıyorsa onun IP'si de kayda girer. Oysa site postalarını kimliği doğrulanmış SMTP ile posta sunucunuz üzerinden gönderirseniz ayrı bir girdiye gerek kalmaz. Bu geçişte sık karşılaşılan engellerden biri SMTP 535 kimlik doğrulama hatasıdır. Sorun özellikle mağaza bildirimlerindeyse WooCommerce sipariş e-postalarında önce postanın hiç tetiklenip tetiklenmediğine, sonra hangi yoldan çıktığına bakmak gerekir.

Alt alan adı yöntemi büyük kayıtlarda en temiz çözümdür. Bülten servisini bulten.ornek.com.tr gibi bir zarf alan adıyla çalıştırırsanız o alan adının kendi SPF kaydı olur ve kendi 10'luk bütçesini kullanır. Kökteki kaydınız bu servisi hiç taşımaz. DMARC'ın gevşek (relaxed) hizalaması alt alan adını ve ana alan adını aynı kuruluş alan adı altında saydığından, kaydınızda aspf=s yoksa bu düzen DMARC'ı da bozmaz.

Düzleştirme, include'ların çözülmüş IP listelerini kayda doğrudan ip4/ip6 olarak yazmaktır. Açıkçası bunu son çare olarak görüyoruz. Sağlayıcı yeni bir IP bloğu eklediğinde haberiniz olmaz ve o bloktan çıkan postalar fail almaya başlar. Kayıt da hızla uzar. RFC 7208, SPF sorgusunun yanıtının 512 baytlık UDP sınırına sığacak kadar küçük kalmasını önerir. Otomatik düzleştirme servisleri ilk sorunu çözer ama alan adınızın kaydını bir üçüncü tarafa bağlar. Bu yolu seçecekseniz kaydınızı sağlayıcının güncel IP listesiyle karşılaştıran otomatik bir kontrol kurun, kuramıyorsanız en azından ayda bir elle karşılaştırın.

permerror DMARC'ı nasıl etkiler?

DMARC standardı Mayıs 2026'da RFC 9989 ile yenilendi ve RFC 7489'un yerini aldı. SPF tarafındaki temel kural aynı kaldı. DMARC, zarf göndericisi (MAIL FROM) için yapılan SPF denetiminin sonucunu kullanır. RFC 9989 bunu açıkça yazar: SPF geçen bir sonuç üretmiyorsa hizalama oluşamaz. permerror geçen sonuç olmadığı için o posta DMARC açısından SPF'ten hiçbir şey kazanmaz.

Bu durumda DMARC'ın kaderi DKIM'e kalır. Yukarıdaki örnek başlıkta olduğu gibi postada alan adınızla hizalı ve geçerli bir DKIM imzası varsa dmarc=pass çıkar, posta yoluna devam eder. Bu da insanı yanıltır: "permerror var ama postalar gidiyor" denip konu kapatılır. Oysa DKIM imzası atmayan her kaynak, çoğu zaman site formları ve eski uygulamalar, DMARC'tan kalır ve politikanız p=quarantine ya da p=reject ise o postalar spam klasörüne iner ya da geri döner. Spam klasörüne düşmenin diğer nedenlerini e-postaların neden spam'a düştüğünü anlattığımız yazıda sıraladık.

Alıcının yerel politikası da işin içine girer. RFC 7208, permerror nedeniyle SMTP aşamasında ret verilecekse 550 yanıt kodunun ve destekleniyorsa 5.5.2 genişletilmiş durum kodunun kullanılmasını önerir. Yani bazı alıcılar DMARC'a hiç bakmadan postayı reddedebilir. Hangi alıcının ne yaptığını önceden bilemezsiniz.

Düzelttikten sonra doğrulama

Kaydı değiştirdiniz. Şimdi gerçekten düzeldiğini görmek gerek:

1. dig +short TXT ornek.com.tr çıktısında v=spf1 ile başlayan tek bir satır ve yeni içerik görünmeli. Eski değer görünüyorsa kaydın TTL süresi dolmamıştır. Bekleme süresinin nereden geldiğini DNS kayıt türleri ve yayılma süresi yazısında anlattık.
2. Ağacı yeniden sayın. Toplam 10'u geçmemeli, boş yanıt sıfır olmalı.
3. Her göndericiden, yani posta sunucusu, site formu, bülten ve fatura sisteminden, dışarıdaki bir adrese test postası gönderin. Başlıkta spf=pass ve beklediğiniz smtp.mailfrom değerini arayın.
4. Sonraki birkaç günün DMARC toplu raporlarında kendi IP'leriniz için SPF sonucunun pass olduğunu kontrol edin.

Değişiklikten önce eski kaydın tam metnini bir yere kaydedin. Yeni kayıtla beklenmedik bir gönderici geçmemeye başlarsa geri dönmek ve eksik girdiyi bulmak dakikalar sürer, tahmin yürütmek ise saatler.

Destek talebinde hangi bilgiler gerekir?

Kaydı kendiniz düzenleyemiyorsanız ya da permerror'un hangi alıcıda, hangi postada çıktığını çözemediyseniz destek ekibine şunları iletin: alan adı, dig +short TXT ile aldığınız güncel SPF kaydı, sorunlu bir postanın Authentication-Results ve Received-SPF satırları, sizin adınıza posta gönderen servislerin listesi ve kayıtta son yapılan değişikliğin tarihi. E-postanızı Netx'in Plesk panelli kurumsal hosting paketlerinden birinde tutuyorsanız bu bilgileri Netx müşteri panelinden açacağınız destek talebine ekleyin. Böylece Türkçe teknik destek ekibimiz aynı bilgileri sizden yeniden istemek zorunda kalmaz.