SPF Kaydı Oluşturma: Yetkili Gönderici ve Hata Kontrolü

SPF kaydı, bir alan adı adına hangi sunucuların e-posta göndermeye yetkili olduğunu tanımlar. E-posta tesliminde görünen birçok sorun, aslında yanlış SPF kaydı, birden fazla SPF kaydı veya taşınmış altyapıya rağmen güncellenmemiş yetki listesi nedeniyle ortaya çıkar. Bu yüzden SPF kaydı yalnızca teknik bir ayrıntı değil, doğrudan teslimat kalitesini etkileyen temel DNS bileşenlerinden biridir.

Bir domaine yeni e-posta servisi bağlandığında, eski sağlayıcı kalıntıları temizlenmeden ek kayıt bırakılması sık rastlanan problemdir. Sonuçta alıcı sunucular hangi kaydın geçerli olduğunu net yorumlayamaz, iletiler spam klasörüne düşebilir veya kimlik doğrulama zinciri zayıflar. TXT mantığının genel çerçevesini görmek isterseniz TXT kaydı kullanımı yazısı bu konunun temelini tamamlar.

SPF Kaydı Ne İşe Yarar?

SPF, Sender Policy Framework ifadesinin kısaltmasıdır. Temel mantığı şudur: domain sahibi, DNS üzerinde bir TXT kaydı yayınlar ve bu kayıt içinde kendi adına e-posta gönderebilecek IP bloklarını veya servisleri tanımlar. Alıcı sunucu, gelen iletinin gerçekten bu yetkili kaynaklardan gelip gelmediğini kontrol eder.

Bu yapı özellikle spoofing ve sahte gönderici kullanımını sınırlamak için önemlidir. SPF tek başına bütün kötüye kullanımları durdurmaz; ancak yetkisiz gönderimlerin daha kolay işaretlenmesini sağlar. Google da e-posta kimlik doğrulama yöntemleri kılavuzunda SPF veya DKIM doğrulamasının temel gerekliliklerden biri olduğunu açıkça belirtir.

v=spf1 include:_spf.google.com ~all

Bu örnekte alan adı, Google tarafından tanımlanan SPF kapsamındaki sunuculara yetki verir ve diğer kaynakları ~all ile yumuşak şekilde başarısız sayar. Buradaki ifade küçük görünür; ama yanlış bir karakter veya eksik bir include satırı tüm teslimat davranışını etkileyebilir.

SPF Kaydı Neden Yanlış Kurulur?

En büyük neden, zaman içinde birden fazla e-posta servisi kullanılmış olmasıdır. Örneğin önce cPanel tabanlı bir hosting, sonra Microsoft 365, ardından bir bülten servisi devreye alınır. Her sağlayıcı “şu SPF kaydını ekleyin” dediğinde kullanıcı bunları ayrı TXT kayıtları halinde bırakır. Oysa SPF tarafında ana kural, her domain veya ilgili alt alan için tek SPF kaydı bulunmasıdır.

Microsoft Learn, aynı domain için birden fazla SPF kaydı bulunduğunda teslimat ve spam sınıflandırma sorunları çıkabileceğini açıkça belirtir. Bu yüzden yeni servis eklerken ikinci bir SPF oluşturmak yerine mevcut kaydı düzenlemek gerekir. Sorun çoğu zaman eksik kayıttan değil, gereğinden fazla kayıttan çıkar.

Doğru SPF Mantığı Nasıl Kurulur?

Önce gerçekten hangi sistemlerin sizin domaininiz adına e-posta göndereceğini netleştirmek gerekir. Kurumsal kutularınız Microsoft 365 üzerinde olabilir, pazarlama bültenleri başka bir servisten çıkabilir, uygulama bildirimleri ise ayrı SMTP altyapısından gelebilir. SPF kaydı bu kaynakları tek yapı içinde toplamalıdır.

Yani doğru yaklaşım şu değildir: her servise ayrı TXT kaydı eklemek. Doğru yaklaşım, mevcut SPF içinde gerekli include, ip4 veya ip6 parçalarını tek kayıtta birleştirmektir. Böylece alıcı sunucu yorum yaparken çelişkili kayıtlarla karşılaşmaz.

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:203.0.113.25 ~all

Buradaki mantık, hem Outlook koruma altyapısını hem Google gönderim alanını hem de tekil bir uygulama sunucusunu yetkilendirmektir. Ancak böyle bir birleştirme yapılırken gerçekten kullanılan servisleri ayıklamak gerekir; gereksiz include satırları SPF'yi şişirir ve yönetimi zorlaştırır.

~all, -all ve ?all Farkı

SPF kaydının sonundaki politika bölümü çok önemlidir. ~all yumuşak başarısızlık anlamına gelir; yani yetkisiz gönderim tam güvenilir sayılmaz ama her durumda sert red uygulanmayabilir. -all ise daha katıdır ve kayıt dışında kalan kaynakları kesin biçimde başarısız sayar.

Yeni kurulumlarda veya altyapı henüz tam netleşmemişken doğrudan -all ile başlamak bazen gereksiz risk oluşturur. Çünkü unutulmuş bir gönderim servisi varsa meşru postalar da başarısız sayılabilir. Bu nedenle birçok ekip önce görünürlüğü artırır, ardından kayıtlarını netleştirip daha katı politikaya geçer.

?all ise nötr yaklaşımı temsil eder; pratikte koruma seviyesi düşüktür ve modern kurulumlarda sınırlı değer taşır. Teslimat ve güvenlik dengesi için çoğu senaryoda ya kontrollü ~all ya da tam doğrulanmış yapıda -all tercih edilir.

SPF Tek Başına Yeterli Değildir

SPF önemli olsa da tek başına tam e-posta güvenliği sağlamaz. İleti yönlendirme senaryolarında SPF kırılabilir; çünkü mesaj sizin adınıza farklı bir ara sunucu üzerinden iletilebilir. Bu nedenle SPF, DKIM ve DMARC ile birlikte düşünülmelidir.

Google Workspace yardım dokümanlarında da SPF ile birlikte DKIM ve DMARC kullanımı açıkça önerilir. Özellikle Gmail tarafına düzenli gönderim yapan alan adlarında, yalnızca SPF'ye güvenmek modern teslimat beklentileri için yetersiz kalır. DKIM imzası ve DMARC politikası, SPF'nin açığını kapatan tamamlayıcı katmanlardır.

Bu ilişkiyi daha geniş görmek için TXT kaydı kullanımı yazısındaki SPF, DKIM ve DMARC bölümünü de birlikte okumak faydalı olur.

SPF Kaydı Eklemeden Önce Kontrol Edilmesi Gerekenler

Bu sorular cevaplanmadan SPF düzenlemek çoğu zaman tahmine dayalı değişiklik anlamına gelir. Özellikle eski hosting sağlayıcısından yeni kurumsal posta sistemine geçiş yapılan yapılarda, “eski kayıt kalsın, yenisini de ekleyelim” yaklaşımı en problemli senaryodur.

SPF Kaydı Nasıl Kontrol Edilir?

Kayıt eklendikten veya düzenlendikten sonra ilk iş, TXT yanıtının dışarıdan gerçekten doğru görünüp görünmediğini kontrol etmektir. Panelde kaydın görünmesi yeterli değildir; dışarıdan yapılan DNS sorgusunda hangi değerin döndüğü asıl önemlidir.

SPF sonucunu hızlı kontrol etmek için DNS lookup aracı ile ilgili domainin TXT kayıtlarına bakabilirsiniz. Burada kontrol edilmesi gereken nokta sadece bir SPF kaydının varlığı değil, birden fazla SPF çıktısı oluşup oluşmadığı ve beklenen include değerlerinin gerçekten görünmesidir.

Eğer sorgu sonucunda iki ayrı v=spf1 satırı görünüyorsa bu güçlü bir hata sinyalidir. Benzer şekilde kaydı güncellediğiniz halde eski değer dönüyorsa TTL veya önbellek etkisi düşünülmelidir. Bu yüzden değişiklikten hemen sonra kesin hüküm vermek yerine kısa süreli yayılım payı bırakmak gerekir.

Yaygın SPF Hataları

Birden fazla SPF kaydı bırakmak en yaygın hatadır. Bunun dışında gereksiz include zinciri kurmak, artık kullanılmayan sağlayıcıları kayıt içinde tutmak ve yanlışlıkla başka bir domainin SPF değerini kopyalamak da sık görülür. Özellikle kurumsal geçişlerde eski sağlayıcının izleri aylarca kayıtta kalabilir.

Bir başka yaygın hata, alt alanlar ile ana alanın aynı SPF mantığına sahip olduğunu varsaymaktır. Oysa bazı yapılarda ana domain ile belirli alt alanlar farklı e-posta akışları kullanabilir. Bu durumda hangi adın hangi kayıtla korunacağı ayrı düşünülmelidir.

SPF'yi kurup MX tarafını gözden kaçırmak da hatalı yaklaşımdır. Çünkü e-posta tesliminin bütünsel resmi için yetkili gönderici kadar alıcı altyapısı da önemlidir. Bu nedenle MX kaydı ayarları ile SPF planı birlikte okunmalıdır.

SPF Güncelleme Sonrası Güvenli Adımlar

Bu sıra, SPF kaydını yalnızca “ekledim bitti” mantığından çıkarır ve gerçek teslimat kontrolüne dönüştürür. En sağlıklı yaklaşım, SPF'yi bir kez yazılan statik kayıt değil, e-posta altyapısı değiştikçe gözden geçirilen yaşayan DNS politikası olarak ele almaktır.

Sağlam bir SPF yapısında tek kayıt mantığı korunur, gerçekten kullanılan gönderici kaynaklar açık biçimde tanımlanır ve değişiklik sonrası sonuç DNS üzerinden doğrulanır. Bu disiplin kurulduğunda teslimat sorunlarını teşhis etmek de yeni servis eklemek de çok daha kolay hale gelir.