Check-Host.cc

Global SPF Doğrulama Kontrol Aracı

Sender Policy Framework (SPF), yetkili gönderen IP adreslerinin kriptografik bir beyaz listesini (whitelist) yayınlayarak alan adı sahtekarlığını (spoofing) önleyen kritik bir e-posta kimlik doğrulama protokolüdür. SPF protokolünün kendisi modern teslim edilebilirlik (deliverability) için gerekli olsa da, özel SPF DNS kayıt türü (Type 99) inanılmaz derecede karmaşık bir geçmişe sahiptir ve resmi olarak kullanımdan kaldırılmıştır.

Record Type 99'un Yükselişi ve Düşüşü

SPF protokolü ilk olarak kavramsallaştırıldığında (RFC 4408), IETF, SPF Payload'larını standart TXT verilerinden izole etmek için açıkça tasarlanmış belirli bir DNS kaynak kaydı (Type 99) tasarladı. Teori, özel bir kayıt türü tutmanın resolver ayrıştırmasını (parsing) hızlandıracağı yönündeydi. Ancak, kullanıma sunma devasa bir başarısızlıktı. Eski (legacy) DNS sunucuları, güvenlik duvarları ve donanım Load Balancer'ları yeni Type 99 sözdizimini (syntax) tanımadı ve sıklıkla paketleri düşürerek yaygın e-posta kesintilerine neden oldu. Bu donanım uyumsuzluğunu kabul eden IETF, Type 99 kaydını resmen kullanımdan kaldıran RFC 7208'i yayınladı. Günümüzde, tüm SPF yapılandırmaları standart TXT kayıtları olarak yayınlanmalıdır. Bir yönetici eski bir Type 99 SPF kaydını dağıtmaya devam ederse, Microsoft Exchange ve Google Workspace gibi modern platformlar bunu tamamen görmezden gelecek ve bu da anında DMARC hatalarına yol açacaktır.

Mekanik 10-Lookup Sınırı

SPF'yi yöneten geliştiriciler için en belirgin teknik hata noktası, katı 10-lookup sınırıdır. Bir SPF kaydı yöneticilerin include: yönergesini (örneğin, include:_spf.salesforce.com) kullanarak diğer alan adı politikalarını iç içe yerleştirmesine (nest) izin verdiğinden, alan bir posta sunucusu bu üçüncü taraf sağlayıcıdan IP'leri getirmek için özyinelemeli (recursive) bir DNS sorgusu gerçekleştirmelidir. MTA'ları sonsuz routing döngülerinden ve hedeflenmiş DDoS Amplification saldırılarından korumak için, protokol yürütmeyi 10 özyinelemeli DNS lookup'ında sınırlar (hard-cap). Bir şirket çok fazla SaaS sağlayıcısını birbirine zincirler ve 11 lookup'a ulaşırsa, yürütme durur ve bir SPF "PermError" döndürür. Bu, yasal giden e-postaların anında hard-bounce olmasına veya karantinaya düşmesine neden olur.

Flattening ve Teşhis

Arama sınırlamalarını atlamak için ağ mühendisleri "SPF Flattening" araçlarını kullanır. Bu komut dosyaları saatlik olarak çalışır, tüm include: yönergelerini API aracılığıyla genişletir, host adlarını soyar ve ham IPv4/IPv6 bloklarını devasa, düz (flat) bir TXT kaydında derler. Global bir teşhis kontrol aracı kullanmak, sözdiziminizin geçerli olmasını, iç içe geçmiş (nested) include'larınızın sessizce DNS eşiğini aşmamasını ve politikanızın taklit edilmiş Payload'ları reddetmek için kısıtlayıcı bir -all (fail) veya ~all (softfail) bayrağıyla açıkça sonlandırılmasını sağlar.