SPF 10 Lookup Limiti Nedir? Nasıl Aşılmaz?

SPF kaydınız sözdizimi hatası içermiyor, DKIM imzası yerli yerinde, DMARC politikası yapılandırılmış — ama bazı gönderim senaryolarında e-postalar spam klasörüne düşüyor ya da doğrudan reddediliyor. Gelen header'lara ya da DMARC raporlarına bakıyorsunuz; "pass" yerine "permerror" yazıyor. Bu, sessiz ve sinir bozucu bir hata türü. Kaydın yapısında değil, kaydın alıcı sunucu tarafından nasıl değerlendirildiğinde gizleniyor.

SPF doğrulama sırasında alıcı sunucu, SPF kaydınızın işaret ettiği tüm mekanizmaları çözmek için arka arkaya DNS sorguları gönderir. RFC 7208, bu sorgu sayısını 10 ile sınırlandırır. Bu limit kasıtlı bir kısıtlama değil, hizmet reddi saldırılarına ve sonsuz referans döngülerine karşı tanımlanmış zorunlu bir mekanizma. Fakat büyüyen e-posta altyapılarında — birden fazla gönderim servisi kullanan firmalarda, pazarlama araçları ve CRM entegrasyonları eklendikçe — bu limit farkında olmadan aşılabiliyor.

SPF kaydı nasıl oluşturulur ve hata nasıl kontrol edilir soruları ayrı bir yazının konusu. Burada o temelden yola çıkarak farklı bir durumu ele alıyoruz: kaydınız var, işliyor, ama gönderim servisleriniz çoğaldıkça 10 sınırının neresinde olduğunuzu bilmiyorsunuz ve bu belirsizlik zaman zaman teslimatta sessiz hasara dönüşüyor.

RFC 7208 ve 10 Lookup Kuralının Kökeni

RFC 7208, SPF standardını tanımlayan teknik belge. Bu belgede DNS lookup sınırı şöyle gerekçeleniyor: bir SPF kaydı başka kayıtlara referans verebilir (include), o kayıtlar da başkalarına — zincirleme DNS sorguları başlar. Sınır olmadan, kötü niyetli bir aktör özenle hazırlanmış bir SPF kaydıyla alıcı sunucuyu onlarca DNS sorgusuna zorlayabilir. Bu "DNS kaynak tüketimi" vektörü, standart koyucuların 10 sayısını sabit olarak tanımlamasının arkasındaki esas neden.

10 sınırı, RFC 7208 bölüm 4.6.4'te açıkça şöyle tanımlanır: include, a, mx, ptr ve exists mekanizmaları ile redirect modifier'ı için yapılan DNS aramalarının toplam sayısı, SPF değerlendirmesinin tamamı boyunca 10'u aşamaz. Yalnızca kök kaydınızdaki mekanizmaları değil, her include zincirinin derinliklerindeki mekanizmaları da kapsayan birikimli bir sayaç bu. Kaydınızın ilk bakışta sadece birkaç include içermesi yanıltıcı olabilir; bu include'ların kendi içleri de sayaca katkıda bulunur.

10 rakamının kendisi biraz keyfi görünebilir — neden 15 ya da 20 değil? SPF standardı yayımlandığı dönemde e-posta altyapıları bugünkü kadar dağınık ve SaaS-ağırlıklı değildi. Bir mail server, bir bulut yedekleme, belki bir CRM — 10 yeterliydi. Ancak her servisin kendi include zinciriyle geldiği günümüz altyapılarında bu sınır sıkışık hale geldi. Standart güncellenmediği için 10 sayısı, etrafından dolaşılmaya çalışılan değişmez bir kısıt olarak kalıyor.

Hangi Mekanizmalar Lookup Sayar, Hangileri Saymaz?

SPF sözdizimini mekanizma ve modifier olarak ayırmak, maliyeti anlamanın ilk adımı. Her ikisi de SPF kaydında yer alır, ama DNS lookup açısından birbirinden çok farklı davranır.

Lookup sayan mekanizmalar şunlardır: include:domain.com her kullanımda sayaca 1 ekler — include'un hedef domain'i başka include'lar içeriyorsa, onlar da kümülatife eklenir. a ve a:domain.com, domain'in A ve AAAA kaydını çözmek için 1 lookup kullanır. mx ve mx:domain.com ise önce MX kaydını sorgular (1 lookup), ardından her MX host'u için ayrı A sorguları gönderir — üç MX sunucunuz varsa bu mekanizmadan tek başına 4 lookup çıkar. ptr:domain.com mekanizması hem yavaş hem maliyetlidir; RFC 7208 bu mekanizmanın kullanımını açıkça önermez. exists:domain.com 1 lookup sayar. redirect=domain.com modifier'ı, hedef domain'in SPF kaydını çözmek için 1 lookup kullanır ve ardından o kayıttaki tüm mekanizmalar kümülatife eklenir.

Lookup saymayan mekanizmalar ise şunlardır: ip4:192.0.2.0/24 ve ip6:2001:db8::/32 doğrudan IP aralıkları tanımlar; DNS sorgusu gerekmez, maliyetsizdir. all mekanizması hangi qualifier ile yazılırsa yazılsın (+all, -all, ~all, ?all) yalnızca bir sonlandırıcı görevindedir ve sayaca hiçbir şey eklemez. v=spf1 direktifi de herhangi bir maliyeti olmayan başlık unsurudur.

Bu ayrım pratikte belirleyici. Bazı gönderim servisleri SPF entegrasyonlarını include yerine ip4 aralıklarıyla sunar — bu, lookup maliyeti sıfır demektir. Ama büyük çoğunluk include:_spf.servis.com biçimini kullanır ve bu her defasında sayaca en az 1, genellikle 2-4 ekler. "Bir include ekledim, sorun ne ki" sorusunun cevabı burada: o include'un arkasındaki zincir görünmez ama sayılır.

Mevcut SPF Kaydındaki Toplam Lookup Sayısını Hesaplama

Bir domain'in toplam SPF lookup sayısını hesaplamak için yalnızca kendi TXT kaydına bakmak yeterli değil. Tüm include zincirini uçtan uca açmak gerekiyor. Aşağıdaki kaydı düşünün — birden fazla SaaS platformunu entegre etmiş, orta ölçekli bir şirket için tipik bir görünüm:

v=spf1 include:_spf.google.com include:mailgun.org include:sendgrid.net include:servers.mcsv.net include:mail.zendesk.com ~all

Bu kayıtta görünen 5 include, başlangıç noktası — her biri sayaca 1 ekler. Ama her include'un kendi içinde de mekanizmalar var. _spf.google.com genellikle 2-3 alt include veya a mekanizması içerir. mailgun.org'un SPF kaydı 2-3 katman derine gidebilir. sendgrid.net ve servers.mcsv.net (Mailchimp) da benzer derinlikte. mail.zendesk.com ise başka sağlayıcı zincirlerine açılabilir. 5 doğrudan lookup ile başlayan bu kayıt, zincirin tamamı açıldığında 14-18 toplam sorguya kolayca ulaşır — sınırın çok üstü.

Manuel hesaplama için sırayla şunu yapabilirsiniz: önce kendi TXT kaydınızı sorgulayın, her include'un TXT kaydını ayrı ayrı alın, içlerindeki mekanizmaları açın, her biri için sayaca ekleyin.

dig TXT example.com +short
dig TXT _spf.google.com +short
dig TXT mailgun.org +short
dig TXT sendgrid.net +short
dig TXT servers.mcsv.net +short

Bu süreci elle yapmak 5-6 include içeren kayıtlarda bile yorucu hale gelir; her satırın içini açıyorsunuz, o satırların içini açıyorsunuz. Daha pratik yol: mxtoolbox.com/spf.aspx veya dmarcian.com/spf-survey gibi araçlar SPF zincirini otomatik açar, her adımdaki lookup maliyetini ayrıştırır ve toplam sayıyı gösterir. Bu araçlar RFC 7208 mantığını doğru biçimde uygular.

Hesaplama sırasında dikkat edilmesi gereken bir ayrıntı var: aynı domain iki farklı include zinciri üzerinden erişilse bile, her geçiş ayrı bir lookup olarak sayılır. Optimizasyona başlamadan önce zincirlerin kesiştiği noktaları bulmak ve tekrar eden referansları tespit etmek bu yüzden işe yarar.

Limit Aşıldığında Ne Olur? PermError ve Teslimat Sonuçları

SPF değerlendirmesi 10 lookup sınırını aştığında alıcı sunucu permerror döner. RFC 7208 bölüm 8, bu durumu kalıcı hata (permanent error) olarak tanımlar — geçici bir sorun değildir, yeniden deneme yapılmaz. "pass" da değil, "fail" da değil; başarısız bir değerlendirme, tamamlanamayan bir süreç.

Bir sonraki adımda ne olacağı DMARC politikanıza ve alıcı sunucunun yapılandırmasına bağlı. DMARC politikası none ise permerror çoğunlukla görmezden gelinir, teslimat devam eder — ama spam filtresi bu sinyali negatif puanlamada kullanabilir, özellikle başka şüpheli sinyallerle birleşince. DMARC politikası quarantine ise mesaj spam veya junk klasörüne yönlendirilir; açılma oranlarınız düşer ama bunu fark etmek zaman alabilir. DMARC politikası reject ise permerror doğrudan red sonucuna yol açabilir, özellikle alıcı taraf katı DMARC yorumu yapıyorsa.

Karmaşıklaştıran bir katman daha var: DMARC, SPF veya DKIM'den birinin alignment sağlamasıyla "pass" üretebilir. DKIM imzanız sağlıklıysa ve alıcı sunucu DKIM alignment'a dayanarak DMARC'ı geçiriyorsa, SPF permerror'u maskelenir. Bu, durumu "görünüşte sorun yok, aslında var" kategorisine sokar. DMARC raporları düzenli takip ediliyorsa, XML raporlarındaki spf=permerror satırları hata kaynağını açık biçimde gösterir — ve hangi alıcı sunucularda sorun çıktığını da.

Lookup Sayısını Düşürme Teknikleri

Limiti yönetmenin iki temel yolu var: gereksiz mekanizmaları kaldırmak ve include zincirini kırarak doğrudan IP aralıklarıyla eşleme yapmak. Çoğu durumda ikisi birlikte uygulanır.

İlk ve en kolay adım kullanılmayan servislerin include'larını temizlemek. Artık e-posta göndermediğiniz servis SPF kaydında hâlâ yaşıyor olabilir. CRM ya da pazarlama aracı değiştirildiğinde eski servisin kaydı temizlemek sık atlanan bir adımdır; çünkü e-postalar çalışmaya devam eder — sadece gereksiz lookup taşırsınız. Her include en az 1, içerdeki zincire göre 2-4 lookup maliyeti taşır. Temizlik her zaman burada başlar.

mx mekanizması kullanışlı görünür ama maliyetlidir. Domain'inizin MX sunucularından posta gönderiyorsanız, o sunucuların IP adreslerini doğrudan ip4: bloğuyla eklemek lookup sayısını belirgin biçimde düşürür. MX kaydınız değiştiğinde SPF kaydını da güncellemeniz gerektiğini kabul etmek bu trade-off'un bedeli; büyük altyapılarda lookup tasarrufu bu bedele değer.

SPF flattening ise daha köklü bir yaklaşım: tüm include zincirini sonuna kadar çözerek her birinin işaret ettiği IP aralıklarını doğrudan ip4: ve ip6: olarak listeleyen tek bir kayıt oluşturmak. Bu yaklaşımda include kalmaz; lookup sayısı yalnızca kendi TXT kaydınızı sorgulamak için 1'e düşer.

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:66.249.80.0/20 ip4:149.72.0.0/16 ip4:185.166.140.0/22 ip4:198.61.254.0/23 -all

Bu kaydın temel dezavantajı bakım yükü. Google, Mailgun, SendGrid gibi servisler zaman zaman yeni IP blokları ekler ya da mevcutları değiştirir. Flatten kaydınız güncel kalmazsa, yeni IP aralıklarından gönderilen mesajlar fail alır. Bu, include zincirine göre tam tersi bir hata modu: lookup sorunu yok, ama kapsam eksikliği var. Ayrıca bazı sağlayıcılar IP değişikliklerini önceden duyurmaz; fark etmek için teslimatta düşüş görmek gerekebilir.

TXT kaydı yönetimi gönderim altyapısı büyüdükçe karmaşıklaşır. Flat bir SPF kaydı, sözdizimsel olarak sade görünse de içindeki IP listesinin doğruluğundan siz sorumlusunuz — bu sorumluluk servis sayısıyla birlikte büyür.

SPF Flattening Servisleri ve Sürdürülebilir Yönetim

IP aralıklarının elle takibini devralan araçlar "SPF flatten servisi" olarak anılır. Bu servisler düzenli aralıklarla include zincirlerini çözüp güncel IP listesini derler; kaydınızda servisin kendi sunucusuna işaret eden tek bir include kalır, ama bu include'un arkasında otomatik güncellenen dinamik bir flat liste vardır. Lookup sayısı düşük tutulurken IP değişikliklerinin takibi servise devredilmiş olur.

Bu yaklaşım kendi değiş tokuşlarını getiriyor. Flatten servisi bir üçüncü tarafa bağımlılık yaratır; servis kesintisi veya gecikmeli güncelleme doğrudan teslimata yansır. Ayrıca servisin kullandığı include adresi yeni bir lookup maliyeti taşır — flat listenin kendisi 0 maliyet olsa da o listeye ulaşmak için hâlâ bir sorgu yapılır. Bununla birlikte, onlarca IP aralığını elle yönetmek yerine bu yapıyı tercih etmek büyük altyapılarda makul bir karar.

Flatten servisine geçmeden önce kaydın boyutunu da gözetmek gerekir. DNS TXT kaydı tek bir string için 255 karakter sınırına sahip; birden fazla string zinciri çoğu DNS sunucusu tarafından desteklenir ve daha büyük payload'lar taşıyabilir. Onlarca IP aralığı içeren flatten kayıtlarda bu sınırı izlemek önem kazanır — lookup sayısı düşerken kayıt boyutu artar.

Flatten'a geçmek yerine belirli include'ları korumayı tercih ediyorsanız, 10 sınırının altında güvenli bir tampon bırakmak iyi pratik. 8-9 lookup sınıra çok yakın; herhangi bir sağlayıcı kendi SPF kaydını sessizce genişletirse limiti geçebilirsiniz. 5-6 arası daha güvenli bölge. Alt domain bazlı gönderim senaryolarında her subdomain kendi SPF kaydını taşır ve limit her domain için bağımsız sayılır — yükü parçalara ayırmanın pratik bir yolu olabilir, ama her subdomain'i ayrı ayrı yönetmek de yükü artırır.

Periyodik SPF kontrolü — özellikle yeni bir gönderim servisi entegre etmeden önce mevcut durumu ölçmek — birikim sorununu erken yakalamanın en basit yolu. Yeni bir include eklendiğinde toplam lookup sayısını yeniden hesaplamayı bir alışkanlık haline getirmek, sınırın sürpriz bir engel olmasını önler. DKIM kaydı ve DMARC sağlıklı çalışıyor olsa bile SPF'in permerror verdiğini, çoğunlukla ancak raporlar okunduğunda fark ediyorsunuz — bu yüzden DMARC raporlamasını aktif tutmak SPF sorunlarını da görünür kılar.

E-posta altyapısı büyüdükçe SPF kaydı da genişler — çoğunlukla plansız. Her yeni araç bir include daha ekler, bu birikimin sınırı ne zaman zorladığını teslimatta sorun başlayana kadar fark etmiyorsunuz. Lookup sayacı sessizce dolar; PermError sessizce üretilir; bazı mesajlar sessizce kaybolur. SPF 10 limitini yönetmenin özü, bu sessizliği rutin ölçümle kırmaktan geçiyor.