SPF kaydı nasıl yazılır? ~all, -all ve DNS sorgu sınırı

SPF (Sender Policy Framework), bir alan adının sahibinin, o alan adı adına mail göndermeye yetkili sunucuları DNS'te v=spf1 ile başlayan bir TXT kaydıyla ilan ettiği standarttır. Alıcı sunucu, gelen mailin zarf göndericisindeki (envelope sender) alan adının SPF kaydına bakar ve maili gönderen IP adresinin listede olup olmadığını kontrol eder. Standart RFC 7208 ile tanımlanır.

Bu yazı, doğru bir SPF kaydının nasıl yazıldığını, kaydın sonundaki all ifadesinin anlamını ve kayıtları sessizce bozan 10 DNS sorgu sınırını anlatır.

SPF kaydı nasıl görünür?

Microsoft 365 kullanan ve ayrıca kendi MX sunucusundan mail gönderen bir alan adı için örnek:

ornek.com.tr.  IN  TXT  "v=spf1 mx include:spf.protection.outlook.com -all"

Kayıt soldan sağa okunur; ilk eşleşen mekanizma sonucu belirler:

Kaydın sonundaki all ne anlama gelir?

all mekanizmasının önündeki niteleyici (qualifier), listede olmayan bir göndericiye ne denileceğini belirler:

• -all (fail): Listede olmayan gönderici yetkisizdir. Önerilen değer budur.
• ~all (softfail): Yetkisiz olabilir; alıcı maili genellikle yine kabul eder. Yalnız DMARC politikası quarantine ya da reject olduğunda sonuç doğurur.
• ?all (neutral): Hiçbir şey söylemez. Sahte mail engellenmez.
• +all (pass): Dünyadaki her sunucu yetkilidir. SPF kaydının hiç olmamasından daha kötüdür: sahte mail SPF'den geçer ve güvenilir görünür.

Kaydın sonunda hiç all yoksa sonuç ?all ile aynıdır.

SPF'de 10 DNS sorgu sınırı nedir?

RFC 7208, bir SPF değerlendirmesinde DNS sorgusu gerektiren mekanizma ve değiştiricilerin toplamını en çok 10 ile sınırlar. Sayılanlar: include, a, mx, ptr, exists ve redirect. ip4, ip6 ve all sayılmaz.

Tuzak, include zincirlerinin iç içe sayılmasıdır. Kendi kaydınızda dört include görürsünüz, ama sağlayıcıların kayıtları da kendi içinde include taşır. Toplam 10'u geçtiğinde sonuç permerror olur: alıcı SPF'yi geçersiz sayar, meşru mailleriniz SPF'den kalabilir, DMARC zorlamadaysa reddedilebilir.

Sorgu sayısını düşürmek için:

1. Artık kullanılmayan servislerin include değerlerini kaldırın.
2. Sabit IP adresinden gönderen sistemleri (ör. bir uygulama sunucusu) ip4: ile yazın.
3. Bülten ya da CRM gibi yüksek hacimli servisleri ayrı bir alt alan adından (ör. bulten.ornek.com.tr) gönderin; o alt alan adının kendi SPF kaydı olur.

Ayrıca sonucu boş dönen (NXDOMAIN ya da kayıtsız) sorgular da sınırlıdır: RFC 7208 bunların sayısını 2 ile sınırlamayı önerir. Silinmiş bir servisin include değeri bu sınırı tüketebilir.

SPF kaydı nasıl yazılır? Adım adım

1. Gönderen her şeyi listeleyin. Mail sağlayıcınız (Microsoft 365, Google Workspace), kendi mail sunucunuz, CRM, bülten servisi, fatura sistemi, tarayıcıların tara-gönder özelliği, web sitesinin iletişim formu.
2. Her biri için doğru mekanizmayı seçin. Sağlayıcılar için kendi belgelerindeki include: değeri; sabit sunucular için ip4: / ip6:.
3. Tek kayıt yazın. Aynı adda v=spf1 ile başlayan ikinci bir kayıt olamaz. İki kayıt, RFC 7208'e göre permerror demektir ve alıcılar SPF'yi yok sayar. Mevcut bir kayda ekleme yapıyorsanız eskisini düzenleyin, yanına yenisini eklemeyin.
4. -all ile bitirin. Emin değilseniz geçiş döneminde ~all kullanın, ama DMARC zorlamaya geçince -all yapın.
5. Uzunluğu kontrol edin. Bir TXT dizesi en çok 255 karakterdir; daha uzun kayıt birden fazla tırnaklı dizeye bölünür. Birçok panel bunu kendisi yapar.
6. Doğrulayın. Kaydın yayınlandığını görmek için:

nslookup -type=TXT ornek.com.tr

dig +short TXT ornek.com.tr

Mail göndermeyen bir alan adında yapılacak tek şey sahte gönderimi kapatmaktır:

ornek.com.tr.  IN  TXT  "v=spf1 -all"

SPF'de hangi mekanizmalardan kaçınılmalı?

ptr: RFC 7208 bu mekanizmanın kullanılmamasını önerir. Yavaştır, çok sayıda DNS sorgusu üretir ve bazı alıcılar onu hiç değerlendirmez.

Gereksiz a ve mx: Web sitenizin sunucusu mail göndermiyorsa a mekanizması o sunucuyu boşuna yetkilendirir ve bir sorgu harcar. Mail Microsoft 365 ya da Google Workspace üzerinden çıkıyorsa mx da çoğu zaman gereksizdir; sağlayıcının include: değeri zaten gönderen sunucuları kapsar.

Geniş IP blokları: ip4: ile yazılan blok yalnız sizin sunucularınızı içermelidir. Paylaşımlı bir barındırma firmasının bütün bloğunu yazmak, aynı bloktaki diğer müşterileri de sizin adınıza yetkilendirir.

redirect= ile include: karışıklığı: redirect= başka bir alan adının politikasını tamamen devralır ve kayıtta all varsa yok sayılır. Birden fazla alan adını tek bir merkezi SPF kaydına bağlamak için kullanılır; sağlayıcı eklemek için include: doğru araçtır.

SPF tek başına yeterli mi?

Hayır. SPF yalnız zarf göndericisini kontrol eder; kullanıcının ekranda gördüğü From adresine bakmaz. Ayrıca bir mail başka bir sunucu üzerinden yönlendirildiğinde (forward) gönderen IP değişir ve SPF kırılır. Bu iki boşluğu DKIM imzası ve DMARC hizalaması kapatır. Ayrıntılar: DMARC nedir? ve DKIM nedir?

Denetta SPF'de neyi kontrol eder?

Denetta'nın Alan Adı ve E-posta Güvenliği modülü, SPF kaydını include zinciriyle birlikte DNS'ten okur ve şu kural kodlarıyla değerlendirir:

• MAIL-001: SPF kaydı yok.
• MAIL-002: SPF kaydı geçersiz (permerror): birden fazla kayıt, sözdizimi hatası, döngü ya da boş cevap sınırı.
• MAIL-003: Kayıt herkese izin veriyor (+all).
• MAIL-004: Kayıt sahte göndericiyi reddetmiyor (?all, all yok ya da DMARC zorlaması olmadan ~all).
• MAIL-005: 10 DNS sorgu sınırı aşılıyor; zincir iç içe sayılır.

Düzeltme metni mail sağlayıcınıza göre (ör. Microsoft 365 için include:spf.protection.outlook.com) ve DNS barındırma sağlayıcınızın paneline göre yazılır. Metin yalnız gösterilir; Denetta DNS kaydı değiştirmez.

Kendi alan adınızın SPF durumunu alan adı kontrolüyle görebilirsiniz. Kontrol yalnız DNS kayıtlarını okur ve 21 kuralla bir ön kontrol puanı üretir; modülün tamamı 31 kuraldan oluşur.

Sıkça sorulan sorular

Bir alan adında iki SPF kaydı olabilir mi?

Hayır. Aynı adda v=spf1 ile başlayan ikinci bir TXT kaydı, RFC 7208'e göre permerror sonucudur ve alıcılar SPF'yi yok sayar. Tüm göndericiler tek kayıtta birleştirilmelidir.

~all mı, -all mı kullanmalıyım?

Gönderen tüm servisleri listelediğinizden eminseniz -all. ~all (softfail) ancak DMARC politikası quarantine ya da reject seviyesindeyse koruma sağlar; tek başına sahte maili durdurmaz.

SPF kaydı 255 karakteri aşarsa ne olur?

Bir TXT dizesi en çok 255 karakter olabilir; daha uzun kayıt birden fazla tırnaklı dizeye bölünür ve alıcılar dizeleri birleştirerek okur. Birçok DNS paneli bölmeyi kendisi yapar.

SPF kaydım doğru ama mailler yine reddediliyor, neden?

Sık nedenler: 10 DNS sorgu sınırının aşılması (permerror), aynı adda ikinci bir SPF kaydı ya da listede olmayan bir göndericinin (CRM, bülten, tarayıcı) kullanılması. DMARC raporları hangisi olduğunu gösterir.