SPF 10 DNS Sorgu Limiti: Permerror Hatası ve Kalıcı Çözüm

Her yeni SaaS servisi için SPF kaydına bir include eklenir ve bir gün kayıt sessizce çöker: değerlendirme 10 DNS sorgusunu aşar, alıcı sunucular permerror döndürür. Kimse DNS’e dokunmamış gibi görünür, çünkü sorgu sayısını sağlayıcının kendi kaydındaki bir değişiklik artırmıştır. Bu rehber RFC 7208’deki sorgu ve void lookup sınırlarını, sayının nasıl hesaplanacağını ve include zincirinden doğan hatanın kalıcı çözüm yollarını anlatıyor.

SPF değerlendirmesi nasıl işler

Alıcı sunucu SPF’i kullanıcının gördüğü From başlığına göre değil, SMTP oturumundaki zarf göndericisine (MAIL FROM, başlıklarda Return-Path) göre değerlendirir. MAIL FROM boşsa (bounce iletileri) HELO/EHLO adı kullanılır. Sıra şöyledir:

1. MAIL FROM alan adının TXT kayıtları sorgulanır, v=spf1 ile başlayan kayıt seçilir. Birden fazla SPF kaydı varsa sonuç doğrudan permerror olur.
2. Mekanizmalar soldan sağa değerlendirilir; bağlantı kuran IP ilk eşleşen mekanizmada sonucunu alır (+ pass, - fail, ~ softfail, ? neutral).
3. Hiçbir mekanizma eşleşmezse ve redirect= varsa değerlendirme hedef alan adının kaydıyla sürer; yoksa sonuç neutral olur.

include:, hedef alan adının SPF kaydını ayrı bir değerlendirme olarak çalıştırır; hedefte pass çıkarsa include eşleşmiş sayılır. Gözden kaçan ayrıntı şu: include edilen alan adında SPF kaydı yoksa sonuç none değil, permerror olur. Sözleşmesi bitmiş ve alan adını kapatmış bir sağlayıcının include’u kaydınızın tamamını bozar. Tek satır, bütün kayıt.

10 sorgu ve void lookup limitleri

RFC 7208 bölüm 4.6.4, alıcının kaynak tüketimini sınırlamak için üç sınır koyar:

Sınır	Kapsam	Aşıldığında
10 DNS sorgusu	include, a, mx, ptr, exists, redirect (iç içe olanlar dahil)	permerror
Mekanizma başına 10 adres sorgusu	Bir mx veya ptr değerlendirmesinde dönen MX/PTR adları için A/AAAA sorguları	mx için permerror; ptr için ilk 10 dışındaki adlar yok sayılır
2 void lookup	Boş yanıt veya NXDOMAIN dönen sorgular (RFC “SHOULD” düzeyinde önerir)	permerror

ip4, ip6 ve all DNS sorgusu gerektirmez, sayılmaz. exp= değiştiricisi yalnızca fail durumunda açıklama metni için kullanılır ve sınıra girmez. Sorunun kaynağı, sınırın iç içe include’ları da kapsamasıdır. Kendi kaydınızda dört include görürsünüz; her biri kendi içinde başka include’lar çağırabilir ve o sayıyı DNS panelinde göremezsiniz.

Void lookup sınırını genellikle unutulmuş kayıtlar aşar: kaldırılmış bir sunucuyu gösteren a:eski-sunucu.example.com ya da artık var olmayan bir alan adına yapılan include. ptr mekanizmasını RFC 7208 açıkça önermez; yavaştır, güvenilmezdir. Kaydınızda varsa kaldırın.

Sorgu sayısının hesaplanması

Aşağıdaki örnek kayda bakalım (alan adları temsilidir):

example.com.  IN  TXT  "v=spf1 mx a include:spf.protection.outlook.com include:_spf.crm.example.net include:mail.pazarlama.example.net include:spf.fatura.example.net ip4:203.0.113.10 ~all"

Üst düzeyde 6 sorgu var: mx, a ve dört include. Sonra her include’un içeriğine ayrı ayrı inilir. Örnek hesapta CRM kaydı iki, pazarlama kaydı üç include daha çağırıyorsa (diğerlerinde ek sorgu olmadığı varsayımıyla) toplam 6 + 2 + 3 = 11 olur ve kayıt permerror üretir. Zinciri elle izlemek için tek tek sorgulayın:

dig +short TXT example.com | grep -i spf1
dig +short TXT _spf.crm.example.net
Resolve-DnsName -Name mail.pazarlama.example.net -Type TXT

Düzenli denetim için küçük bir betik daha pratiktir. Aşağıdaki Python örneği dnspython paketini kullanır, SPF zincirini yazdırır ve sayılan sorguları toplar; makro (%{i} gibi) içeren hedefleri sayar ama çözmeye çalışmaz:

import sys
import dns.resolver

def spf_kaydi(alan):
    for r in dns.resolver.resolve(alan, "TXT"):
        metin = b"".join(r.strings).decode()
        if metin.lower().startswith("v=spf1"):
            return metin
    raise ValueError(alan + ": SPF kaydı yok")

def say(alan, derinlik=0):
    kayit = spf_kaydi(alan)
    print("  " * derinlik + alan + " -> " + kayit)
    toplam = 0
    for terim in kayit.split()[1:]:
        t = terim.lstrip("+-~?").lower()
        if t.startswith(("include:", "redirect=")):
            hedef = t.split(":", 1)[1] if t.startswith("include:") else t.split("=", 1)[1]
            toplam += 1
            if "%" not in hedef:
                toplam += say(hedef, derinlik + 1)
        elif t in ("a", "mx", "ptr") or t.startswith(("a:", "a/", "mx:", "mx/", "ptr:", "exists:")):
            toplam += 1
    return toplam

print("Toplam sayılan DNS sorgusu:", say(sys.argv[1]))

Sonucu dış bir SPF doğrulama aracıyla karşılaştırın; iki farklı yöntemin aynı sayıyı vermesi iyi bir çapraz kontroldür. Sağlayıcıların kayıtları zamanla değişir; bugün 9 çıkan sayı birkaç ay sonra 11 olabilir. Ölçüm tek seferlik iş değildir. Takvime bağlayın.

Permerror’ın teslimata ve DMARC’a etkisi

Permerror alan sunucunun ne yapacağı yerel politikasına bağlıdır. Bazısı iletiyi reddeder, bazısı istenmeyen e-posta skorunu artırır, bazısı SPF sonucunu yok sayar. Belirtiler bu yüzden dağınık gelir: bir müşteriye fatura ulaşmaz, diğerine ulaşır. Destek ekibi önce kullanıcının posta kutusuna, sonra alıcının filtresine bakar; DNS en son akla gelir.

DMARC açısından permerror, SPF’in pass vermediği anlamına gelir. İleti From alan adıyla hizalı geçerli bir DKIM imzası taşıyorsa DMARC yine geçer; taşımıyorsa DMARC başarısız olur ve p=quarantine veya p=reject politikası uygulanır. DMARC’ı zorlama seviyesine taşıyan kurumlarda permerror bu yüzden çok daha görünür sonuç doğurur. Aggregate raporlarda SPF sonucunda permerror görüyorsanız sorunu zaten yaşıyorsunuz. Politika geçişinin genel planı için DMARC’ta p=none’dan p=reject’e geçiş rehberine bakın.

Çözüm seçenekleri karşılaştırması

Çözüme başlamadan önce tek soru: bu include gerçekten gerekli mi? SPF, MAIL FROM alan adına göre değerlendirilir. Bir pazarlama servisi iletileri kendi bounce alan adıyla gönderiyorsa, sizin kaydınızdaki include o servisin SPF sonucunu hiç etkilemez; yalnızca sorgu bütçenizi yer. Sahada denetlenen kayıtlarda bu tür include sık çıkar. Servisten gelen gerçek bir iletinin başlığındaki Return-Path değeri soruyu cevaplar.

Yöntem	Ne zaman uygun	Sınırlama
Gereksiz include temizliği	Kullanılmayan veya kendi Return-Path’ini kullanan servisler	Envanter ve başlık kontrolü gerektirir
a/mx yerine ip4/ip6	Kendi sabit IP’li sunucularınız	IP değişikliğinde kaydın güncellenmesi gerekir
Alt alan adına ayırma	Servis özel Return-Path destekliyorsa (ör. bounce.example.com)	Her alt alan adının SPF’i ayrı yönetilir
Elle düzleştirme	IP aralığı nadiren değişen küçük servisler	Sağlayıcı değişikliğini fark etmezseniz kayıt eskir
Otomatik düzleştirme / makro servisleri	Çok sayıda servis, sık değişen aralıklar	SPF’iniz üçüncü bir servise bağımlı hale gelir

Çoğu kurumda en temiz çözüm alt alan adına ayırmaktır. Pazarlama servisi bounce.example.com gibi bir alt alan adını Return-Path olarak kullandığında SPF o alt alan adının kendi kaydına göre değerlendirilir; ana kaydın bütçesine dokunmaz. DMARC relaxed hizalamada (aspf=r) alt alan adı ana alan adıyla hizalı sayıldığı için DMARC da geçer:

example.com.         IN  TXT  "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ~all"
bounce.example.com.  IN  TXT  "v=spf1 include:mail.pazarlama.example.net -all"

Bir ayrıntı daha: tek bir TXT dizesi 255 karakteri aşamaz. Uzun kayıtlar tırnaklı birden çok dizeye bölünür ve alıcı bunları araya boşluk koymadan birleştirir. Bölme noktasında boşluk bırakmazsanız iki mekanizma birbirine yapışır ve yeni bir hata doğar.

~all ve -all tercihi

-all (fail), listede olmayan kaynakların yetkisiz olduğunu kesin olarak bildirir; ~all (softfail) “büyük olasılıkla yetkisiz” der. DMARC uygulanmayan ortamlarda bu fark belirleyiciydi. DMARC zorlama düzeyindeyken nihai kararı DMARC verdiği için fark daralır, ama bir yan etki kalır: bazı alıcılar SPF fail gördüğünde DMARC’a geçmeden iletiyi reddeder. Yönlendirilmiş ve DKIM imzası sağlam meşru bir ileti de böyle kaybolur; RFC 7489 bölüm 10.1 bu riski açıkça anar.

Pratik yaklaşım: e-posta gönderen alan adlarında DMARC p=reject ile birlikte ~all, hiç e-posta göndermeyen alan adlarında v=spf1 -all. Hangisini seçerseniz seçin +all veya ?all kullanmayın. İlki herkesi yetkilendirir. İkincisi SPF’i bir kurumsal siber güvenlik kontrolü olarak işlevsiz bırakır.

SPF bakım kontrol listesi

• Alan adı başına tek bir v=spf1 kaydı olduğunu doğrulayın.
• İç içe dahil toplam sorgu sayısını ölçün; 10’a yaklaşan kayıtlarda yeni servis eklemeden önce yer açın.
• Her include için sahip birimi ve servisin Return-Path davranışını kayda geçirin.
• Kendi Return-Path’ini kullanan servislerin include’larını kaldırın.
• NXDOMAIN veya boş yanıt dönen a:, mx: ve include hedeflerini temizleyin.
• ptr mekanizmasını kaldırın.
• Sözleşmesi biten servislerin include ve DKIM kayıtlarını aynı değişiklikte silin.
• DMARC raporlarında SPF permerror ve temperror sonuçlarını haftalık izleyin.
• Düzleştirilmiş kayıtlar için sağlayıcının IP aralığı duyurularını takip edecek bir sorumlu atayın.

Kullanıcıdan gelen tek bir şüpheli iletide SPF sonucunu yorumlamak için şüpheli e-posta başlık analizi rehberindeki Authentication-Results bölümüne bakın. Protokolün başvuru metni RFC 7208’dir. Birden çok alan adı ve çok sayıda gönderim servisi olan yapılarda kayıtların toplu denetimi e-posta güvenliği ve kimlik avı koruması çalışmasının parçası olarak ele alınabilir.

Sık sorulan sorular

ip4 ve ip6 mekanizmaları 10 sorgu limitine dahil mi?

Hayır. ip4, ip6 ve all DNS sorgusu gerektirmez, limite sayılmaz. Sayılanlar include, a, mx, ptr, exists mekanizmaları ve redirect değiştiricisidir. Include edilen kayıtların içindeki bu terimler de toplama eklenir.

Bir servisin include kaydını SPF’ten çıkarırsam e-postaları etkilenir mi?

Servis iletileri kendi bounce alan adıyla, yani kendi Return-Path’iyle gönderiyorsa SPF onun kaydına göre değerlendirilir; include’u çıkarmak teslimatı etkilemez. Return-Path sizin alan adınızsa include gereklidir. Karar vermeden önce servisten gelen gerçek bir iletinin başlığında Return-Path değerine bakın.

SPF düzleştirme (flattening) güvenli mi?

Teknik olarak geçerlidir. Ama sağlayıcı IP aralığını değiştirdiğinde kaydınız eskir ve meşru e-postalar SPF’ten kalır. Elle düzleştirme yalnızca aralığı seyrek değişen ve değişikliği duyuran servislere uygundur. Otomatik düzleştirmede DNS kaydınızı bir araç günceller; o aracın güvenilirliğine bağımlı hale gelirsiniz.

Permerror varken DMARC yine de geçebilir mi?

Evet. DMARC için hizalı SPF veya hizalı DKIM sonuçlarından birinin pass olması yeterlidir. SPF permerror verse de ileti From alan adıyla hizalı geçerli bir DKIM imzası taşıyorsa DMARC geçer. Bu yüzden permerror bazen aylarca fark edilmez ve yalnızca DKIM imzalamayan kaynaklarda teslimat sorunu olarak ortaya çıkar.