SPF 10 DNS lookup limiti ne demektir?
SPF (Sender Policy Framework), bir alan adından (domain) e-posta gönderme yetkisi olan IP adreslerini ve gönderim kaynaklarını DNS üzerinde tanımlamanızı sağlar. Alıcı posta sunucusu, bir mesajın zarf gönderen (envelope-from) alan adı için SPF kontrolü yaptığında DNS’teki SPF kaydını okur ve bu kaydın işaret ettiği kaynakları doğrulamak için çeşitli DNS sorguları yapar.
SPF’nin kritik bir kuralı vardır: SPF değerlendirmesi sırasında en fazla 10 adet DNS lookup (DNS sorgusu) yapılabilir. Bu limit, “SPF policy evaluation” sırasında yapılan belirli türdeki sorguları kapsar ve aşıldığında SPF sonucu genellikle PermError (kalıcı hata) olur. PermError, alıcı sistemin SPF’i güvenle değerlendiremediği anlamına gelir ve teslim edilebilirliği olumsuz etkileyebilir; bazı sistemler mesajı reddedebilir, bazıları spam puanını yükseltebilir.
Bu konu, özellikle birden fazla SaaS aracıyla (CRM, helpdesk, pazarlama otomasyonu, fatura sistemi gibi) e-posta gönderen işletmelerde sık görülür. Her yeni gönderim aracı, SPF kaydına yeni bir include eklenmesine yol açabilir ve include zinciri büyüdükçe 10 sorgu limiti aşılabilir.
Hangi SPF mekanizmaları DNS sorgusu sayılır?
SPF kaydında her ifade (mekanizma) aynı maliyete sahip değildir. 10 lookup limitine dahil olan başlıca mekanizmalar şunlardır:
- include: Başka bir domainin SPF kaydını içeri alır. Her include en az bir DNS sorgusu demektir ve include edilen kaydın içinde başka include’lar varsa toplam sorgu sayısı hızla artar.
- a ve mx: Domainin A kaydını veya MX kayıtlarını çözümler. Her biri lookup tüketebilir.
- exists: Koşullu kontrol için DNS sorgusu yaptırır, lookup tüketir.
- redirect=: SPF değerlendirmesini başka bir domaine yönlendirir, lookup tüketir.
Öte yandan ip4 ve ip6 gibi mekanizmalar doğrudan IP aralıkları içerdiği için lookup tüketmez. Bu yüzden sadeleştirme çalışmalarında çoğu zaman hedef, include’ları azaltıp mümkün olduğunca ip4/ip6 ile netleştirmektir.
Limit aşıldığında ne olur? Tipik belirtiler
10 DNS sorgu limiti aşıldığında SPF değerlendirmesi sağlıklı tamamlanamaz. Bu durumun pratikteki belirtileri şunlar olabilir:
- Alıcı sistemin loglarında veya bounce mesajlarında SPF ile ilgili PermError ifadeleri
- “Too many DNS lookups” ya da benzeri hata açıklamaları
- Bazı alıcılarda normal teslim, bazı alıcılarda spam/ret gibi tutarsız sonuçlar
- Yeni eklenen bir gönderim kaynağından sonra aniden teslim edilebilirlik düşüşü
Bu noktada sorun “SPF yanlış” olmaktan çok “SPF doğrulanamıyor” haline gelir. Dolayısıyla çözüm, SPF kaydını teknik limitler içinde yeniden düzenlemektir.
include zinciri neden kontrolden çıkar?
İşletmeler genellikle SPF kaydını zaman içinde “ekleyerek” büyütür. Örneğin pazarlama aracı bir include ister, destek sistemi bir include ister, bulut ofis servisi bir include ister. Ayrıca bu servislerin kendi SPF kayıtları da başka domainleri include edebilir. Böylece siz yalnızca 3-4 include eklediğinizi sanırken, arka planda 12-15 sorguya çıkan bir zincir oluşabilir.
Bazı yaygın hatalı yaklaşımlar:
- Aynı servis için birden fazla include eklemek (dokümantasyon farklı zamanlarda değiştiyse)
- Eski servisleri kaldırmamak (kullanılmayan include’lar)
- “mx” veya “a” mekanizmalarını gereksiz yere eklemek
- Birden fazla SPF TXT kaydı oluşturmak (SPF için tek TXT kaydı olmalıdır; birden fazlası sonuçları bozabilir)
SPF kaydı denetimi: Adım adım pratik kontrol
1) Gönderim kaynaklarını envanterleyin
Önce organizasyonunuzun hangi sistemlerden dışarı e-posta gönderdiğini listeleyin. Bu liste genellikle şunları içerir: kullanıcıların SMTP submission ile gönderimleri, uygulama sunucuları, pazarlama platformları, helpdesk/ticket sistemi, çok işlevli yazıcılar, izleme sistemleri.
Hedef: “Gerçekte kullanılan” kaynakları belirlemek. Kullanılmayan kaynakları SPF’ten çıkarmak çoğu zaman en hızlı kazançtır.
2) SPF kaydındaki mekanizmaları okuyun
SPF kaydı genellikle “v=spf1 … -all” biçimindedir. Burada yer alan her include, a, mx, exists ve redirect öğesini not alın. En sonda kullanılan nitelendirici de önemlidir:
- -all: Yetkisiz kaynakları fail ile işaretler (daha katı)
- ~all: Softfail üretir (daha toleranslı)
Bu yazı “hangi -all daha iyi” tartışmasına odaklanmıyor; asıl amaç, kaydın çalışabilir sınırlar içinde olmasıdır.
3) Lookup bütçesini hesaplayın
Sadece sizin SPF kaydınızdaki include sayısı değil, include edilen domainlerin SPF içerikleri de lookup tüketir. Bu nedenle gerçek bütçe, zincirin toplamıdır. Zinciri çözümlemeden “bizde 7 include var, sorun yok” demek yanıltıcı olabilir.
SPF flattening nedir ve ne zaman düşünülmelidir?
SPF flattening, include edilen SPF politikalarını çözümleyip (resolve) ortaya çıkan IP aralıklarını doğrudan kendi SPF kaydınıza yazma yaklaşımıdır. Amaç, lookup tüketen include’ları azaltıp daha çok ip4/ip6 mekanizması kullanarak 10 lookup limitinin altında kalmaktır.
Flattening şu durumlarda gündeme gelir:
- 10 lookup limitine yaklaşılıyor veya aşılıyorsa
- Birden fazla gönderim hizmeti zorunluysa ve include sayısını düşürmek mümkün değilse
- Belirli alıcılarda PermError kaynaklı teslim sorunları yaşanıyorsa
Ancak flattening sihirli bir çözüm değildir. Dikkat edilmesi gereken önemli riskler vardır.
Flattening’in artıları
- Lookup sayısı düşer, SPF PermError riski azalır
- SPF değerlendirmesi daha deterministik hale gelir
- Gereksiz include zincirlerinden kaynaklanan belirsizlikler azalır
Flattening’in eksileri ve operasyonel riskleri
- Servis sağlayıcının IP aralıkları değiştiğinde sizin SPF kaydınız güncel kalmayabilir
- Yanlış veya eksik IP eklemek, meşru e-postaların SPF fail almasına neden olabilir
- SPF TXT kaydı çok uzayabilir (DNS TXT uzunluğu ve parçalama sınırlarına dikkat etmek gerekir)
Bu nedenle flattening, “bir kere yaptım bitti” değil; düzenli takip gerektiren bir idari süreçtir.
Flattening yapmadan önce denenebilecek daha basit çözümler
Bazı durumlarda flattening’e gerek kalmadan da lookup sayısını düşürmek mümkündür:
- Kullanılmayan include’ları kaldırın: Eski pazarlama araçları, eski ticket sistemleri veya artık kullanılmayan gateway’ler SPF’te kalmış olabilir.
- Aynı sağlayıcıyı tekrar tekrar include etmeyin: Dokümanlar farklı alt domainler önerse bile çoğu zaman tek include yeterlidir.
- mx/a kullanımını sorgulayın: “mx” mekanizması her zaman gerekli değildir; sadece MX’ten gönderim yapılıyorsa anlamlıdır.
- Gönderim domainini ayrıştırın: Pazarlama gönderimleri için ayrı bir alt alan adı kullanmak, ana domain SPF’ini sadeleştirir. Bu strateji, marka ve teslim edilebilirlik yönetiminde de yardımcı olabilir.
Güncelleme ve değişiklik yönetimi: Kesintisiz ilerlemek için
SPF değişiklikleri DNS üzerinden yayıldığı için zaman alabilir. Değişiklik yaparken şu pratikleri uygulayın:
- DNS TTL planlaması: Büyük değişiklik öncesi TTL’i makul bir süreye indirip, değişiklik sonrası tekrar yükseltmek geçişi yönetilebilir kılar.
- Aşamalı doğrulama: Kritik gönderim kaynaklarını tek tek test ederek ilerleyin; bir anda çok büyük değişiklikler yapmak hata ayıklamayı zorlaştırır.
- Dokümantasyon: SPF kaydında her include veya IP’nin hangi sistem için eklendiğini iç süreçlerde kaydedin.
SPF ile DMARC/DKIM ilişkisi: Tek başına düşünmeyin
SPF, gönderim kimlik doğrulamasının yalnızca bir parçasıdır. DMARC politikaları uygulanıyorsa SPF’in “geçmesi” kadar SPF hizalaması (alignment) ve DKIM’in durumu da önem kazanır. SPF PermError yaşandığında, DKIM imzası doğru ve hizalıysa DMARC değerlendirmesi bazı senaryolarda yine de başarılı olabilir. Bu yüzden SPF’i iyileştirirken DKIM/DMARC bütünlüğünü de göz önünde bulundurmak gerekir.
Son kontrol listesi
- Tek bir SPF TXT kaydı kullanılıyor mu?
- Kullanılmayan include/a/mx/exists öğeleri kaldırıldı mı?
- Toplam DNS lookup sayısı 10’un altında mı?
- Güncelleme sonrası kritik gönderim akışları test edildi mi?
- Değişiklikler iç dokümantasyona işlendi mi?
MX1Mail ile pratik yaklaşım
Birçok işletmede SPF sorunları, tek bir ayardan çok “zamanla biriken karmaşıklık” nedeniyle ortaya çıkar. E-posta altyapınızı yönetirken gönderim kaynaklarını netleştirmek, DNS değişikliklerini kontrollü yapmak ve kimlik doğrulama kayıtlarını düzenli gözden geçirmek teslim edilebilirliği korumaya yardımcı olur. MX1Mail gibi kurumsal e-posta hizmetleri kullanırken de domaininizin SPF/DKIM/DMARC yapılandırmalarını periyodik olarak denetlemek, yeni eklenen uygulamaların SPF lookup limitini aşmasına engel olacak şekilde değişiklik yönetimi yapmak iyi bir rutin oluşturur.