SPF +all, -all, ~all ve ?all Ne Anlama Gelir?

Sesli Dinle — Makale

SPF (Sender Policy Framework), bir alan adını kullanarak e-posta göndermeye yetkili kaynakları bildiren doğrulama yöntemidir. SPF kaydında niteleyici, bağlandığı mekanizma eşleştiğinde hangi SPF sonucunun üretileceğini belirleyen işarettir. + pass (başarılı), - fail (başarısız), ~ softfail (zayıf olumsuz), ? ise neutral (tarafsız) sonuç verir. İşaret yazılmazsa + varsayılır. Politika, DNS içinde TXT kaydı olarak yayımlanır.

all, bütün IP adresleriyle eşleşen sonlandırıcı mekanizmadır. Bu nedenle +all, -all, ~all ve ?all değerlendirme kendilerine ulaştığında tanımlanmamış bütün kaynaklar için farklı sonuç üretir. all sonrasındaki mekanizmalar hiçbir zaman çalışmaz.

SPF sonucu, alıcıya alan sahibinin yetki beyanını taşır; iletinin kesin kabul veya reddedilme talimatı değildir. Alıcı sistem sonucu kendi güvenlik, itibar ve teslim politikasıyla birlikte yorumlar. Bu ayrım özellikle -all ile “kesin ret”, ~all ile “kesin teslim” beklenmesini önler.

SPF Niteleyicisi Nasıl Çalışır?

Mekanizmalar soldan sağa değerlendirilir. Kaynak IP adresiyle ilk eşleşen mekanizmanın niteleyicisi sonucu belirler ve işlem sona erer. Niteleyici yalnız hemen ardından gelen mekanizmaya bağlanır; bütün kaydın genel ayarı değildir.

Örneğin v=spf1 ip4:192.0.2.0/24 -all kaydında ip4 önünde işaret bulunmadığından + varsayılır. Belge amaçlı bu ağdaki kaynaklar pass, diğer bütün kaynaklar ise -all nedeniyle fail alır. Kaynakları ve adresleri gerçek kayda kopyalamayın; kendi gönderim envanterinizle değiştirin.

Bir mekanizmanın önünde olumsuz niteleyici de kullanılabilir. Örneğin -ip4:192.0.2.25 yalnız o kaynak eşleştiğinde fail üretir; bu adresle eşleşmeyen kaynaklar için değerlendirme sonraki mekanizmayla sürer. Bu tür sıralamalar kolayca yanlış anlaşılabildiğinden politika, her kaynak sınıfı için beklenen sonuç tablosuyla doğrulanmalıdır.

+all, -all, ~all ve ?all Karşılaştırması

SPF raporlarında sonuç adları genellikle küçük harfli pass, fail, softfail ve neutral biçimleriyle görülür. Bu adlar, alıcının eylemini değil yetkilendirme değerlendirmesinin sonucunu bildirir. DNS kaydındaki mekanizma ve niteleyicileri de e-posta sağlayıcısının beklediği standart yazımla yayımlayın.

+all Neden Güvenli Değildir?

all her kaynakla eşleşir ve niteleyici yazılmadığında + kabul edilir. Dolayısıyla hem +all hem de yalnız all, önceki mekanizmalarda bulunmayan herhangi bir IP adresine pass sonucu verir. Bu son terime ulaşan yetkisiz kaynakla meşru kaynağı SPF üzerinden ayırma imkanı kalmaz.

+all, kayıt sorununu geçici olarak “çözmez”; SPF’nin yetkilendirme amacını ortadan kaldırır. Bir hizmet pass alamıyorsa gerçek SMTP oturumundaki MAIL FROM adresinin alan adı, istemcinin kendini tanıttığı HELO/EHLO adı, çıkış IP adresi ve doğru include mekanizması bulunmalıdır.

Bir kayıt v=spf1 include:_spf.example.net +all biçimindeyse include hatasız değerlendirilir ve eşleşmezse +all kalan kaynakları yetkilendirir. include değerlendirmesi temperror veya permerror üretirse işlem bu hatayla biter; +all aşamasına geçilmez. E-posta sağlayıcısı eklemek için son terimi genişletmek yerine tek politikadaki gönderim envanterini düzeltin.

-all Ne Bildirir?

-all, önceki mekanizmaların hiçbiriyle eşleşmeyen kaynak için fail sonucu üretir. Alan sahibi böylece kaynağın değerlendirilen SMTP kimliğini kullanmaya yetkili olmadığını kesin biçimde bildirir. Bu güçlü beyan, yalnız bütün meşru çıkışlar kayıt içinde tanımlandığında güvenle kullanılabilir.

Fail sonucu alıcının iletiyi mutlaka reddedeceği anlamına gelmez. Alıcı SMTP oturumunda reddedebilir, kabul edip istenmeyen posta puanlamasına katabilir, karantinaya alabilir veya başka kimlik doğrulama sonuçlarıyla birlikte değerlendirebilir. SPF standardı tek bir teslim davranışı dayatmaz.

Hiç e-posta göndermemesi gereken alan veya sunucu adında v=spf1 -all yayımlamak, hiçbir kaynağın o adı MAIL FROM adresinin alan adı veya HELO/EHLO adı olarak kullanarak posta göndermeye yetkili olmadığını bildirir. Ana alan ile alt alanların politikaları otomatik olarak birbirine aktarılmaz; her ad kendi amacıyla ele alınmalıdır.

~all Ne Bildirir?

~all, eşleşmeyen kaynak için softfail üretir. Bu, alan sahibinin kaynağın muhtemelen yetkisiz olduğuna ilişkin zayıf bir olumsuz beyanıdır; “kısmen yetkili” anlamına gelmez. Önceki bir mekanizma eşleşirse sonuç o mekanizmanın niteleyicisine bağlıdır; yalnız + niteleyicisi pass üretir. Önceki mekanizmalar eşleşmez ve değerlendirme ~all terimine ulaşırsa softfail sonucu alınır.

Softfail, yeni bir envanterin gözlendiği sınırlı geçiş döneminde kullanılabilir; ancak alıcıların nasıl davranacağı evrensel değildir. Geçişten sorumlu ekip, bitiş tarihi ve -all için kabul ölçütleri belirlenmezse politika süresiz olarak zayıf kalabilir.

~all kullanılırken de bütün gerçek kaynaklardan test iletisi gönderin. Softfail alan meşru bir hizmet bulunursa niteleyiciyi sürekli zayıf tutmak yerine hizmetin gerçek MAIL FROM adresinin alan adını, çıkış IP adresini ve resmi yetkilendirme yöntemini düzeltin.

?all, Neutral ve SPF Kaydı Olmaması

?all, eşleşmeyen kaynak için neutral üretir; alan sahibi kaynak hakkında yetki iddiasında bulunmaz. Bu sonuç, pass değildir ve kaynağı olumlu biçimde yetkilendirmez. Fail veya softfail gibi olumsuz bir beyan da taşımaz.

Neutral ile SPF politikası bulunmaması aynı sonuç değildir. SPF kaydı bulunamazsa değerlendirme none sonucuna ulaşır; ?all ise geçerli bir politikanın bilinçli neutral sonucudur. İki durum tanılama kayıtlarında ayrılır; ancak SPF standardına göre alıcı neutral sonucunu none ile aynı şekilde işlemelidir.

Kayıtta all ve redirect yoksa, hiçbir mekanizma eşleşmediğinde varsayılan sonuç neutral olur; bu davranış ?all varmış gibi düşünülebilir. Açık bir son terim, alan sahibinin niyetini ve hata ayıklamayı daha anlaşılır kılar.

all ile redirect Birlikteyse Ne Olur?

redirect, hiçbir mekanizma eşleşmediğinde değerlendirmeyi başka alanın SPF politikasına devreden değiştiricidir. Kaydın herhangi bir yerinde all mekanizması varsa redirect yok sayılır; çünkü all mutlaka eşleşir ve yönlendirmeye sıra gelmez.

v=spf1 include:_spf.example.net redirect=_spf2.example.net -all gibi bir kayıtta -all bulunduğundan redirect işlevsizdir. include ve redirect aynı şey değildir: include, başvurulan politika pass verdiğinde kendi mekanizmasını eşleştirir; redirect ise eşleşme bulunmadığında tüm değerlendirme için başka politikayı kullanır.

E-posta sağlayıcısının verdiği include terimini redirect ile veya tersini kendi başınıza değiştirmeyin. Her ikisi de DNS sorgusu başlatan terim sınırına dahildir; ancak hedef politikanın sonuçlarını aynı şekilde işlemezler.

SPF Sonucu Alıcının Teslim Kararını Nasıl Etkiler?

Söz dizimi hatası, aynı adda birden fazla SPF politikası veya DNS sorgusu başlatan terim sınırının aşılması permerror üretir; niteleyici seçimi bu yapısal hataları geçerli sonuca dönüştürmez. Geçici DNS hatası temperror olabilir ve sonraki denemede değişebilir.

Niteleyici yalnız eşleşme sonucunu belirler; alıcının uygulayacağı işlemi zorunlu kılmaz. Ayrıca all, ip4 ve ip6 değerlendirme sırasında DNS sorgusu başlatmaz. include, a, mx, ptr, exists ve redirect ise tüm değerlendirme boyunca toplam en fazla 10 kez değerlendirilebilen, DNS sorgusu başlatan terimlerdir. İç içe politikalar da bu toplama dahildir; sınır doğrudan DNS paketi sayısı değildir. Bir mekanizmanın niteleyicisi bu hesaba etkisini değiştirmez.

SPF Sonucunun DKIM ve DMARC ile İlişkisi

SPF, görünen From üstbilgisini doğrudan doğrulamaz; kaynak IP adresinin MAIL FROM adresindeki alan adını veya HELO/EHLO adını kullanarak gönderim yapmaya yetkili olup olmadığını denetler. Başarılı SPF sonucu, kaynağın denetlenen SMTP kimliğini kullanmaya yetkili olduğunu gösterir; içeriğin güvenli, hesabın ele geçirilmemiş veya görünen gönderenin doğrulanmış olduğunu kanıtlamaz.

DMARC (Domain-based Message Authentication, Reporting, and Conformance), SPF tarafında yalnız pass sonucu alınan MAIL FROM adresinin alan adıyla görünen From adresinin alan adının uyumlu olup olmadığını denetler; bu uyum alan adı hizalaması olarak adlandırılır. HELO için alınan pass sonucu tek başına DMARC başarısı sağlamaz. DKIM (DomainKeys Identified Mail) ise e-postanın imzasını doğrular. SPF fail olsa bile geçerli DKIM imzasının alan adı görünen From adresinin alan adıyla hizalıysa DMARC başarılı olabilir.

Bu nedenle “SPF fail = DMARC fail” veya “SPF pass = DMARC pass” biçiminde doğrudan eşitlik kurmayın. SPF veya DKIM başarısı, alan hizalaması ve DMARC sonucu ayrı ayrı incelenmelidir.

Niteleyiciyi Değiştirmeden Önce Kontrol Listesi

1. Alan adına ait bütün kurumsal posta, web uygulaması, fatura, destek, bülten ve üçüncü taraf gönderim kaynaklarını envantere alın.
2. Her kaynak için gerçek MAIL FROM adresinin alan adını, HELO/EHLO adını ve çıkış IP adresini doğrulayın.
3. all teriminin sağında işlevsiz mekanizma bulunmadığını, redirect kullanımının niyetle uyumlu olduğunu kontrol edin.
4. Aynı DNS adında tek v=spf1 politikası bulunduğunu ve iç içe politikalarda da geçerli olan 10 DNS sorgusu başlatan terim sınırının aşılmadığını doğrulayın.
5. Değişiklikten en az mevcut TTL kadar önce kısa TTL yayımlayın; eski önbelleklerin geriye dönük kısalmadığını hesaba katın.
6. Her gerçek kaynaktan kontrollü ileti gönderin; güvenilir alıcının Authentication-Results (kimlik doğrulama sonuçları) üstbilgisinde spf sonucunu ve smtp.mailfrom kimliğini inceleyin.
7. DMARC raporlarında beklenmeyen kaynak, hizasız SPF ve geçerli DKIM yollarını izleyin.
8. Geçici ~all kullanılıyorsa sorumlu ekibi, bitiş tarihini ve -all geçiş ölçütünü belgeleyin.

Authentication-Results üstbilgisini yalnız alıcı sistemin güven sınırı içinde eklediği biliniyorsa kanıt sayın; dışarıdan taşınan aynı adlı alan sahte olabilir.